敏捷开发之六:测试、生产测试和beta测试

在一般项目开发中,需求方和开发的矛盾主要体现在时间和完成的功能。同样这个问题,在敏捷开发中会依然存在。

测试的重要性。为什么要有专门的测试团队以及测试的方法论这里就不多赘述了。在敏捷开发中,平行观念很重要,所以测试是可以和开发几乎一起开始的。

对于测试团队来说,一部分测试工作可以跟着Issue(User Story),当开发人员完成一个Issue开发,就可以进行功能测试。对于有些不能直接进行测试的Issue,也没关系。标准的测试案例方法还是可以使用的。在开发的初期,平行测试并不能带来很多效率提升,因为功能还没有开发好,开发好的功能一会比较零散。到了开发中后期,同步开展测试的效率就体现出来了,可以让测试的进度比开发始终只滞后一点。这在传统的瀑布开发中是做不到的。不过,这对测试人员的要求高了不少,工作强度也会增大,会产生不少反复的回归测试。我们在实际敏捷开发过程中,测试人员是一早就进入的,就是为了便于团队之间的沟通。

我们发现,测试人员提早接入还会有很多小的好处。比如,在开发过程中,开发人员需要制造一些测试数据,制造测试数据的脚本越早准备好越好,由于测试相对的提前,数据脚本的问题可以及早发现。另外,之前由于开发和测试在时间上是分成不同阶段的,而在敏捷中产品、 开发、测试几乎一直在一起,对于需求在开发过程中的具体展开有一个感性的认识。

生产测试,一般是需求方和产品经理来负责。在生产测试过程中,提出需求的部门和产品经理需要按照需求来逐个功能点进行测试。瀑布开发方式中,需求方一般要等到测试通过后才能进行测试,发现的话,需要再提交到开发,然后再经过开发-测试-生产测试的流程,这样时间当然有开销。敏捷开发模式里面,生产测试几乎和 开发、测试一起开始,发现问题的时候,通过产品经理和项目经理可以立刻就增加一个Issue或者修改功能点,以保证项目进度受到的影响最小。

公开测试,也叫beta测试,对于有用户的产品来说,让一小部分用户先开始使用,并收集意见,在下一个迭代周期中进行改进,非常符合敏捷思想。这部分其实已经不是开发的范畴了,而是产品流程的一部分。敏捷开发Scrum是按照Sprint来发布的,因此我们可以通过这样的步骤来进行一个不断迭代升级:发布一个Sprint1作为beta版本,同时继续进行Sprint2的开发测试等,同时产品经理收集beta测试中用户的反馈,进行归纳讨论后,作为Sprint3或者之后Sprint的一部分。在发布时间上,如果可以做到2-3周一个Sprint的话,那么在几个月后,用户对于产品的满意度会上升很多,并且用户会感觉他们的意见得到了重视,从而愿意更好的体验产品和提出建议。

因此,beta测试并不是给用户测试那么简单,而是在互联网、移动时代贴近用户迅速提高产品质量的一种方法。国内小米、微信等例子已经不胜枚举。说到这里,大家或许可以明白为什么Scrum方法在互联网时代突然爆发出来成为一种非常有效的方法,其在本质上就是因需而变、因用户而变。