当前项目采用的敏捷开发模式,下面是我对的敏捷测试理解和建议:
1. 验证需求和设计
在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。积极地参与前期工作,并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试,不要等待到功能完全做好才开始。
2. 测试计划,测试用例
2.1 编写计划、测试用例
在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。测试人员可以驱动开发人员来写story,来确定每个user story的优先级。不过这中间存在一点,开发人员常会估算时间过少,引起版本无法按时发布须进行加班才能进行发布。主要原因是由于版本更新很快,任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间,比如开发中遇到问题的时间,开会,给其他成员提供帮助的时间,等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素, 测试人员根据已审核通过的需求和设计编制测试计划,设计测试用例。测试的这两个需求和设计也要被项目经理和开发人员审核。
2.2 测试用例的审核
为使开发人员能参与到Test Case的评论中来,以保证Test Case的质量和可行性,确保测试工作的顺利进行,让开发人员迅速地了解测试的重点并给出相应的意见和建议,测试人员在出 Test Case的同时,应出一份相关的说明书,其中注明Test Case已覆盖了哪些特性,具体每个特性对应的Test Case的编号,这样在测试经理和PM对Test Case进行评论的时候,能够对Test Case的覆盖率一目了然,对覆盖率不足的地方能够及时给出意见。
在迭代后期测试要抽时间更新测试用例。
2.3 测试用例的维护
在执行测试阶段中,测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例:一是对于当初测试设计不周全的领域,二是对于外部的Bug,没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁),所涉及的测试用例也要相应地修改,使测试用例保持和现有的功能需求同步。
|