Do We Still Need Test Spec
22 Aug 2014 Category: Testing做weekly retrospective时，赫然发现本周大大小小拢共做了16个test case的review(包括test specification和test report)，且大部分都集中在后半周。直接后果就是，每天的日程表都被会议占得满满的，只有晚上到家才有时间提前看材料和提comments。没办法，每个sprint快结束时，都是各个团队最忙碌的时候–要抓紧时间把backlog上的任务都消灭掉。这么多的specification(abbr. spec)，着实花了不少author和reviewer的时间。不禁想起人们常提的那个问题：
软件测试还需要测试用例规范吗？
软件测试流程无外乎以下几点。略微有些出入的，也左不过是某些步骤交叉结合在一起。
- 需求分析 requirements analysisl;
- 测试规划 test plan;
- 测试用例编写 test case spec;
- 测试用例执行 test case execution;
- 测试报告提交 test report;
通常“用例执行”最受重视也耗时最久，因为只有这一步是在真正的被测对象上进行操作，而大部分的软件bug也是在这一步被发现的。“需求分析”和“测试规划”重视程度次之，这可以理解，因为这两步可以说是重要的学习过程，不做好这两步后面的步骤将困难重重。而“用例编写”和“测试报告”，作为常规意义上的“文档类工作”，通常是优先级最低的tasks，预留的时间往往也最短。有的同事说写得那么好干嘛，我们是coder不是writer，我把case测好，能发现问题就够了。更有甚者宣称“test spec完全是可有可无的东西”。
不知道这些同事是否跟了业界的潮流，受了TDD(Test-Driven Development)和executable specification等蛊惑，觉得文档可有可无，spec也完全可以被脚本script代替。
至于是否真的可以不写test spec，我的答案很简单：it depends（又一句政治正确的废话）。任何事情，脱离了语境(context)直接下结论，都是耍流氓。就我所在的团队而言，个人觉得现阶段test spec还是不可或缺的。原因如下：
- 通过spec消解测试复杂度。现阶段我们进行的是软件系统组件测试，需同时兼顾信令面和用户面的需求。对于信令面而言，消息繁多，而每条消息内部又有着成百上千个参数。不同消息之间的耦合，以及消息内或消息间参数的耦合，都导致直接阅读脚本会陷入“只缘身在此山中”的茫然感，而无法提纲挈地理解case用意；
- 测试框架和测试工具决定了脚本是否轻易可读。我们现在使用的测试工具基于Eclipse二次开发，GUI界面让手动测试(manual testing)非常容易上手。而带来的问题就是语法臃肿，调用库变得复杂，因此无法醒目地通过阅读“脚本(scripts)”，去了解该case的目的和重点；
- 保证信息交流低误码率。我们的test case往往不是测完就丢弃的，在手动测试后需要加到Continous Integration上进行自动化测试。而往往一个case在整个生命周期内，会经手好几位同事。因此同事之间就不能只是通过简单的口头交流进行任务交接。一份清晰的文档可以省却许多口舌之争；
- 通过spec的撰写更进一步地理解需求。对一件事情的看法，人们脑子里想的，嘴上说的，和最后写出来的可能都不一样。而以前也常听人说“某人很厉害，可惜了，肚子里有货倒不出来”，暗示某人不善表达。克服这一点最好的办法，就是写出来：如果自己都无法说服自己，那就说明理解得不够透彻，或者根本就是理解有误。我现在每周固定一篇blog，也是强迫自己在有限的时间和文字内，表述清楚一件事情；
- 搭建需求和测试间的桥梁。如能在这一步就分析清楚可测性以及合理搭配测试步骤，到“测试执行”时就不会无目的的乱试，大大提高测试效率。这也是大家常说的“磨刀不误砍柴工”；
说这么多，那一份好的test spec要具备哪些特征呢。个人觉得：
- 简洁。该有的都有，不该有的一个字也不要提。尽量减少文档工作的时间，重点放在测试方案的制定上；
- 清晰。不要出现模棱两可的词句，这样会增加tester的理解成本。更不应出现诸如“该步骤测试结果请参考需求文档”这样的描述。否则大家就可以不用test spec，直接看需求文档好了；
- 目的明确。spec是测试用例的guideline，要把握好细节和提纲之间的trade off；
- 尽量减少错别字和语法错误。有些typo可以理解，但如果满篇都是错别字文法混乱的话，那就不可原谅了；
总的来说，我不赞成在文档上花费太多时间，宁愿花时间在思考测试方式和步骤上，但同时，最后输出的spec一定要有可读性。至于spec的后期更新和管理，也是一个纠结的话题，以后再聊。