在上篇的反模式中，有提到一个点：沉迷发现缺陷，忽视缺陷预防，有读者留言说：不通过 BUG 数量等量化数据，那么如何界定测试人员的价值或者贡献？本文聊聊自己对于测试价值的思考。
需求端的价值：从质量构建和缺陷预防的角度看，测试人员需要尽早地介入，了解需求。在需求端，测试的价值至少应该包含三类
验收标准：测试人员需要明确某个需求的验收标准是什么，实例化出场景来确认，保证产、研、测三方达成共识，避免需求返工，造成浪费。可参考：从测试看需求
业务逻辑梳理：作为对被测系统最了解的人（使用频率最高的人），需要协助产品经理梳理业务细节，当产品对已有功能做出改变时，需要评估改动点对原有业务逻辑的影响，避免遗漏。
用户体验：系统好不好用，视觉效果是否合理，操作路径是否顺滑等等用户体验的问题，可以在需求端给予确认。
测试即服务：把测试活动当成一种服务，在不同的场景下提供对应的服务。如上文的 AC，算是对产品的服务。那么对于研发侧，能够提供哪些服务呢？
测试用例服务：在不同的研发环节，提供经过科学设计的高效用例，以便开发能够快速验证自己的代码，保障交付质量。如冒烟用例、流水线用例、showcase 用例等。
专项测试服务：当产品达到特定形态后，需要开展如性能测试、安全测试、某类专项测试（安装测试、疲劳测试等）时，测试组能够提供对应的能力进行测试，并出具专业的报告，以便团队做出正确的评估。
缺陷跟踪服务：从缺陷的发现到最终的验证关闭，提供全周期的管理，迭代缺陷及时跟进，遗留缺陷持续跟进。不让缺陷无限期流浪。
团队积累：把个人的经验沉淀成团队资产，对外赋能，提升影响力。
过程改进：由于测试参与到了研发的全生命周期，可以观察到所有的测试活动，所以可以更好地地识别出瓶颈点，给出过程改进建议。
风险评估：结合业务需求及研发进度，提前暴露风险，进行风险预警，结合客观条件提出质量预期，帮助团队建立质量信心。
业务沉淀：测试人员积累了大量业务知识，不管是宏观层面还是业务细节，测试人员对自己测过的产品都了如指掌，往往也更容易成为领域专家。在这个过程中的积累和沉淀，对组织来说都是一种有形的或无形的资产。
个人价值体现：为了完好的完成以上团队层面的价值，测试人员个人要也需要具备一些突出的能力，形成一定的 leadership，进而影响团队，体现自己的价值。
缺陷定位能力：同样一个缺陷，有的测试人员只能在页面上截个图，有的测试人员可以追踪日志、分析代码，甚至给出解决方案（这点笔者并不提倡）。你觉得哪个测试更有价值？
风险识别能力：在需求确认时，能识别出业务风险，在测试过程中能识别出进度风险，在上线前能识别出上线风险，可以极大地极大地保障迭代的顺利进行。
测试策略制定能力：在迭代前，明确测什么（指质量需求是什么、需要关注质量的哪些方面，比如应用的功能范围、性能、安全、易用性等非功能需求）怎么测（采用什么办法来帮助系统实现质量需求，而不仅仅是手动和自动化的测试方法，也包括一切为质量保障服务的流程、环境、基础设施和人员等）。可参考你还记得测试策略么
技术攻坚能力：当团队需要开展某类专项测试时，能够承担起对应的责任，从技术和方法上攻坚克难，顺利完成对应的任务。
汇报能力：既要做得好，也要说得漂亮。在适当的场合刷刷存在感，定期做做汇报。让更多的人看到你的能力，认可你。潜移默化地，你的价值就最大化了。
当我们做好缺陷预防后，就可以提升研发的交付质量。有的人会担心 BUG 少了，老板会认为测试就可以减少人力，是不是会把自己做没了？其实大可不必有这样的担心。当研发交付质量提升后，测试可以把时间腾出来做更多有意义的事，比如探索性测试、可观测性测试等，这些测试活动，不论对个人，还是对团队，都是有利的。
只有在不规范的团队，才会存在天天救火的情况。救火多了，看似你很重要，但是能力没有得到质的提升，未来的上升空间也就没了。
做好测试该做的事，讲好测试该有的故事，才能真实地体现测试人员的价值。
