软件测试向敏捷要什么？

　　敏捷软件开发与其他软件开发方法学大的区别，在于敏捷是承认并拥抱变化的。为了这样的变化，敏捷的不同方法，比如极限编程、Scrum引入不同的技术实践和流程，像持续集成、测试驱动开发以及短迭代周期等，来确保即使在需求的快速变化下，也能保证交付的软件总是满足用户的需求，是高质量的价值交付。

　　从敏捷软件开发宣言来看，并没有涉及测试的内容，更不用提为QA即测试人员提供指导性的建议。是以极限编程的14个推荐实践来看，表面上对于测试的提及也只是验收测试，甚至没有敏捷测试这个概念。这样让很多人一度认为敏捷软件开发是不是之以程序开发为导向的，是不是我们测试人员能从敏捷获得的直接支持少之又少，我们是不是被遗忘的一个种群？

　　答案必然是否定的。还以极限编程为例，除了验收测试以外，极限编程提及的完整团队、用户故事、短交付周期、持续集成等实践，都在从不同的维度对于测试工作的流程和方式甚至对它思考的角度提出了变化的要求。

　　完整团队从文化氛围和组织结构上明显区别与过往的测试人员参与感，测试人员不再是对软件系统质量负责的角色，对质量负责的是全体团队成员的职责。用户故事改变以前对于软件系统功能和模块的划分，而是从交付的独立价值出发，改变了测试人员对于测试案例准备和验收的方法。短交付周期，无论是两周还是四周，都给整个团队带来了巨大的变化，开发和测试不再是独立而又顺序的过程，开发和测试互相穿插，成为一个快速反馈的过程。持续集成是软件系统开发过程的晴雨表，其中价值相当大的自动化测试仍然和我们的测试工作脱不了干系。

　　可见，敏捷和它的方法，虽然没有显式地给测试工作以指导建议，但隐式地要求了我们测试人员仔细思考测试本身在敏捷项目中所需要发生的变化，我们测试人员的职责和工作范畴发生了哪些变化。

　　与敏捷开发一样，敏捷测试针对不同的项目上下文和不同的团队组成和背景，有不同的适配模式。跟敏捷软件开发的宣言类似，敏捷测试也有一系列可以恪守的原则。经过不断实践和经验，ThoughtWorks的同事同样提出了《敏捷测试宣言》：

　　1、Collaborative ownership over detached objectivity

　　2、Targeted automation over widespread anti-regression

　　3、Defect prevention over defect reporting

　　4、Exploratory testing over predetermined scripting

　　第一点与完整团队有关。虽然独立的测试团队可以从外部视角观察软件质量，但真正的软件质量来自测试人员属于一部分的完整团队，不再区分彼此的开发团队和测试团队，不再有彼此分离的目标。整个团队为软件质量和客户价值共同负责。

　　第二点针对性自动化测试胜过广泛的回归测试。随着软件系统开发的进展，后期引入的新功能和缺陷都会带来大量和重复的回归测试，自动化测试是代替人工繁琐而无聊的回归测试的办法。

　　第三点提到的如何对待缺陷恐怕是时下各个测试团队为纠结的内容了。预防缺陷胜过报告缺陷，预防缺陷才是测试工作大的价值所在。敏捷测试会尽早介入软件系统的开发过程，和业务分析师、客户分析需求和价值所在，以用户故事和验收条件来驱动开发，以短周期迭代和持续集成为反馈，可以尽早发现存在的缺陷，从而极大降低后期才报告以及修复缺陷所带来的高额成本。在我的团队，测试人员甚至可以和开发人员结对，共同确认缺陷根源，修复缺陷，并添加自动化测试确保缺陷不会再次发生。

　　第四点的探索性测试的重要性没有人会怀疑，测试人员可以凭借自己的经验积极、自由地发现质量问题，而不仅仅是反复运行已经定义好的测试。这样可以证明软件不仅仅做了它该做的事情，还证明软件没有做它不该做的事情。