上篇《常见技术类缺陷及解决方案》发布后，有小伙伴留言说团队中有部分测试人员，对业务缺陷也不敏感，经常在迭代测试中发现不了问题，等到 UAT 环境业务验收时，会发现大量的缺陷，导致业务团队对 IT 团队的交付质量失去信心。这种情况要如何处理？
本文结合自己的经历，谈谈这个问题的解决方案，主要有以下几点。
必要的业务培训
理解业务是一切测试活动的基础，如果对业务不熟悉，肯定是无法发现缺陷的，特别是在 TO B 的一些特殊领域，都有很强的业务属性和专业壁垒，需要测试人员认真地去学习和了解相对应的行业知识和用户操作使用习惯，才能更好地发现问题，仅靠需求文档是不够的。
在了解的被测系统的业务属性后，还需要结合业务流程图、系统架构图，对业务系统有个整体的感知。知道业务系统的整体业务流向及涉及的系统架构，这样有助于测试人员从大的方向去拉通测试场景，不至于陷入细节中而无法顾及全貌。
结合迭代测试中的具体业务测试场景，了解业务的流转规则、约束条件及数据流向。业务时序图可以帮助我们更好的了解场景细节，这也是测试用例设计中场景法的基础。在这个环节，需要去实例化业务场景，去梳理数据流向，去弄清楚状态约束。
制定明确地测试策略
在迭代开始前，测试负责人应该明确知道本次迭代的测试策略是什么，即明确两个问题：测什么？怎么测？设计测试策略的目标是 “减少缺陷的出现和发布”。其中 “减少缺陷的出现” 可以通过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；而 “减少缺陷发布” 可以使用各种测试方法、技术来验证和测试编码完成的功能。
结合常用的测试建模，可以更好地设计测试用例，解决怎么测的问题。在《如何让测试用例更有价值》一文中，有提到过相关的设计方法论，这里不再赘述，有兴趣的可以直接移步阅读。
在明确了测试建模后，测试用例就容易开展了，因为测试用例就是上面步骤的具体呈现，具体使用什么工具，用什么形式来承载，并不重要，团队可以根据自己的现状去落地。
严格执行测试流程
很多人都讨厌自己走流程，但更讨厌别人不按流程来（是不是很熟悉？）。比如流程中明明有研发自测，但是很多研发就是不执行。
流程是什么？流程是保障团队目标达成的最佳实践，没有流程会导致团队中个体各自为战，目标不统一，进度不协调，规范流程的目的，是为了确保团队中大部分人在同一个正确的方向上前进。同时通过一些关键指标、日常宣导和定时检查，让偏离方向的人回到正确的途径上。换句话说，流程规范本身是一种对群体的约束，也是团队内各个成员共同认可的一个承诺，约定和约束意义大于管理意义。
每个团队都会有对应的流程规范，但是这些流程规范是否真的落地执行了？有没有明确的 DOD（完成标准）？流程是否可跟踪并量化透明出来？
测试不参与需求澄清？测试用例不需要评审？迭代测试没有测试报告？你能想象吗？这些笔者都经历过。如果没有严格地执行测试流程，那么就无法保障测试活动的下限。
建立质量意识和责任感
测试活动，其实是一个非常依赖团队成员个人主观能动性的一项活动。严格的测试流程，只能保障测试活动的下限。如何提高测试价值的上限呢？就需要提升团队成员的质量意识和责任感。
很多人觉得测试不重要，门槛低。这种认知是我们自己造成的，早期的测试人员确实是这样的。但是，经过一批批测试人员的努力，不断地研究测试底层逻辑，提升测试能力。他们没有躺平在测试 “仅仅是点一下、看一下、验一下” 的认知中，而是通过提升自己的能力，通过单测覆盖、静态分析、接口测试、各类自动化手段，乃至于安全测试、埋点、监控、生产流量导入等等各种手段和方案，来提升质量，让产品的质量更加可靠。
作为测试人，经过自己测试过的内容，应该承担一份责任，能够保证产品的基本质量。测试遗漏是难免的，但是我们不能把线上问题简单地归结为对质量意识不强或者开发人员能力太差，测试应该有责任和能力去探查问题的根源并加以改进。我们不生产问题，但我们也不能让问题轻易地从自己测试的版本中遗留出去。出现问题并不可怕，可怕的是让问题重复出现而自己视若无睹。（个人也经历过比较重大的线上问题，复盘后给出改进项即可，很少会有团队因为线上问题就开掉测试人员的。但是这份责任，不能丢，你有义务去加以改进）
定期回顾和总结
著名的 PDCA 法则告诉我们，想要把事做得更好，复盘和总结是必不可少的，通过复盘，能够更好地认识自己，发现问题，改进方法，提高工作效率。复盘活动的核心有两点：安全的环境和可落地的改进项。前者可以让团队更充分地去发现根本问题，而不是表面问题，后者可以让复盘会得到价值最大化，没有改进项的复盘会是没有意义的。
在复盘活动中，有一项比较重要的内容，就是缺陷分析，在某个迭代或者版本的周期内（或者更长时间），对 BUG 产生的原因、修复周期、累积趋势进行分析。总结分析 bug 和测试过程问题，形成的质量报告不仅能准确评估过去产品质量，还能为未来产品提出改进建议，持续推进产品质量的不断提高和完善。具体的分析方法可参考《如何高质量的做 BUG 分析》。
很多人可能会有疑惑，上面提到的那些理论我都懂，也希望去实践那些活动，但现实的问题是，时间不允许啊，在所有的研发活动中，测试活动处于相对后期的环节，时间总是容易被压缩。如何解决这个问题呢？答案就是测试左移，其实会发现，很多测试活动都是可以逐步前置的，真正被压缩的只是测试执行的时间。
还是那句话，测试活动，其实是一个非常依赖团队成员个人主观能动性的一项活动。你的责任能力（Ownership）将决定你的上限。
共勉。
