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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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