敏捷测试与传统测试的区别

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。

一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。

在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。

 

在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而如果BUG很难复现，则付出努力最多的不是开发人员，而是测试人员。

在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。一个测试人员怎么能提高开发生产率呢？下面几个因素保证其可以发生。

1. 若缺陷发现越及时越容易修改。

比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个自动测试工具来以接近实时地发现缺陷。

比如如果在每天能进行一次持续集成，则集成测试不能通过的原因会很单一很容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制/发送/接收/分流/解密/显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。

2. 若发现缺陷的人就是制造缺陷的人，则越容易修改。

比如如果开发人员有自动测试工具能快速看看自己写的程序有没有问题，而不是交给测试人员发现，则更容易修改。想象一下编译器就知道了，如果编译活动都要委派给别人（最然现在很难想象，在软件开发的极早期其实就是这样的），效率会很低。

3. 一个开发人员花费在查找和修改Bug上的时间越少，则开发效率越高。

另外一个推论是：在0缺陷的产品上增加一个功能，比缺陷缠身的产品上要容易得多。

因此1和2两条的推论就是开发效率提高。

 

敏捷测试的人做什么？

1. 不断推进自动化测试的效率和效果。

2. 不断推进持续集成的效率和效果。

3. 不断提高开发人员开发功能而非处理缺陷的时间（即使缺陷是开发人员自己制造自己修改）。

当然有一个前提，就是每个软件对待需求/进度/质量/成本的目标和策略是不同的，敏捷测试人员不能有本位主义，不能片面追求测试活动本身的效果，而是应该帮助开发团队达成其目标和策略。