使用敏捷开发一开始会遇到的大问题, 我认为是测试. 因为开发还能基本按照瀑布式继续走. 不过是多了一些会议, 再把开发时间缩短些, 似乎还能凑合过去. 而测试呢? 如何凑合呢?
传统的测试模式
我们先看看以前的测试都是怎么回事先. 传统的测试团队有点像是警察, 比如我们公司的测试团队会把自己叫做 "Teminator" ^_^ 它们独立于开发团队，他们是质量的最后一道防线：
- 核查需求确保其正确并可验证
- 根据需求编写测试用例
- 等待开发团队提交稳定测试版本以后, 封存版本号, 进行黑盒测试
- 记录并分析 Bug
- 决定是否可以 Release
因为和开发团队相对独立, 不成熟的开发人员会有把 QA 作为质量的保护者的想法, 只需要提交给测试人员就好，而主观上放松了对自己coding的质量的关注.
敏捷里的测试原则
Kent Beck 在 Extreme Programming Explained : Embrace Change 对测试相关内容提到下面一些原则:
- 必须要对容易被破坏的代码做自动化测试
- 程序员对方法逐个写单元测试，他们要用测试保证代码逻辑的正确，易于重构
- 客户对Story逐个写功能测试。他们要在代码完成前思考如何验证功能是否完成（客户通常无法完成代码编写，所以通常不论任何大小的敏捷团队都需要至少一位专职的测试人员，他的工作是把客户的测试用列转化为代码，并以客户的测试为基础构建更多测试）
所以他的实践是, 测试人员是开发小组不可区分的一部分, 这个角色相对来说更关注项目测试的方面. 需要有一定的编程能力, 但是不是一定要有和开发人员相等的技术水平, 因为开发人员会承担大部分测试代码的编写. 而测试人员会更侧重功能测试的开发. 使用更容易的脚本语言已经能满足需要. 但是测试人员会对所有的测试代码负责, 他们要定期经常的查看所有测试的结果.
实践中的问题
测试是否需要编码能力?
他们具体需要什么技能是仁者见仁, 智者见智的问题.
可我们遇到的情况是, 我们把测试人员按照每个小组配置, 所以每个小组有自己 Dedicated 的测试人员. 他们的工作是负责 verify 提交的story, 做一些黑盒测试, 检查代码规范, 决定是否release ... ... 可由于缺乏编程的基础, 在有些时候感觉无法真正的融入团队. 因为开发人员承担了大部分测试, 剩下"把关" 这个相对简单的任务, 需要一个有经验的人来做吗? 实习生就能很好的完成这个工作了. 如果再赶上需要一段时间 research 新技术的特殊时期, 测试人员会更是百无聊赖, 没有适当工作能做. 于是他们像是半个人嵌入了开发团队一般, 无比的尴尬. 如果是以黑盒测试为主的测试 , 用瀑布式集中安排设计测试工作反而效率效果都会更好. 可以考虑在正常开发编制外设立独立的 "警察" 机构.
我们需要的是 QA 还是 Tester ?
另外一个有趣的问题是, 在敏捷开发团队中其实只有 Tester 这个角色. 而公司定义的职位确是 QA.
对质量和过程改进的关注, 毫无疑问是不可缺少的. 但很难说没有和 Scrum Master 这样的角色重合. 当然如果有人需要特别关注这个领域, 那么其实对 QA 们提出了更高的要求, 他们不能只是对这列表检查是否满足了这个要求那个要求. 如同 Scrum Master 是 Coach一样, QA 也应该是 Coach. 否则 Scrum Master 应该已经足够了. 抛开对流程方面关注, 他们需要更多的 :
- 关注编码，例如评审设计
- 程序员同样关注质量，特别在代码的质量，包括是否符合需求，是否可以自动测试. 能对如何写出好的测试对开发人员给出指导
- 在客户很难和Team工作在一起时，QA更多承担customer proxy
如何获得满足敏捷要求的 QA / Tester ?
其实要做好 Agile Tester 或者 QA 要求不低, 一点都不比做敏捷的开发人员来得容易. 既要有良好的沟通能力, 又要有测试知识的专长 还必须要有一定的编码能力.
除非开发转测试, 就对技术的要求在国内, 可能就能拍死一大片人. 但要做好敏捷, 我认为绝不能放低要求. 如果要做到快速的迭带开发, 测试和开发不能相互提高, 做好平衡, 几乎是不可能的.
招不到人, 只好自己培养了. 很高兴看到我们已经开始准备实施这个计划, 我会继续关注这个实践的结果.
题外话, 如果真的把 Tester 做好了, 不是很有前途的工作吗? 目前国内测试比开发 "低人一等" 的囧况, 随着敏捷的继续发展, 或许是可以慢慢改变的, 它会慢慢逼着测试人员稳步提高. 不能跟上步伐, 可能会被淘汰, 会有更多开发转测试或者直接没有 Tester 这个职位, 因为我们只需要 Test 这个 Role. 完全可以由开发人员兼任即可. 而我们用了这么些年的传统测试团队, 在使用敏捷的小公司可能很难生存, 但在大公司或许还能寻找到新的空间.