随着业界对敏捷开发的逐步了解，经常有同事和朋友问我，你们现在敏捷里注重测试，所以每个人都在进行测试，甚至以前测试人员所认可的发展方向：自动化测试，都让开发人员参与了很多，那你们QA是不是会被取代呢？
听到这么一说，我真是猛然感觉到危机感，不过细想了一下，如果QA会被取代，就说明他／她的工作不重要或者不必要。既然这样，就还是从QA工作内容开始看看和分析吧：
- 让我们先从敏捷QA最早涉足的活动，业务需求分析入手。在业务分析阶段，QA可以通过自己的丰富知识，包括测试设计和分析的能力（例如实例化需求）来帮助业务分析人员以及客户发现遗漏的需求，以及从技术层面避免出现依赖等不合理的需求问题。
- 在开发过程中，虽然开发人员参与了不少的自动化测试的活动：单元测试和功能性测试等。不过这里需要说明的是：单元测试基本都是由开发人员负责完成的，更多的是侧重于代码中方法调用及模块调用这一层级的。而开发人员参与的功能性测试，更多的是从自动化测试实现方面出发的。究其原因，开发人员的编码技能一般来说都要熟练于QA。但是QA在这些活动中也在提供着自身不可替代的作用：根据单元测试，功能测试的完成度和覆盖率，更有指导性地规划项目中的测试金字塔；而且运用测试设计的能力，设计自动化测试的场景以及用例，以保证在最小最有效的测试场景和用例集中，完成尽可能高的功能场景的覆盖。我相信除非是像QA这样在测试设计方面倾注了很大的心血和时间，不然很难有能力设计这些架构和场景。而且QA也是可以写自动化测试的啊！
- 而在手动测试本身，基于自动化测试的覆盖力度，我们做得更多的是探索性的测试，而非基于明确的验收标准或者测试用例的验证性的测试。你也许会问那谁来做验证性测试，答案是开发人员、QA和业务分析人员一起在故事卡开发完成时来做的，而不是推到QA一个人的身上。对于探索性测试，QA采取了更有针对性和目的性的方法：根据对现有系统的理解和分析，归纳和总结出用户行为和功能点，然后以此为依据，开辟一段单独的时间，来对特定的行为和功能进行开放性的测试。这对于我们验收性的测试，是一种非常有效的补充。
- 在手动测试结束后，QA很多时候还承担了和客户沟通需求以及演示产品的职责，这样他／她们对于产品的认识有了更全面的了解，以及为什么需要这么做；同时客户对于他／她们的信任程度也提高了，从而更容易接受他／她们提出的建议。正因为这样，QA担任PM和IM也是很常见的。
除此之外，QA一般还会负责性能测试和安全性测试这些非功能性测试，以保证项目在各方面都有品质的保证。
在具体测试当中，QA发挥了关键的作用；在其他方面，QA也发挥了不可取代的作用。
- 首先，从项目整体上来说，对于项目部署和运维，QA也是很有发言权的。因为测试的过程中包含了这些部分。对于通过脚本部署产品，通过log分析和定位bug，QA对开发人员甚至运维人员都能提供帮助。
- 其次 ，在敏捷里，QA不仅测试的是产品本身，还需要对项目中的一切进行测试，这就包括了项目流程以及各阶段的分析工作。合理和优化的项目流程能帮助团队“更高、更快、更强”地达到目标，而QA有很好的全局观，所以很自然地会更关注于流程的优化。对于分析工作，敏捷的QA不仅仅是测试，更重要的是对现有结果进行分析和估计，有针对性地提出专业性的建议，便于项目组下一阶段目标的制定。
看到以上罗列的这些工作内容，有一个问题自然地会浮现在脑海里：“这么多工作，都是从理论上说的，QA能都做到吗？”答案你我都知道，不可能。实际项目中的QA能做到很大一部分已经很不容易了。但是就像其他角色一样，不可能在同时段时间内能做到所有的方面，但是我们至少知道了自己可以发展的方向，以及我们所特有的优势和技能。
敏捷中的QA因为要关注的方面更多了，所以有些可以代理出去的工作可以让其他角色辅助，而不必事必躬亲；但是我们自身所特有的技能，并不是能代理出去或者其他角色能轻易达到的。
如果下次有人在问我文章开头的问题，我会开心的告诉他：“欢迎你来取代我。”而他／她付出的会是“一万小时“的时间来成为QA方面的专家。到那时候，就不是取代我，而是成为我了。