5、传统测试阶段
当开发完成了所有的功能点,测试那个时候也差不多完成了这些功能点的测试,我们就会有一个阶段性的最终版给客户评估,让客户看看需要的功能是不是都已经可以了,如果觉得没什么问题,一般情况下就不进行功能添加与更改了。(当然,真的要更改我们还是会欢迎的,不过一般客户也知道,频繁的更改不能保证产品的质量,所以到最后他们一般有不紧急的更改也会要求放在下一个版本里的)
到目前为止,真正意义上的敏捷测试阶段其实已经完成了,要开始进入一些传统的测试了,比如系统测试,性能测试,压力测试等。这些就会用到之前说的DevTest里管理的测试用例,通过这些测试用例,我们会生成测试任务,然后通过手工和自动的方式,把这些任务完成,当然,可能要进行几轮,第一轮测试最仔细,覆盖面最大,所以时间也最长,第二轮主要是对开发修Bug的确认以及可能影响到的功能的测试,最后还有一轮验收测试,主要对基本的功能进行测试,确保不会出现明显的问题。
这些测试都完成以后,差不多产品也就可以发布了,当然能不能发布,领导们还是会有一个会议研究通过的,不过也就是通过 DevTrack 和 DevTest 来导出一些报表看看测试情况来了解产品质量。
以上差不多就是我们公司现在的一个流程,从严格意义上来说,不是完全的敏捷测试,只是算一部分,但是如果从以前的瀑布来看看,已经算很敏捷了。而且,从现在这个流程分析,如果把那些传统意义上的测试继续敏捷化,我们觉得对产品的质量没法保证,所以基本上,目前这个模式,可以算是我们公司特色的敏捷测试了,之后应该不太会有大的更改了。
接下来我再总结一下我们公司的模式,以及补充一些之前没提到的,因为之前写得太急,有时候很难想得太全。
我们公司测试模式按照顺序主要有以下这么几步组成:
1)需求阶段测试研究设计方案是否符合要求
2)开发编码期间完成测试用例
3)开发完成一个功能的编码,测试就需要开始测试,并且确保能在一个迭代周期中完成测试,并且确认严重Bug的修复
4)所有迭代周期完成后,开始进入集成测试,系统测试,验收测试以及压力测试,性能测试
差不多测试需要参与的工作就是这几步了,下面就是有一些细节点讨论一下,我会以问答形式来介绍:
(1)问:发现了很多Bug,测试人员怎么知道哪些Bug要马上修,哪些可以推迟修呢?
答:首先,我们会规定什么样子的Bug需要什么样的优先级,比如报错优先级就会比较高,每个测试人员都有这么一个文档让他们来判断这个 Bug 是什么级别。其次,我们会有专门的人员对这些Bug进行二次过滤,由他们来觉得这个Bug是否需要在这个迭代周期中进行修复,这种专门的人员的能力需要很高,因为他们需要能了解这个Bug的重要性以及这个Bug修复起来所需人力物力是否能在这个迭代中解决,所以一般这个角色会有测试主管或者项目经理来承担。
(2)问:整个测试期间,就专职的测试人员参与测试就行了吗?
答:不是的,首先开发肯定需要进行单元测试;然后设计人员和项目经理也要参与测试,因为只有他们最清楚这个功能设计的初衷,才能真正知道现在做完的是不是真的符合当初的初衷;再次,客户也会参与测试,因为产品说到底最终是给客户使用的,他们当然想拿到一个他们满意的产品,所以我们会定期给客户版本,让他们对做好的功能点进行简单的试用,让他们来看看产品是否符合他们的需要,这样就是最直接的用户体验了,发现的问题也是最真实的。