敏捷推荐围绕应用建立足够的单元测试和验收测试,以构建足够强壮的测试套件。然而,实际情况是:不是所有的应用都有配套的测试套件。敏捷测试讨论组中有一个有趣的讨论,提到如何为没有任何自动化测试的应用进行测试,成员们提出了多种方法。
Asad Safari 发起了这个讨论,他说他的一个应用没有任何测试,团队中的开发人员不熟悉单元测试,距离截止日期也只有3 个星期的时间供团队测试。他希望得到一些建议,指导如何在这样的约束条件下测试。
Phlip 回应道:他曾多次处于类似环境,并推荐以下建议:
- 加入一个可选模块,能够通过任意或是指定的输入来驱动应用;
- 向程序中加入日志,把错误信息和断言存入日志文件中;
- 编写一个大单元测试,调用你所有的程序,提供前面提到的输入,然后梳理日志;
- 编写一个大的断言,在其中指出日志应该没有任何错误;
- 现在开始一个一个排错。每次去掉一个错误,去掉对它的异常处理。
Phlip 指明:在这个大测试保护伞之下,如果时间允许,团队可以开始编写小规模的、目的更明确的测试。他还指出:虽然团队可以在接下来的三个星期等待上面的做法产生效果,编写和运行更小的单元测试应该马上开始。
Adam Sroka 同意 Phlip 的建议,并补充道:
没错,很多团队碰到质量低劣的代码时,会放慢速度,产出的价值也会减少,而这对于质量没有任何好处。我们需要更实用的解决方案……如果没有从一开始就加入测试,那么就很难完全把测试做好,这是没问题的。但是就此认为测试没有价值,这是错误的看法。测试虽然不完美,但仍有其价值所在。
Brian Spears 却没有被他们说服,他认为敏捷不是魔法,在三周时间内恐怕没法产生什么好解决方案。他说:
敏捷不是魔法,对这种紧急情况的解决方案,如果有的话,就是要投入很多很多时间,这明显不是敏捷的做法。
Adam 反对这个看法,指出有很多团队如果进入类似境况,都采用了敏捷。这是团队变得有实效的机会,也是让软件变得更好的启动之旅。
Annette 认为:这种情况最应该做的就是用很多很多时间做手工测试,因为到了这个阶段,自动化测试就太费时间了。推荐从重要的和与收入相关的功能开始测试。Annette 也推荐了Lisa Crispin 和Janet Gregory 合著的 Agile Testing 一书。
Charles Bradley 提出了类似的建议,不过他指出还要获得一个有条件的承诺。他说:
你的时间很有限,所以从业务角度来看,将 ROI 最大化是最佳选择。就使出吃奶的劲头做手工测试吧!但是要从你的老板那里得到承诺:他们无论如何也不会再让你的团队这么做了……他们应该先规划好时间和金钱完成自动化测试……着手下一个发布工作时就应该马上开始,甚至更早,比如开始修复当前版本的 bug 时。
因此,编写完整的测试套件,也许不是最适合当前情形的做法,团队最好开始手工测试。而这并不能削弱在一有机会时就编写适当的测试套件的做法。正如 Jonathan Rasmusson 指出的:
你所能做的就是修复 bug,然后在上线之前尽一切可能完成手工测试。这就是你到这个时候还能做的事情。更大、更重要的问题,是你在三周截止日期到达之后要做什么。
评论