在软件研发中,有一种思想叫TDD,即测试驱动开发,TDD是敏捷方法中的一项核心实践,其原理是在开发功能代码之前,先编写单元测试用例代码,对要编写的函数或类明确测试方法后,再进行设计与编码。

本篇不是讲如何来实践TDD,而是利用这种思想来推进项目的进度。大部分人可能都有这样的感受“别人催着自己的工作往前赶,心里贼反感”,“而自己催着别人往前赶,心里只有快感”。

在大部分项目都在走敏捷模式的情况下,项目经理已经被弱化,而产品经理更多关注设计、客户,使项目团队经常出现一团散沙的情况。作为下游的测试团队就贼难受,上游的设计、开发掉了链子,如延期,在时间截点已被卡死的情况下,测试团队很难顺利完成项目测试并交付。

项目没有顺利交付,不管什么原因,板子必将指向测试。所以,此时活用“TDD”显得很有必要,精髓是“驱动”。而测试要驱动设计、开发,根据小酋的实践,需要从计划、需求、用例、转测四点着手。

计划

不管项目如何变化,都需要一个大家共同确定的计划。不用出一个非常详细的计划,可以是一个一个的时间节点,比如A模块什么时候完成设计,什么时候交付测试,什么时候完成测试。

当这些节点确定的情况下,我们才能去驱动项目进度。不论是产品经理做设计变更,还是开发人员落地搬砖,测试才有一个底,应对其中的变化,是力争调整计划,还是协调加大测试资源投入,亦或是调整测试策略,才能做到有理有据,有条不紊。

否则只有截点的情况下,可能产品经理说对不起,客户有了新的需求,设计要多花点时间,大家后面紧一紧;开发人员说对不起,这个技术超出了预期,或者又加了新需求,那只有辛苦测试后面加加班;最后轮到测试,截点在望,只能边吐槽边熬夜,搞得身心憔悴。

需求

需求,大家都知道非常重要,但问题常常还是出在上面。比如,大家理解不一致,场景、业务考虑不全,脱离实际无法实现等。

作为测试,我们必须认真啃需求,产品经理知道的,我们一定要知道,而产品经理不知道的,我们还得指出来,做好跟踪,确认解决。如果判断极可能出现理解偏差的地方,要与产品经理确认,理解一致后把信息同步给对应的开发人员。核心要点:尽可能早地发现需求中的问题,并跟踪、确认解决,减少开发歧义和后期出现的设计缺陷。

用例

用例越快完成越好,越早完成评审越好。

要推动项目进度,测试用例的设计也要提效。在敏捷项目中,我不倡导教条主义,即一定要按照XXX标准模板去编写,而应该积极探索更加快捷的方式,如测试思维导图,测试点列表等。用例,我们应花精力在设计思想,业务逻辑上,而不应该过分追求形式,除非时间允许,或者有其它需要(如后续作为客户验收用例)。

用例出来后,要做评审。可以根据版本大小,确定参与者的范围,但一定要有产品经理。评审通过后的用例,我们可以分享给开发人员,这也是开发人员可以查漏补缺,消除需求理解偏差的重要途径之一。

转测

要想测试顺利,转测(即开发提测)质量也关键。

测试最不能忍受的情况,可能就有:提测后,明显的功能都出错。如转测登录模块,输入账号、密码,点击登录报错了!

那怎么能保证转测质量呢?这里有三个实践:

1、提高开发人员的质量意识

这可能很难做到,所以退而求次,提高开发leader(或者主导开发人员)的质量意识,只有开发leader去强调、去推动,转测质量才有明显的改善。

我们要做的就是,平时和开发leader搞好关系,多交流项目中的看法,潜移默化中达成对软件质量的统一看法。

2、开发自测

我们可以寻求上面的支持,引入开发自测的环节。在开发提测前,我们可以提供自测用例,这些用例应尽可能精简,能覆盖提测内容的主要功能,如登录模块“输入账号、密码登录成功”。

3、冒烟测试

同样,我们为了保证转测质量,引入冒烟测试环节。即开发转测后,只有当我们把主干测试用例(与上面开发自测用例同理)通过后,才进一步做后续的系统测试。否则,有主干用例执行失败,就视为冒烟测试失败,打回开发责令其整改后再提测。

通过上述四个方面,我们基本上就能很好地驱动项目了,但实际情况远不如文字这么简单、明了。具体执行效果还得依赖于我们的沟通能力,协作能力,以及人格魅力;不管是能力、还是魅力,都建立在我们不断总结、思考、学习的基础上。