这几天一直被年前一个事情所困惑: 在与一个公司的开发经理聊天时,他掷地有声地说: "我的团队采用了敏捷开发模式,我们已经取消了测试团队！". 尽管以前自己对敏捷模式有一定的了解和简单实践.但碰到敏捷模式下把测试团队砍掉的情况还是第一次!
春节期间和节后的这段时间里，自己一直在思考这个问题：敏捷模式下测试工作真的不需要独立存在了吗？如果能够独立存在，核心价值又体现在那里呢？
这几天在几个测试相关的群和论坛里也大致问了这个问题，大家众说纷纭，归纳及各类如下：
1、上面提到的开发经理的做法不正确，不应该取消测试团队，这样做风险应该很大
2、测试工作实际已经被需求、开发承担了，整个项目团队其实都在从事测试工作
3、也有人认为，这种架构在短时期内可能是工作的不错的，但长远发展，质量风险很高
4、...
作为从事多年测试工作的自己，感觉以上观点各有一定的道理，但都没回答关键的一个问题，敏捷模式下测试的价值是否可以做到无可替代？如果这个问题分析清楚了，一切问题可能也就烟消云散了。
基于此，这几天又重新学习了一下敏捷模式的核心：
1、客户为中心
2、快速迭代
3、尽早开展工作
这三个核心理念指导下的开发模式大家称为敏捷开发，指导下的测试模式大家称为敏捷测试。这应该是比较流行的认识。但这个好像解释不了那位开发经理砍掉测试团队动力何在！
因此，继续思考敏捷模式下测试价值：再往前分析测试和开发分工产生的原因中能否发现测试的核心价值呢？
测试最早可以追溯到软件刚刚产生的年代，那个时候需求、开发、测试等没有明确分工，甚至没有专门的概念描述这几个阶段，那个时代的测试工作应该是程序员的“调试”，后来随着软件规模扩大、实现越来越复杂，人们认识到质量的重要性，测试作为保证质量的一个有效手段逐步产生了与从开发工作中独立出来，并产生了众多的专门测试技术、测试流程模式等。
基于此，测试的工作的独立和不可替代性是软件现代软件规模、复杂性越来越大的必然要求，即使出了敏捷模式也无法降低系统的整体规模和复杂性，但可能每个迭代循环中软件复杂性和规模降低了，因此，短期看，那位开发经理取消测试团队的做法目前工作的还不错。
不过，到了大系统集成阶段，这种取消测试团队的敏捷开发做法可能会带来一定的风险！另外一个风险可能就是尽管省掉了测试团队人员费用，但估计需要增加很多培训费用，需要给需求、开发人员进行测试理念的培训！
以上是自己对敏捷模式下测试工作价值的思考历程，与大家共勉之！
版权声明：本文出自 zhengxm_16 的51Testing软件测试博客：http://www.51testing.com/?80374
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
