发布影响与回归规划
示意性用例，并非案例研究。
将发布变更映射到受影响的配置、集成与测试；交付负责人决定范围并把控上线。
问题
厂商发布和我们自己的变更按照我们无法控制的时间表落地。我们阅读发布说明，猜测可能出问题的地方，然后要么全部测试，要么测试记得的部分。缺陷仍然会到达用户。
当前做法
发布公告发出后，分析员阅读说明，并就看起来相关的内容给团队发邮件。测试人员凭经验从共享文件夹中挑选脚本。集成合作方很晚才被告知。上线后，问题被追溯到无人标记过的变更。
查看场景
示意性工作流程。含字幕。
文字稿
- 发布说明到了，团队仍在猜测该测什么。遗漏的变更在上线后变成事件。
- 规划器将发布变更映射到受影响的应用和测试，突出覆盖缺口，并提出测试内容和部署方式。
- 交付负责人决定测什么、推迟什么。计划经过审核，测试结果决定能否上线。
- 衡量指标：测试覆盖率和逃逸缺陷数。示意性用例。欢迎探讨您的用例。
拟议工作流程
- 导入范围内应用的发布说明和变更记录
- 将每项变更映射到它可能涉及的配置、定制内容和集成
- 将受影响区域与现有测试清单匹配，并突出缺口
- 起草拟议的回归范围和部署顺序
- 在测试和部署进行之前，将计划提交交付负责人审批
人员保持掌控的环节
- 交付负责人审批回归范围和部署
- 无法映射的变更被标记为需人工评估，而非被忽略
- 逃逸缺陷反馈到映射关系和测试清单中
平台映射仅表示可评估此构想的环境。实际实施取决于配置、许可、API、数据和权限。收益以定性方式表述；数值化的说法需要有书面记录的基线。