做敏捷QA五年多，看到了很多人加入，也看到了很多人放弃。其中有经验丰富的测试人员，也有刚刚步入职场的新人。虽然“从入门到精通”是大多数人选择进入这个行业的初衷，但是敏捷QA一些特有的工作方式和要求，会让很多人不适应或者不喜欢，所以很多时候我们看到的是一个个“从入门到放弃”的过程。

那么什么样的人应该不要选择或者尽早放弃敏捷QA这条路呢？本文试图给大家提供一些参考。

敏捷QA入门

QA（Quality Assurance）通常指的是质量保障，也有一种说法是质量分析（Quality Analysis），在敏捷软件开发团队中，我们强调所有成员（业务分析师、开发人员、专职QA）为质量负责，所有人参与跟质量相关的活动，所以从宏观意义上来说，人人都是QA，很多文章都有相关的介绍，这儿不再继续探讨。本文提到的敏捷QA，指的是敏捷团队中专职的QA角色，他们的主要职责是主导并促使跟质量相关的活动在团队内发生，包括但不仅限于测试。

敏捷QA的入门阶段除了要有基本的测试知识外，必须要熟悉一些敏捷相关的基本概念以及实践，比如用户故事、迭代、迭代计划、回顾会议等等。敏捷QA几乎会参与整个用户故事的生命周期，从分析，启动，开发，验收，测试到最后的展示，尤其在启动，验收和测试这三个环节发挥着非常重要的作用。

另外，敏捷QA会同时工作在多个迭代当中，在进行当前迭代用户故事的测试验收等活动的同时，也经常需要做前一个迭代的收尾工作以及下一个迭代的准备计划等。

敏捷QA放弃

了解了基本的敏捷QA知识后，我们来看看放弃敏捷QA的四个理由。

• 不爱说话？别做敏捷QA了

如果你之前是安安静静专心找软件缺陷的工作模式，那么进入敏捷团队你可能会经历很长时间的不适应。

因为敏捷QA不能被动地等待软件完成交到你手里再做测试，不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入，在软件的整个生命周期中全程参与。

敏捷软件开发强调质量内建，在用户故事的生命周期中，作为质量保障的主要负责人，你需要在每个阶段跟不同的角色反复确认和验证，确保团队对需求理解一致，还要保证跟质量相关的活动发生，比如确保开发人员添加了相关的自动化测试等，所以你需要和团队的每一个成员以及客户有非常多的交流，而最直接有效的方式就是说话，沉默寡言是行不通的。

所以，如果你不喜欢说话，那么Tester也许比敏捷QA更适合你。

• 心态不好？趁早放弃

不知道你是否经历过这样的场景，在某些小餐厅等位严重的情况下，你需要站在某个快要结束用餐的客人边上等空位，而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。

虽然这种行为不是很好但也无可厚非，换个角度想，这种人的心理是非常强大的，因为很少有人能够不顾及别人而我行我素。而这种“能力”对敏捷QA是非常有用的，比如在故事验收环节，这个阶段就是业务分析师、开发人员和QA三种角色一起在开发人员的机器上验证用户故事是否被正确地实现。当然任何角色都可以主导这个环节，但效果最好的是由QA来主导，因为可以提前发现缺陷并快速修复。

但是因为这个阶段所有角色都会参与，大家关注点又有所不同，所以心态不好难免就会有各种顾虑，比如，自己会不会太慢了？会不会耽误太多人的时间了？别人会不会很着急？

太多顾虑就会影响你做验收测试，尤其验收阶段的探索性测试。从而使你不能充分发挥QA的作用，而这个环节对于敏捷开发模式下的质量保障来说非常重要，这时候如果具备前面提到的强大的心理素质，就能专注地按照你的想法测试你的场景，当然可以配合一些解释让别的角色了解你的思路，而不是左顾右盼思前想后影响这个阶段的发挥。

所以，如果没有强大的心理素质，也许应该考虑趁早放弃做敏捷QA。

• 对业务、代码没兴趣？敏捷QA不适合你

相信很多人进入测试这个行业，是因为对测试领域的技术和方法论有浓厚的兴趣，但是对于敏捷QA来说，仅仅对测试感兴趣是不够的。

敏捷QA需要对整个系统以及业务足够熟悉，这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分（可以在故事审查或者启动阶段帮团队澄清需求）。

另外如果可以具备一些编码能力，对于做敏捷QA也是非常有帮助的。当然，术业有专攻，并不要求每个QA都会写代码，但是要对代码有一定的兴趣，愿意听开发人员讲解他们的逻辑和实现，并通过提问题了解他们的思路，至少了解他们编写的测试代码。因为在验收阶段，敏捷QA会通过审查开发人员的自动化测试是否合理和全面，来帮助团队建立对自动化的信心。

所以如果对业务、代码没有丝毫兴趣，那么也许敏捷QA不太适合你。

• 不会管理工作的优先级？做敏捷QA很难

敏捷QA最大的挑战是，每时每刻都同时工作在很多事情上，我们可以细数一下敏捷QA的活动：当前迭代的故事审查、故事启动、故事验收、故事测试用例准备、部署、缺陷管理、缺陷分析，前一个迭代的故事收尾，后一个迭代的测试计划、故事审查、故事启动等等。

另外敏捷QA希望可以做的更多，比如日志分析、性能监控、安全测试等等。

可以看到，敏捷QA的工作是非常杂乱琐碎的，而且大多活动是和团队中不同成员一起进行的，我听过很多刚刚加入敏捷QA的新人抱怨没有自己思考的时间，忙乱没有目标；也见过很多优秀的测试人员转做敏捷QA后因为不适应这种多线程的工作选择了放弃。确实，在这样一种工作模式下，如果QA不能清晰定义自己工作的优先级，就会被各种杂事牵着鼻子走。

不擅长管理自己的工作任务、不会划分优先级，做敏捷QA会非常难。

总结

敏捷QA，不管性格还是心态，都需要足够强大，否则在整个工作过程会非常艰辛；另外仅仅掌握专业的测试技能是不够的，还需要更多地了解业务甚至代码；最后必须能够管理自己工作的优先级，否则会事倍功半。

了解了这些方面后，可以认真思考一下，自己是不是真的适合做敏捷QA。如果依然坚持步入这个领域，那么希望我们可以一起从入门到精通。