使用敏捷开发一开始会遇到的大问题, 我认为是测试. 因为开发还能基本按照瀑布式继续走. 不过是多了一些会议, 再把开发时间缩短些, 似乎还能凑合过去. 而测试呢? 如何凑合呢?

传统的测试模式

我们先看看以前的测试都是怎么回事先. 传统的测试团队有点像是警察, 比如我们公司的测试团队会把自己叫做 “Teminator” ^_^ 它们独立于开发团队，他们是质量的最后一道防线：

核查需求确保其正确并可验证 根据需求编写测试用例 等待开发团队提交稳定测试版本以后, 封存版本号, 进行黑盒测试 记录并分析 Bug 决定是否可以 Release

因为和开发团队相对独立, 不成熟的开发人员会有把 QA 作为质量的保护者的想法, 只需要提交给测试人员就好，而主观上放松了对自己coding的质量的关注.

敏捷里的测试原则

Kent Beck 在 Extreme Programming Explained : Embrace Change 对测试相关内容提到下面一些原则:

必须要对容易被破坏的代码做自动化测试 程序员对方法逐个写单元测试，他们要用测试保证代码逻辑的正确，易于重构 客户对Story逐个写功能测试。他们要在代码完成前思考如何验证功能是否完成（客户通常无法完成代码编写，所以通常不论任何大小的敏捷团队都需要至少一位专职的测试人员，他的工作是把客户的测试用列转化为代码，并以客户的测试为基础构建更多测试）

所以他的实践是, 测试人员是开发小组不可区分的一部分, 这个角色相对来说更关注项目测试的方面. 需要有一定的编程能力, 但是不是一定要有和开发人员相等的技术水平, 因为开发人员会承担大部分测试代码的编写. 而测试人员会更侧重功能测试的开发. 使用更容易的脚本语言已经能满足需要. 但是测试人员会对所有的测试代码负责, 他们要定期经常的查看所有测试的结果.

实践中的问题

测试是否需要编码能力?

[...]