敏捷宣言里面有这么一条：“个体和互动，胜过流程和工具”。我非常喜欢的一句，当然了敏捷宣言总共就那么几句，总结都是非常精辟和智慧的，每一句都值得细细品味，就不展开说了。
这里的流程和工具显然是直指前面我们提到的缺陷管理系统，所以在敏捷开发模式下我们很少看到有人使用CQ的（有很多项目号称已经敏捷了，但还在继续使用CQ这种重量级缺陷管理工具的，不计），测试人员和开发人员以及PO的交流更加紧密但轻量化。
这里把本文中的敏捷开发模式限定为最流行的 scrum + xp，scrum本身并没有要求团队一定要设置独立的QA角色，但实际上在传统开发模式往敏捷转型的时候，原来独立的测试人员都会被要求“测试前移”成为团队中独立的QA，所以从瀑布开发模式下转型敏捷的团队多半会设置独立的QA，特别是在比较大型的组织。
以scrum为例我们先看一看敏捷团队中QA在迭代的不同时机和不同的角色是怎么发生交互的，个人觉得这个是敏捷模式和传统模式下最大的区别。
QA与团队的交互
迭代n-1
在这个迭代中，QA需要和PO一起完成下个迭代用户故事的准备，理解PO优先级排序的思路，确定每个用户故事的验收条件，一般这个时候一名合格的QA已经对这些用户故事的测试重点和风险有了一定的了解。有的团队没有设置独立的QA角色，那么这些工作就主要落在PO的头上，或者开发团队安排1-2个人，个人更倾向于PO来做这部分工作，因为定义用户故事的验收条件，确定开发团队的输出满足自己的期望本身就是PO的分内之事(我想这也是scrum为什么没有要求一定要设置QA角色原因)。
迭代n
迭代启动之后，在Planning Meeting上QA会参与用户故事的估算，特别对于测试部分的任务如果存在理解上的偏差时需要进行澄清，对验收标准进行说明，以帮助开发人员正确理解用户故事的意图和边界并做出准确的估算。
在迭代开发过程中，QA会进行FT用例的设计和编写，在需要时解答开发人员对用户故事细节的疑问（其实也是PO的职责，主要一般PO会比较忙很少在座位旁），优秀的QA还会参加集体代码走查，或者通过独自走查的方式来识别代码中的设计缺陷或者风险。
一个用户故事开发完成，QA需要和PO一起(这里又看到PO和QA角色的重叠)对用户故事进行验收，QA还会对用户故事进行探索性测试（可能还有性能测试等）并反馈给开发人员进行修正，一般来说QA和开发人员是当面沟通，如果实在需要记录bug也会直接采用便利贴、Jira等轻量级的工具，一旦开发人员修复了bug，QA则会立刻和开发人员一起进行验证并关闭bug。
迭代最后一天，QA通常还需要准备本迭代的Review，虽然Review会议也可以让其他人来准备，但如果有专职的QA的话让专职QA来准备是更加合适的。Retrospective Meeting上开发人员和QA都可以反馈测试方面的问题，比如CI环境的稳定性，CI的修复速度，验收标准是否明确，测试执行的是否有效，是否需要更新当前使用的测试技术，有什么问题阻碍了测试任务等等。
度量
在《敏捷软件测试》中对于测试的四象限以及各种象限下如何评价进行了详细说明，针对不同的测试类型会采用不同的度量指标，tbd
开发人员对测试的参与
对开发人员来说一个最大的不同是对 UT 的投入，如果要开发一个内部质量靠谱的产品，UT是不可或缺的，按照google的说法，ut/ft/st的比例应该达到 7/2/1，可见ut的重要性。比较好的团队会坚持采用TDD的方式开发，保持比较高比例的代码覆盖，也会带来良好的设计，这是另一个话题这里也不展开。
比较严谨的同学可能会说，即使是在瀑布式的开发模式下我们也可以做 UT，也可以做测试分层啊？我也不太确定UT算不算是XP实践，不过以我个人这些年的经历来看，在接触敏捷之前还真没有写过UT（可能是我所在的公司比较low吧）。
总结下不同点
这里可以看到敏捷开发模式下，测试和开发为了同一个目标在同一个团队中工作，他们的关系是合作而非对立，在这个前提下，测试能够真正回归到原本的那个目标，我们得以回归理性，更加客观的来选择测试策略和进行更高效的测试，比如度量指标可以更加科学，不必沦为不同团队利益博弈的筹码；通过不停的迭代和改进，测试人员的技能和团队其他人员一样能够逐步提升，比如最新的测试设计方法的运用，测试工具的使用，自动化的运用，这些新的知识会给测试人员带来成就感并帮助他们以更高效的方式工作，不仅仅是人肉测试机器；测试人员在组织中获得和开发人员一样平等的地位，获得相同的尊重，而且，就像前面我们提到的一样，QA的角色和PO的角色有很大部分重合，优秀的QA是整个团队中对产品理解最深刻的那个人，就像《google软件测试之道》一书中所说的，QA职业生涯的下一步就是产品经理。
说了这么多好处，看起来只要我们按敏捷的开发模式做下去就好了，那为什么还有标题里提到的敏捷转型失败之道呢？我们继续往下面看。