很多团队的测试复盘开着开着就变成了批斗会。“这个bug为什么没测出来”“谁负责的模块”“下次注意啊。”散会之后问题还在下次照样出。还有一种更常见的复盘开了大家轮流说了一遍“我觉得这次还好”“下次可以再仔细一点”然后就没有然后了。改进项没人跟进下次复盘时发现上次说的问题又出现了。复盘不是追责也不是走过场。复盘是让流程持续迭代的引擎。这篇文章讲怎么让复盘真正有用。一、复盘的第一个误区把复盘变成追责复盘会上最容易出现的一句话是“这个bug是谁测的”这句话一出来气氛就变了。被问的人开始防御其他人开始庆幸“还好不是我”。接下来的讨论重点不再是“问题怎么发生的”而是“谁该背这个锅”。一旦进入追责模式信息就会失真。大家会下意识地隐藏问题、推卸责任、避重就轻。复盘拿到的信息是经过修饰的基于这些信息做的改进自然也是无效的。解法对事不对人。复盘的对象是“问题”不是“人”。问的不是“谁漏测了”而是“这个场景为什么没有覆盖到是需求没写清楚还是用例设计时漏了还是时间不够没跑到”把焦点从“人”转移到“流程”大家才愿意说真话。二、复盘的第二个误区只复盘“出问题的事”很多团队只在出事故的时候才复盘。线上出了bug赶紧开个会讨论一下然后继续干活。但那些“没出问题但差点出问题”的事往往更有复盘价值。比如提测时冒烟差点没过但开发临时修了一下勉强过了某个需求变更来得太晚测试时间被压缩但最后勉强赶上了某个环境问题导致测试阻塞了半天后来恢复了就没再管。这些事没有造成实际损失但它们暴露了流程里的隐患。如果不复盘下次可能就没这么幸运了。解法定期复盘不只在出事时复盘。可以顶一个节奏比如每个版本结束后做一次轻量复盘每个季度做一次深度复盘。轻量复盘看当前版本的问题深度复盘看流程层面的趋势。三、复盘的正确姿势三个步骤第一步还原事实不加判断先搞清楚“发生了什么”而不是“谁做错了”。把时间线拉出来需求什么时候定的、开发什么时候提测的、测试什么时候开始的、问题什么时候发现的、影响范围多大。事实清楚了再讨论原因。跳过事实直接讨论原因很容易变成互相指责。第二步找根因不找借口问“为什么”要问到根上。比如线上出了一个bug测试没覆盖到。为什么没覆盖到因为用例里没有这个场景。为什么用例里没有因为需求文档没写这个场景。为什么需求文档没写因为产品经理觉得这个场景“不太可能发生”。问到这一步根因就清楚了不是测试漏测而是需求评审时没人提出这个场景。改进的方向也就明确了需求评审时增加“异常场景”的检查项。第三步产出改进项明确责任人和时间复盘如果没有产出改进项就等于没复盘。改进项要具体、可执行、有责任人、有时间节点。不要写“加强测试覆盖”这种空话要写“在用例模板里增加异常场景检查项由XX负责下个版本前完成”。改进项不需要多一次复盘能落地一两个就不错了。关键是每次都跟进上次的改进项形成闭环。四、让复盘持续迭代流程复盘的最终目的不是解决单个问题而是让流程持续迭代。每次复盘产出的改进项都应该落到流程里。比如发现需求变更太频繁导致测试时间不够—改进项建立需求冻结机制发现环境问题反复阻塞测试—改进项明确环境维护责任人发现提测质量不稳定—改进项把冒烟用例清单固化下来这些改进项积累起来流程就一步步长出来了。流程不是一次建完的是复盘一次、改进一次、迭代一次慢慢长出来的。五、复盘的文化比复盘的方法更重要最后说一点复盘的方法可以学但复盘的文化更难建立。如果一个团队的文化是”出了问题先找责任人“那再好的复盘方法也白搭。大家会本能地防御、隐藏、推卸。如果一个团队的文化是”出了问题先看流程哪里可以改进“那复盘就会变成一件自然的事大家愿意说真话愿意暴露问题愿意一起想办法。文化不是一天建成的但可以从管理者的一次次示范开始。管理者在复盘会上先做自我复盘先承认自己的判断失误先提出流程改进建议—这些动作比任何制度都管用。