Q: 之前会有一个阶段， 是一组相关的特性开发完成后， 测试人员接手测试， 几轮Bug修复过去后， 产品基本稳定可以发布了. 现在测试人员提前介入到每个迭代中， 针对单个特性进行测试， 那如何保证产品集成起来的质量?

　　A: 跟以前一样， 该有那么个集成测试阶段还得有那么个集成测试阶段， 取决于产品当时的质量状态. 并不是说有了迭代级别， 单个特性级别的测试不需要发布级别的集成测试了， 两者没有任何矛盾.

　　Q: 那么测试人员提前进入迭代有什么好处?

　　A: 尽早发现问题， 降低修复错误的成本. 有几种手段， 一是前面提到与业务人员和开发者一起讨论验收条件， 这样能防止理解偏差而导致的返工. 二是开发完成立即测试， 发现问题立即反馈， 这样开发人员对代码依然印象深刻，能快速定位和修复错误. 这样流入后集成测试阶段的Bug会少， 会缩短后的集成测试时间， 保证产品更平稳的发布.

　　Q: 有时候后续的特性会影响前面的特性， 那么迭代过程中测试人员只测单个特性， 怎么保证以前的特性依然工作?

　　A: 几个手段. 测试尽量自动化， 以便能够持续集成. 再是做好依赖管理， 每当一个新特性完成， 应该能够发现它影响的其它特性， 看看是否应该补充一些集成测试.

　　Q: 有时候开发人员完成一个特性时已接近迭代结束， 测试人员没有时间进行充分测试， 怎么办?

　　A: 下个迭代测呗， 并且在计算开发速度时， 只应该计算本迭代通过测试人员验收的特性， 那些仅仅是开发人员完成， 没有经过测试人员充分测试的特性不计在内. 这种情况是不可避免的. 但我们能通过一些手段让测试与开发更加同步， 尽量缩短滞后性， 包括让测试人员与开发人员更紧密合作， 尽量让测试用例自动化等.

　　Q: 我还是觉得在开发迭代过程中， 测试人员的工作量不饱满.

　　A: 如果这不是您的感觉， 而是事实， 并且前面测试人员必须要做的工作也都做了， 还是不饱满， 那么恭喜你， 可以省下一些测试人员， 去做别的事了. 但不推荐的是， 不要让测试人员同时为两个团队工作. 这会大大增加沟通的成本. 你会经常发现， 当你的开发者想找测试人员协助时， 却找不到人了， 于是你的团队便被堵塞在那里. 而测试人员本身的Context切换也是痛苦的.

　　Q: 你们说验收测试应该由客户来编写， 可在我们这里根本不可能.

　　A: 验收， 当然是由客户来验收， 这在理论上是毫无疑问的， 而且肯定在各行各业发生着. 只是具体到测试用例的编写和执行， 无论是自动化的还是非自动化的， 都需要掌握一定的技术， 需要周密的思考， 需要专门的时间， 客户可能无法同时满足这几个条件， 我们要尽力争取， 争取不到， 便只好通过更充分的交流来弥补越俎代庖的失真. 这时业务分析人员和测试人员要通力合作， 完成验收测试的编写.

　　Q: 你们说你们之前的项目产品代码和测试代码的比例大约 1:3， 这不是平白增加了 3 倍的工作量吗?

　　A: 是增加了 3 倍的代码量而不是工作量. 它节省了你几十人做几个月庞大的预先设计的工作量， 节省了你详细设计每个模块并为之编写几百页详设文档的时间， 节省了无数不眠之夜通宵Debug的时间， 它节省了集成阶段修复难以计数的Bug的工作量， 甚至它缩减了你产品代码的数量， 大量的重复代码被消除了， 大量过度设计的复杂代码被废除了， 你的代码更易理解了， 添加新特性更容易了， 发现的Bug更易定位了， 以致于大大减少了长达数年的生命周期内维护的工作量.

　　有点夸张了? 可这是 TDD 和敏捷开发带给我们的好处(如果你已经实践了)和vision(如果你还在观望)