如何用敏捷方法做测试?-创新互联
敏捷的核心就是个“快”字:快速开发,快速推出,快速验证产品方向。说白了就是管理每个小目标,保证他们能够按时完成。
我们提供的服务有:网站设计、做网站、微信公众号开发、网站优化、网站认证、安源ssl等。为近1000家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的安源网站制作公司想要运用敏捷方法,要注意几点:
1、开发做完一个小功能马上开始测试,减少等待时间。
2、测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况。
3、每次的bug都是针对刚刚开发完的功能,开发处理起来会更得心应手,减少沟通成本。
在与同事沟通中,我还了解到,将bug加入开发计划会大大影响他们的目标完成进度,往往问题刚整理出一些思路,就因为某些bug需要处理而被迫中断了。
所以很多时候,直到deadline临近,目标中还会存留大量任务。如果测试一味地只管提交bug,而不考虑开发的工作习惯和目标的可执行性,就会导致效率大大降低。
*内容截图自teamin演示案例,结构略有修改,下同*
解决这个问题,需要将bug单独管理,同时做到合理分配,有节制,分缓急。
比较好的做法是,测试根据当前的开发计划设置自己的计划,将所有bug按紧急、重要、一般3种优先级来划分(分几级不重要,重要的是如何处理分级不同的bug),优先挑选紧急bug放入当前目标,重要bug根据当前进展情况适量分配,一般bug可以暂时不考虑。
另外,bug最好能建立单独的项目来管理,保证开发的任务集中度,避免产生过多冗余信息(属于当前版本却优先度不高的bug)。
项目、目标、标签,三位一体
举个不恰当的例子,测试与开发的配合就像父母喂孩子一样,不能等到孩子饿了才给吃的,这样容易一次喂太多,引起消化不良;也不能什么都给孩子喂,要注意合理配餐,否则营养失衡影响健康发育。回头心疼的不还是你这个做父母的吗?(哎!好像哪里不对……)
计划经常需要修改,测试如何应对?
计划变更频繁可以说是敏捷开发的另一大特点。上文提到了将bug单独管理,并将筛选后的bug加入计划,那么这种单独管理bug的方式就可以解决计划频繁变更的问题吗?
显然不能,因为bug最终还是要加入计划,计划出现变更,之前分配好的bug也会随之发生变化,这样之前设定的测试目标岂不乱套了吗?而且想必大家也会有疑问,我分配到开发计划中的bug,相当于从测试项目中移走了,那么修改后我如何得知,又如何统一审核呢?
简单来说,我需要任务支持跨项目协同,这样可以将同一个任务分配给不同的项目,达到测试与开发既各自独立、又相互联动的效果。这其实比较难实现,好在我用的协作工具支持我这样做,具体怎么做我不太好描述,直接上图吧:
跨项目协同,任务状态共享
这样一来,我在测试项目中设置的目标计划,不会随着开发计划的变更而变化,计划的调整都是自主和可预期的,另一方面,也能解决任务状态同步和后期审核的问题。
如何编写测试用例?
计划开始阶段没有测试工作,主要就是做测试用例了。我想这也是不少测试小伙伴的心头大患。测试用例结构复杂,分支众多,很难做的很详尽,一开始更是不知道从何写起。
到目前为止,我还没有找到一款非常合适的管理工具能够比excel做的更好,管理工具即使能够自定义功能,也很难达到excel的灵活性。与其在软件中记录分支,我宁愿将需要参考的相关任务导出成excel,然后自己添加情况分支,做优化修改。
导出任务列表,便于用excel编写用例
我一般会在开发前期就将产品的整体计划导出,作为总的测试用例大纲;再将开发当前正在做的计划导出,作为版本测试的用例大纲。
经常写测试用例的测试小伙伴可能都深有体会,用例最头疼就是整理结构大纲,而产品的整体计划本身就是一个结构性很强的需求大纲,相当于一个全部功能点的索引目录。
我们只要导出,稍作修改和补充,用例的完成度就会相当高。而且这样做还省去了与产品、开发一条条对接沟通的麻烦,减少了大量的沟通成本。
这种看似“投机取巧”的方法会让测试的用例编写工作事半功倍,效率大大提升。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网页题目:如何用敏捷方法做测试?-创新互联
URL网址:http://scyanting.com/article/dicjcj.html