管控变更对提升质量的重要性

昨天晚上测试交流群一位同学抛出一个问题：

线上发布，前端上线了一段测试不知道的代码，且这段代码不在本次发布的需求范围内，上线后测试未回归这段代码涉及到的功能逻辑，导致出现了线上故障。这个问题需要测试承担责任吗？

群里其他同学提出了各自的看法，比如：

1. 开发私自夹带代码，且未通知测试进行回归，测试不需要承担责任；

2. 已经上线的部分测试没有回归到，出了问题测试也要承担一定的责任；

3. 对应代码和本次发布的需求没关联，且未提前做好同步，线上出问题一概不认；

站在不同的角度来看，好像都挺有道理也符合逻辑，但真的是这样吗？

以我的理解和实践经验来说，线上出了故障，就是交付的质量存在不足，测试作为直接对交付质量负责的岗位，是要对这个事情负责的。但测试团队不是为了本次夹带私货的代码产生的问题负责，而是为线上出了事故负责。

当然，线上的交付质量和整个技术团队每个人都有关系。在上面这个问题中，开发要对自己夹带私货且没有同步测试进行回归验证负责，测试要对线上发布后的回归以及线上质量不佳负责，管理或者掌握发布变更权限的人要对不经过测试和评审就可以发布线上负责，大家都有责任。

可能有人会说，线上出了故障，那就组织故障复盘，定责然后改进就好了。但我认为，故障复盘只是治标而不是治本，很多时候所谓的复盘后的改进，有没有落地，有没有解决根因问题，这些都是滞后的动作。相比于复盘，更重要的是计划+规范+检查，即所谓管理上是否可以进行优化。

做技术的同学都知道，日常的版本迭代，一般都会有发版计划，以及对应的各种评审。做这些动作的原因在于，团队中每个人的工作习惯、技术栈、沟通方式都不同。计划是为了将团队中不同的人划入同一个大的方向中，并告诉大家前进的目标以及关键的节点；评审是为了尽早的发现需求、方案、代码、用例中可能存在的风险，并且及时处理；而测试的执行动作，更多的是检查代码实现的需求是否在各个方面符合预期的目标。

有句话叫做“质量是设计出来的，不是测试出来的”，我个人的理解是：最初的设计(通过评审)可以保障质量的下限，而测试应该做的，是通过测试左移右移来提高质量的上限。

以文章开头的问题为例，要杜绝类似的不经测试就上线导致问题的现象，可行的手段有很多，比如：

流程规范：严格要求每次发布不允许夹带私货，并且和个人绩效挂钩；

分支管理：禁止 push 操作，每次代码改动必须有 changelog，且必须和需求的 ticket 挂钩；

质量卡点：每次代码改动或者变更都必须经过测试，只有测试通过才能进行下一步 merge；

变更管理：研发内部进行 code review/code diff，核心模块或者线上发布的变更必须多方检查，且需要审批通过；

权限管理：禁止研发的线上发布权限，由 QA/运维或者专门的线上配置管理员进行发布变更操作；

据不完全的数据统计，大部分的线上问题，最直接的原因都是变更导致的。如何理解变更呢？变更并不是简单的代码发布，还包含配置变更/服务器变更/DDL 变更甚至业务活动的开关等变更，理论上所有的变更都会对代码运行结果造成影响，因此变更管控很重要。

对于变更管控和评审，这样做的目的一方面是通过不同的角色参与，从不同的角度进行 review，查漏补缺；另一方面通过 check 和审批的方式落实责任，这样才能提高团队所有成员对于变更风险的认识和质量保障意识。

在变更 review 和 double check 时候，需要变更申请人说明变更内容/影响范围/异常情况的解决方案等，这样即使变更出问题，也可以及时修复，将风险控制在合理范围内。

虽然说搞各种流程规范和管控会无形中增加管理和沟通成本，但在实际的工作场景中，我们不能把对线上质量的期望，放在团队每个人都具有高度的专业素养和极强的技术能力之上。

流程只是引导，在软件开发这种技术工程领域，强制的技术手段，严格的检查和完善的监控告警机制，可信度更胜于人的主观行动。