给开发测试者及操作bug修复者多一点时间来完善软件，能为一个敏捷组织提高IT效率。

敏捷开发者及DevOps专家通常使用封装好的预定义测试脚本，实际上，敏捷爱好者将这视为敏捷开发的一部分，这种技术还是个争论。但是，探索性测试又是以往老套开发程序的关键性突破，是整个敏捷IT成功因素的一个组成部分。

《敏捷最佳实践》与传统的IT效率观点不一样，它强调让开发者在一个项目中多安排时间来学习，而不是让他们加班做其他项目，而推迟本项目的一些测试。

传统的软件测试是封闭的，使用生搬硬套的方法来测试一段代码的所有部分。这些方法，说白了，完全测试不到一个应用的所有操作环境——尤其是一个经常升级的应用程序。相比之下，探索性软件测试跳出了沙盒的环境，能发现不寻常环境及操作方式下的问题，这些是老式测试无法做到的。探索性测试者目标在于找到代码不对头的地方，从而指出错误所在。

一些没有整体敏捷IT目标的探索性测试信徒提出，过份地强调这个技术只会浪费时间和金钱。非也，因为敏捷开发过程参与进了与客户反复沟通的过程：“我想要这个。好。那这个也给我加上？”事先准备的测试脚本无法处理所有新功能的测试，就是这么简单的道理。所以，探索性测试要用所有可用的脚本来进行测试，密切地反复和敏捷开发过程相匹配。

探索性测试参与了完整的管理和持续的开发过程。测试员不是被动地只对程序员的大段代码做测试并反馈，而是主动地想方设法来干掉它。

对于敏捷探索性测试目标最大胆的延展，莫过于对应用程序的敏捷方面进行测试：敏捷探索性开发与运维。管理者要灭火的同时，也要主动想办法在问题发生前把代码隐患都消除。这需要“操作沙盒”来进行测试。

上线，底线和风险

敏捷探索性测试带来的好处与敏捷开发、问题修复和自身升级密不可分：

• 敏捷并不侧重于成本控制，但能比以控制成本为目标的开发项目减少20%到30%的成本。
• 敏捷不侧重于利润和投入回报，但能比盈利为目标的项目增加20%到30%的投资回报率。
• 敏捷不侧重于风险控制，但相比以质量为目标的项目，能提高20%到30%的质量。

敏捷不断以客户反馈为基础重新定义项目目标，而预定义客户需求的方式要缩短功能列表来实现程序最终发布。

敏捷探索性软件测试为敏捷开发过程提供了保证及支持，其中的程序员代码需要先快速通过探索性前期警示测试，然后这些代码才能作为“管家”进入全脚本的集成测试过程。

敏捷探索性测试特别适应《敏捷开发实践》中所称的“深入其中”开发，程序员先着手底层的软件架构，然后在上层为应用功能添加模板，之后在基础架构上创建额外的架构来为模板功能提供小程序。反复的沟通来设计功能和通用的架构是必须的。敏捷探索性测试直到开发任务完全定义好了才开始，临时性测试则在反复沟通中使用改良的脚本来完成。

将重点放在创新

敏捷探索性测试相对于将测试员当成高可控性、全面优化的安全带而言，更适应商业需求。根据《斯隆管理评论》，偏重于创新的企业，比那些偏重成本的企业能做得更好，这观点对IT部门也是成立的。

敏捷探索性测试要求测试员必须创新，测试员需证明他们对代码的价值要超越单纯修复bug。这样的结果就是一个更有创新力的应用程序。

敏捷探索性软件测试使敏捷开发和运营工作在更佳状态，更快速及更廉价，但这还有个文化冲击，我们发现敏捷开发者的低效率，但也只有学会接受低效率，才能获得真正的回报。

只要测试还不是你重要性排名的首位，那就应该将敏捷探索性测试加进来。拿一个应用程序来做生命周期管理，用一个沙盒来做敏捷探索性测试，然后与敏捷开发集成并在开发运营框架中引入探索性测试工具与培训。敏捷探索性测试所用掉的时间，足以抵消在日常IT灭火所消耗时间，同时还能提高质量和客户满意度。