QA，从1.0到4.0

迄今为止，敏捷开发方法在各个公司都有了长足的发展，曾经的测试人员慢慢的在向QA职能过渡，但依然很多人不了解QA和测试的区别是什么。

敏捷实践不断地演化过程，使项目中各个角色不断弱化，同时，对每个成员的要求也越来越高。“全功能团队”的提出，不单单是对开发的要求，对QA来说，想要在快速变革中具备竞争力，就现在所具备的技能来说，还是远远不够的。

简单聊聊我所经历的“QA发展史”

QA 1.0 —— 机械化流水线作业

在我实习的那年，软件领域还很少提及QA，伴随着瀑布模型的兴起、软件工程规模的不断扩大以及市场对软件质量要求的提高，催生出了“测试工程师”这样一个角色。那时他们的职能很单一，每天的工作就是在各种测试环境中按照详细设计的文档，编写测试用例，并逐条测试，检查功能完整性，发现软件中可能出现的功能缺陷，并进行追踪。

这个时期是软件测试的原始时期，对测试人员的技能要求不高，只要对文档理解透彻，做事细心，是很容易胜任的。此时的产出和交付物可度量，虽然如此，测试工程师只是执行者，能力和价值都无法最大化，却被每天重复的工作所累。

QA 2.0 —— 过程化带来不同的工作内容和价值体现

我毕业的时候，开始接触敏捷方法，团队规模从百人变成了仅有十人左右，信息平等取代了逐级传递，分散的信息源（ 客户的每一封邮件和每一句对话都可能是我们将要做的功能 ）取代了几十甚至百页的文档，测试不再仅是提出软件缺陷和编写、执行测试用例，而是成为了团队的数据库和字典。

当用户提出一个功能的时候，测试人员可以快速的进行需求分析，回顾并确定是否与此前的功能有冲突。当开发人员对某一块业务不了解的时候，测试人员也可以组织会议进行阐明。由于对业务和客户的深入了解，测试人员可以为客户提出建设性意见和功能，有时也会是做出决策的人。

高效、频繁的沟通，大大提升了QA的软技能。此时的测试人员已经过程化，对软件质量的理解，从“发现缺陷”提升到“对软件开发过程的质量控制和风险预估”，我们定义这样的测试工程师为QA。

QA 3.0 —— 自动化技能提高生产力

随着工程实践的日益成熟，QA的角色和工作日益复杂，这使得他们在大量重复、繁杂的工作与更有意义的角色之间频繁切换，这对软件质量也产生了一定影响。

QA从开始的手工测试、探索性测试等手段，逐渐发展成为可以利用工具和程序对测试进行快速的回归，对软件性能进行有效监控，无论是前端还是后端、web应用还是移动平台。这使得自己从繁杂的重复性工作中解脱出来，去做更有意义的事情。他们通过项目的积累以及团队成员的帮助，对测试技术有了一定的认识。

QA 4.0 —— 角色向多技能、服务化转型

记得几年前，前公司领导对我说，“不管开发换了什么技术栈，你做的自动化框架都可以继续使用，对你来说没有任何影响。”当时我也赞同，认为框架已经足够好，可以适用于任何场景和业务。

从某个角度来说确实是这样， 测试相对于开发技术的指数级发展，平稳的太多。不论是在互联网还是移动互联网时代，缓慢的发展速度给了我们一种太平盛世的错觉，似乎我们掌握的技术足够坐吃几年。

来到ThoughtWorks之后，我发现了类似的事情，不论是在交付还是咨询的过程中，会有意无意中推一些我们认为的最佳实践，当遭到客户质疑和challenge的时候，我们似乎很沮丧。

在北京出差的日子，有幸做了一次咨询，虽然只有几天，让我学到一件事，我们认为的最佳实践和方法，并不完全适应于所有场合，尤其是在我们这样的咨询公司，对客户实施怎样的方案，取决于客户的领域、产品/项目特性、用户群、技术水平、政治文化、技术栈以及目标和期望等等。

如果对于“最佳实践”过于坚持，也会影响客户关系和咨询效果。之后咨询同事讲的几个故事也似乎让我认识到，虽然我们对现在的工作和技能足够的熟练，但依然不够。

我们似乎还需要具备以下的能力：

1.尝试用不同的方法写“茴”

经验丰富的QA对于测试技术中的关键点都烂熟于心， 除了我们正在使用的方案和技术，尝试用不同的语言、框架去实现关键点和难点。这样的好处在于，我们可以通过深入的学习和使用，对流行方法、过程和框架进行比较，了解各自的优势和劣势，不但可以增强自身的技能，当面对不同客户的时候，也可以给出客观的分析，为客户提供精准服务，同时如果可以对客户现有的技术和方案、流程和方法提供有价值的意见，也可以提高在客户现场的生存率，轻松俘获客户。

2.If you cannot test it, dev it.

软件过程中，QA可以在需求分析和定义阶段介入，为项目提供不可估量的价值，但另一方面，QA技能实践（此处指Tech）是一个相对受限的领域，我们很难绕过未实现的代码和工程去做更多的事情。

你可能会说，“没有做过mobile的项目，如何去学习移动端的测试技能？”如果恰好你对行业的发展具有前瞻性和敏感度，例如你可能认为IoT和VR是一个趋势，你却没有机会去这样的项目中做QA。

那么我们是不是可以像开发一样，提升自己的学习能力和适应力，保持对技术的敏感度和热忱，了解不同技术领域，对该领域的开发、测试、构建和集成部署都有一定的了解？所以，如果你想比其他人走的快那么一点，go dev!

3.真正的全功能

QA的领域虽然相对受限，但幸运的是角色相对不受限。在日常的开发过程和项目积累过程中，不但能对业务有深刻的理解、对用户行为有独到的见解，而且对技术也有一定的认识。

在需求分析过程中，QA总是可以从技术和业务结合的角度扮演好一个BA的角色，成为一个优秀的PM，甚至我们可以在客户提出一些需求的时候尝试着从一个UX的角度去设计原型，如果具备前端的能力，也可以自己去Dev、UI，不断拓展自己的技能领域，使自己成为真正的全功能。

总结

真正的全功能，并不是单纯意义上让QA去做Dev，而是最大程度弱化角色的概念，逐步强调和培养技能多元化。如何把对需求的理解能力强化为业务分析能力，把质量控制能力强化为项目管理能力。强化自身的优势，跳出自己的舒适区，使自己能够轻松胜任。这样我们才不会在看到去QA和QA消亡之类的观点后，无所适从。

更多精彩洞见，请关注微信公众号：ThoughtWorks