对很多人来说，今年是特别艰难的一年，疫情、裁员、股票缩水、经济下行....各种负面消息接踵而至，身边的小伙伴也离开了不少。即便是留着的人，也略显焦虑，生怕哪天就被“组织优化”了。相对产品、开发角色而言，测试员的担忧往往会更重，感觉自己在老板眼里并不重要，容易成为优先裁撤的对象。这就不得不提到一个时常困扰身处测试岗位的你我的问题：测试的核心价值到底是什么？
今天就用一篇文章，来深入聊聊这个话题。
1、测试的职业意义
任何职业的诞生、发展、衰退、消亡，都有其必然原因。我们需要去客观看待这些原因，并根据环境的变化不断调整自己，才能保持不被淘汰。例如，古时候的更夫，在很长的一段时期内，都承担着重要的角色，后来随着钟表技术的普及，逐渐消失在历史长河里。这不是因为更夫的工作不够努力，而是时代的需要发生了变化。我们个人很难与时代的潮流对抗，我们能做得更多的是：尽力感知这个潮流，并顺势而为。
软件测试亦是如此，我们要了解测试的核心价值，先要理解为什么会有测试这个职业。关于测试发展历史的文章比较多（参考阅读：《软件测试发展简史》），在这里就不具体展开讲，这里做个概要总结：
- 早期：测试 = 调试成功
- 1950s：测试 = 确信软件可以工作
- 1980s：测试 = 软件测试思想、学科形成
- 1990s：测试工具迅猛发展
简而言之，之所以测试会成为一个独立的职业，是因为它已经形成了一门专业学科，相关的理论、工具已经发展到普通开发（当然会有天才程序员）难以同时与开发技术很好兼顾的程度。这一点看似很自然，但事实上，当前国内的从业人员，对测试基础理论的掌握程度之低，远超我们的想像。国内对测试职业普遍的认知就是“入门门槛低，没有技术含量，经过简单培训谁都可以做”。于是大批经过专门机构短期培训、非相关岗位转行的测试从业人员走向这个岗位，进一步加剧了“测试只是点点点”的印象。
例如，13 年作者在一家知名互联网企业工作时，老板希望我对两名产品经理做一次 2 小时的培训，以便他们能在一条新业务线里承担测试工作；15 年作者在另一家知名电商企业管理测试团队时，老板安排了一名客服转岗到测试团队来支持我的工作。（以上只是强调不同领域的岗位间存在差异，并非对产品、客服有偏见） 可见即便是靠近头部的企业，对测试的认知都是如此，更何况发展阶段更加原始的小企业。类似的例子，相信大家身边还有很多。在相当多的人（包含测试自己）眼里，测试并不能算是技术型职业，更像是劳动型职业。
因此，这里再次强调：测试是一门技术专业，它有自己的理论、方法、工具、体系。测试的价值，是建立在对这门学科的掌握深度之上的。测试职业有着自己专业性和门槛度，而不仅只是依靠热情和经验。
2、测试的自我定位
虽然上面提到了测试是需要有专业度的，但是如果老板（或合作同事）的想法就是“测试 = 点点点”，我们又该如何去体现测试的价值？我们不妨先把这个问题做个转换：我们测试和公司发展的关系是什么？它们之间的关联性越直接、越紧密，也就意味着测试的价值越受认可。
坦白说，这个问题的确非常难，它也困扰了作者很多年，即便在历任岗位均拿到还不错的绩效，但是自我感觉也并没有回答好这个问题。直到后来加入了某大厂，遇到了许多顶尖的测试领域专家，这个问题才逐渐有了答案。
测试是从开发中分离出的专业，本质还是开发属性。类似的还有运维（开发）、数据库管理员等。这些岗位均是在某个特定领域深化之后，形成的独特发展方向。因此我认为，测试从本质上说，只是开发的一个方向，而不是区别于开发的岗位。这些年“测试开发”的流行，并非是测试开拓出的新领域，而是对早期的错误做出的一种修正。我们一直被“开发是建设性思维，测试是破坏性思维”的说法误导了很久（这句话本身没有问题，理解和引导有偏差），以致很多测试在潜意识里会认为自身的工作是尽可能提交缺陷、拦截未通过测试的版本发布（老板们都不太喜欢听到这些消息），忽略了测试也是可以帮助产品去做正向构建的。
说到这里，估计部分读者已经有点感觉了。当测试们站出来跟老板、产品、开发说“你的需求存在 X 个缺陷，所以不能发布的时候”，对方的反应是什么？庆幸测试帮他们找到一个问题？还是觉得测试是在给他们制造阻碍？很遗憾，多数情况下，我们得到的反馈是后者。老板们一直在问为什么有了测试之后产品还会有缺陷；产品们一直在问测试时间为什么要这么长；开发们一直在抱怨测试小题大作。这一切的原因，都是因为测试把自己过份定位成了“逆向构建”角色，导致合作的同事感觉我们就是在干“相反的事”。
3、测试的价值体现
接下来，我们就要仔细去讨论前面的问题：测试该如何帮助产品去做正向构建？回答好了这个问题，也就找到了测试与公司发展的关系，同样即是证明了测试的价值。我会从以下两个方面，来解释我对这个问题的理解：业务层面和技术层面。
相信大多数测试员都知道测试左移和右移（参考阅读：《软件测试左移、右移和DevOps小结 》、）。在“左移”里经常被提到的一个点是“需求分析”。通常情况下，我们对需求分析的理解是帮助产品找到需求文档中的细节缺失和逻辑漏洞，避免在后期阶段发现问题，导致项目延期。然而这就够了吗？并不。这仍然还是在以工程的角度看待这个事情，我们不是在“优化产品”，而是在“补全产品”。而我想说的是，其中有相当一部分重要内容被我们忽略了：测试在业务上最核心的价值，是帮助产品准确定义质量。
例如，市面上的硬盘产品，均会标注平均无故障时长（MTBF），原因是它是硬盘质量最重要的体现。如果是用在军事领域，还会有抗震、防尘、防水、安全方面的要求。由此可见，即使是同样的产品，在不同的场景下，对质量的定义也是有区别的。测试应该在项目的早期阶段，就准确识别出需求的质量关键和风险，并围绕它重点开展工作，为后续的开发、测试、发布阶段提供明确的框架和指导。而并非在最终发布之前，和产品、开发在一个缺陷需不需要修复的问题上争吵不休，并为自己“坚持原则”感到光荣（再说一次，老板可不这么想）。
另外一个经常在“左移”里被提到的点是“架构评审”。这点在理解上，相信大家都没有太大分歧。测试需要和开发坐在一起，共同评审技术架构的合理性，而测试角色更多会从容错性、可测试性、质量风险等方面提供自己的专业意见。但是由于前述的各种原因，很多测试从业人员因为缺乏相关的技能，并不能有效参与到技术架构评审的活动中。这里我也再重复一次：测试是开发的一个方向，我们应当要能够和开发在一起讨论技术，并找到其中的技术问题，而不仅只是给他们提交功能缺陷。
例如，公司计划在 6.18 进行一次秒杀活动，以五折的价格销售一万件商品。开发一般更关注如何支撑高并发的访问？如何防止超卖？如何预防恶意请求等问题。测试一般更关注当前的架构是否存在瓶颈？如何模拟高并发进行测试？测试过程中产生的数据怎么处理等问题。虽然双方在问题的方向上有所不同，但同样要求测试对整体架构和技术细节有相当程度的了解，并需要与开发保持密切的交流。