新时代的QA角色：IT全能战士

故事开始于客户告诉我的一个反馈：ThoughtWorks成都的一个项目组，最近这段时间开发工作量变多，于是担任QA角色的某同学自动转入开发模式开始写代码。不仅自己写，还拉上远在墨尔本的客户QA一起远程结对。两个QA结对开发，效果出奇的好：代码质量毫无问题，而且对需求理解充分透彻，story完成得又快又好。

客户表示很惊讶，同时也看到这种多技能跨角色人才可以带来的巨大收益。他说，他想在自己的团队里也推广这样的实践。

为了理解这个故事的意义，我们需要回想IT的原点。最初，计算机的用户都是专家，他们自己定义问题然后自己解决问题。后来，不能以图灵机的方式思考的普通人开始使用计算机，于是IT服务的提供者们成为了物理世界与数字世界之间的桥梁。说到底，整个IT行业的价值所在，就是解决这样一个 NP问题 ：

给定任意一个物理世界存在的问题，将其转换为一个图灵机可计算的问题，或指出其不可计算性。

这个不那么通俗的定义，用比较通俗的方式说出来，就是 Design Thinking ：物理世界存在的问题往往以“谜题”（mystery）的方式被提出；而为了用任何形式的机器来解决一个问题，我们需要“算法”（algorithm）；然而获知一个谜题是否有一个算法可解的过程，根据图灵的论文，本质上等价于 希尔伯特第十问题 ，也即是一个不可能用机器解决的问题，因此这个过程需要人类的“启发式思维”（heuristic）。

说得再简单点，IT服务者的工作，其最大价值不在于 解决问题，而在于 定义问题。

定义问题这件事之所以如此困难，因为这个世界上的大多数人并不了解计算机。他们（通常被称为“客户”，其实计算机魔法学校的学生们都知道这只是“麻瓜”的一个客气的称呼）脑子里冒出的想法是含糊的、模棱两可的、未清晰定义的、不一定能被计算的。而IT服务者的职责就是（1）理解这些模糊的想法，并（2）为这些想法找到可以被普通人理解的计算方案，或者（3）以普通人可以理解的方式说明为什么这些想法不能被计算。

所以，作为物理世界与数字世界（麻瓜世界与魔法世界？）之间的桥梁，IT服务者（以团队的形式）必须同时具备与普通人打交道的能力和与计算机打交道的能力。很长时间以来，这两种能力归属于IT团队中不同的角色，两类角色之间高昂的沟通成本在漫长的交付过程中尚且可以容忍。然而互联网时代要求更短的交付周期、更快的响应能力，于是IT行业开始呼唤既善于与人打交道、又善于与机器打交道的全能战士。

有趣的是，当我们向现有的角色划分里寻找这样的全能战士，我们发现最接近的角色是QA。这个角色需要和客户直接对话，弄清客户那个含糊不清的故事究竟应该用哪些明确的标准来验证，然后再拿着这些标准来检查要交付的软件是否符合。不知不觉中，QA们既能使用商业的语言（保单、免赔、拒绝承保⋯⋯）、又能使用技术的语言（URL、服务器、部署⋯⋯）。于是，我们也就不再惊讶，当这个团队出现 多能工化 的诉求，首先响应的是QA。

（胡凯在 他的文章 里也同样谈到了全功能团队的价值。）

另一方面，QA对于“验证”的重视也恰好与ThoughtWorks对“最后一英里”的重视暗合。回望过去ThoughtWorks取得的重要技术成就，其实大多与“验证”有关：Selenium、Watir、TDD、CruiseControl、持续交付⋯⋯因为验证才是对问题的 定义，而如今在快速变化的市场中打拼的客户所面临的最大挑战往往是清晰地 定义问题。因为这种既能理解人又能理解机器的特质，QA们往往能最好地定义问题。

然而传统的QA定义——很多时候就是“人肉回归测试机”——不仅没有体现出我们所期望的“multi-skilled”，往往倒是走向一个最差的结果：“multi-non-skilled”。“叫你写程序吧，你又不会写；叫你泡客户吧，你一说话就脸红。算了，你还是做测试去吧。”这种不负责任的态度让很多IT从业者都把QA当做职业发展的最差选择。我真的希望，我们能改变这种状况，让QA成为这个行业最领先的全能战士角色。

P.S. 最近和 小朋友 结对做QA，教了他很多犄角旮旯的事情。一个星期里用三种不同语言编程（算上 Selenese 的话就是四种），谁说QA不是个有趣的工作？