测试人员的角色

以前，我是个开发人员。说真的，我一点都不喜欢那份工作——永无止境的压力让人身心俱疲。我几乎从来没有觉得自己的工作做得足够好，也从未真正体验过什么叫做“休息”。一旦出了岔子，要么是项目赶不上 deadline，要么就是发布了一个自己都不忍直视的产品。

后来，我转岗做了测试经理。说实话，那感觉就像在度假。

测试和开发比起来，边界要模糊得多——它给了你很大的发挥空间。最初，我的理解很简单：测试的职责就是找问题。

找问题确实不难，但时间一长，你会发现这活儿很难让人真正满意。我想让产品变得更好。

后来，我在 Apple 一个 400 人的团队里担任测试专家。团队的名字叫“软件质量保证”（Software Quality Assurance），所以我们花在质量保证上的讨论，反而比测试本身还要多。有位经理推荐了一本书——Philip Crosby 的《Quality Without Tears》（中文版叫《质量无泪》），它帮我们重新审视自己在产品开发中的角色。书中提到了“零缺陷”理念，我也因此转向了缺陷预防。“质量不是测出来的”，成了我们的口号。

那时，我认为测试的职责是保证质量。

但很快就会发现，测试人员其实根本没法“保证”质量。首先，完美的质量本身就是一个遥不可及的目标——质量有很多个维度，有些维度之间甚至是相互冲突的。其次，质量不是测试人员“创造”出来的，把保证质量的职责压在我们头上，本来就不合理。如果我们把自己当成质量把关者，团队里的其他人就更容易在质量问题上“甩锅”，他们会觉得“反正有 QA 在兜底”——结果产品不好，我们反而背了最大的锅。

更何况，很多 QA 团队主要靠定义流程和审查流程执行来发挥作用。问题在于，这种做法很容易变成空洞的质量说教，整天在“质量是好的、不好的质量是坏的”这种套话里打转，QA 所有的价值都被掩盖了。这也是为什么很多开发人员觉得 QA 就是耳边嗡嗡的噪音——只会让他们分心。

还好，我后来被人从这种招人烦的角色里解救了出来。经理把我拉到一边，告诉了我一个核心秘密：一切工作，本质上都是为了管理风险。不必追求完美，找到一个“足够好”的东西就行。这样一来，测试和质量保证就成了项目的雷达，专门用于识别风险。我们的目标，是在项目中快速找到那些真正重要的问题，而不是揪着每个历史阶段里的每个陈年旧账不放。

这个想法彻底改变了我。我不再执着于追求测试覆盖率的“全”，而是开始思考哪些地方真正需要测试，并评估那些未知问题的风险有多大。

考虑风险，也让测试人员在项目里和其他人相处得更轻松。关于质量的讨论，变成了判断什么真正有影响，而不是纠缠于谁想要完美。

那时，我终于觉得，测试的职责就是分析风险。

但后来我又意识到，风险这个概念依然很抽象，而且有点悲观。有位开发经理跟我说过，他不太喜欢谈论风险。“风险听起来太消极了。我们不是保险公司的理赔员，我们是企业家。企业家是敢于冒险的。”他这话有道理。对项目来说，回报才是最重要的。难道测试就找不到一个更全面、更积极的视角了吗？

当然，测试的目的确实在于发现问题、分析风险、保证质量，但还有一个更本质的方式来看待我们的职责：我们是在为团队照亮道路。没有测试，项目就像在黑暗中横冲直撞，被各种障碍绊倒，最后跌下悬崖。而测试会在需要的地方点亮火把，帮助开发人员和经理看清他们在哪、要去哪，以及什么时候能到达。

现在，我更愿意这样理解测试的职责：提供关键信息，协助团队创造和运营出优秀的产品。这件事包含发现问题、保证质量、分析风险，以及其他任何能帮助团队了解当前状态的方式。