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

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

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

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

 

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

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

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

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

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

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

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

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

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

所以1和2两条的推论就是开发效率提升。

 

敏捷测试的人作什么？

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

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

3. 不断提升开发人员开发功能而非处理缺陷的时间（即便缺陷是开发人员本身制造本身修改）。

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