最近总结测试经验想针对迭代版本更新分享一些落地的做法。关于版本提测我们有一套 5 步循环管着版本上完测试先确认——确认环境和主要功能可用确认完在群里通知大家严重问题当场抛群里——会挡路的问题第一时间反馈一句话说清、尽可能附图、带编号定时汇总清单——测试每 15~30 分钟把当前问题汇成一份清单发出来修完再提测验证后出清单——开发批量修复后再次提测测试验证过的从清单里去掉清零收尾——清单清零测试确认版本可用在群里更新一条完成情况。比起分享这个流程我更想说的是这套流程是怎么来的——它不是谁一拍脑袋设计出来的是一次次乱出来的。几乎每一条规则背后都对应着一场具体的乱子。把乱写出来是因为我觉得对想抄流程的人知道每条规则是堵哪个洞的比拿到一套完整的 5 步有用得多。最早其实没有提测这个说法。项目每周一个迭代版本大家只管代码有没有上上去版本上了就算完没人确认过这个版本能不能用。结果呢第二周真要测的时候这也不行那也不行只能边测边把开发拉来修。测试的安排全被打乱开发也一肚子意见——当周任务被反复打断。两边都觉得自己委屈。后来项目负责人、测试负责人、开发负责人坐到一起定了一条最基础的约定版本更新后测试先确认环境和主要功能可用确认完再通知大家。这条约定就是整个流程的源头。从它开始规则是一条一条长出来的。最早冒出来的是反馈太杂 互相等待。一开始是有问题就在群里说没多久群里的问题就乱成了一锅粥——大小问题混在一起没重点也没优先级处理安排跟着乱。同时还卡着一件更要命的事测试在等开发改完上版开发在等测试测完确认两边常常互相等一个迭代能拖很久。这事不是改一个地方就能完的先后定了三条规则只反馈影响测试的严重问题。迭代期间只反馈严重问题非严重的留到全量测试时提 BUG——这条把迭代期和全量测试期分开是后面所有规则的地基。测完主动反馈。测试测完要主动反馈不能等群里有人问才说话。更新时间尽早当场敲定。下一次更新迭代的时间测试和开发尽早敲定有任何疑问尽快提谁都别等谁。规则一条条落地之后上版过程才慢慢顺了一些。接着是问题说不清也没编号。群里的反馈当时有两个毛病。一是问题描述不完整常常只有一句话还未必说得清楚或者只甩一张截图没有文字说明不知道想表达什么。二是问题一多就乱没有编号想跟进都不知道该指哪一个。针对这两个毛病又约定了两条问题要说清、尽可能附图不能只有图没有描述——这样负责汇总的测试同学能快速把问题罗列出来开发一眼能看明白其他测试同学也方便协助验证。群里的问题统一编号。不管谁提的发问题的时候带上编号顺序递增。哪个问题漏了编号可以删了重发或编辑原消息补上新编号。暴露得最慢的是汇总清单的问题。这个洞不是马上出现的迭代了几次才慢慢显形。一开始靠人翻聊天记录问题一多得往上翻才知道哪些处理了、哪些还没有。问题少的时候还勉强应付得来日常迭代问题一多就顶不住了。后来有人开始抱怨跟不上才开始想办法于是有了定时汇总的约定测试每 15~30 分钟把当前问题汇一份清单发出来开发处理完在群里回一句版本再更新、测试验证过了也回一句。清单的格式也调过几轮最早是只罗列问题没标注处理进度之后改为所有问题都列出来、标注处理了没处理——问题少的时候还行问题一多就又不好用了一段时间后才改成把验证过的直接从清单里去掉。那阵子还纠结过另一件事旧的清单到底要不要删掉只留最新一份试下来发现不行——旧清单一删这个迭代里问题处理的来龙去脉就全没了回头想查当时那个问题是什么情况都没处看。所以最后定的是旧清单都留在群里不动只在最新一份里把新修复验证过的去掉。清单机制里最坑的一次是编号要不要重编。有段时间我们嫌列表编号越编越长可能还会跳号就重新从 1 开始编。一开始觉得这主意不错。结果——跟进的人开始对不上号比它解决的那个问题还乱麻烦的是为了重新编号测试同学还得专门新开一个记事本重新整理费时费事事后回头看也理不清。后来定死一条编号只增不减用过的编号不复用也不重编。核对问题处理进度时编号两头一对这个迭代是不是在收敛一眼就能看出来。至于编号过程中会跳也无伤大雅能解决问题就行。这个好处不是谁事先设计好的是用着用着才慢慢意识到的。另外还有两个问题一个关于记录一个关于收尾。关于记录迭代里发现的问题一开始只在群里有系统里没记录。开发和测试流程倒是省事了但一到质量分析时就发现不合适。于是规定当周的问题统一汇总提 BUG 单到缺陷平台存档。这个做法是有代价的——问题埋在一到两张汇总单里系统的统计会失真想做数据分析还是很难。但留痕、可追溯的价值更大我们选了留痕。现在通过 AI 了解行业里更成熟的做法一般是两种一种是提测期的问题按优先级分流高优先级的即时录入、低优先级的批量补录另一种是给汇总单打上提测期标签统计时单独归类不污染日常的缺陷数据。我们没做到这一步统计失真是实打实的代价。如果你正要建类似的机制可以直接参考行业做法少走我们走过的弯路。关于收尾迭代结束有时口头说一句没问题了就放行没留文字。这也是一种省事的做法特别是迭代时间拖得长的时候但并不规范。于是规定确认完成后测试在群里更新一条完成情况明确迭代完成。这是执行得不太理想的一条——不只是忙的时候漏平时也会漏。说到底是大家没把为什么必须留文字形成共识只觉得口头说过就行过于随意了规则立了意识没立住。以上这些乱子和规则收拢到现在就是开头那套 5 步循环。但流程归流程——它管得住标准动作管不住资源。人手不够的时候确认和修复的时间都会拉长冲突变多有时要靠负责人出来协调开发不配合的时候得负责人出面问题实在太多处理不完迭代就完不成第二天接着来。还有一个遗留问题——迭代期间这个问题该不该现在优先处理测试和开发时不时还是有分歧。现在回头看根子不在谁的态度还是在标准不够明确待后面再总结一下。另外说明一句这篇讲的是提测这一个环节。测试过程中的协作——和开发的配合、跨角色的沟通——对效率和结果的影响不比流程小我们也有不少没做好、还在改进的地方那块值得单独再整理。还有一点想单独强调这套流程能成形靠的不是哪个管理者高明。好几个调整都是参与的测试同学、开发同学先说出有问题才启动。流程好不好用天天用它的人最清楚——大家都憋着不说、改进全等着管理者来推问题只会越拖越久反过来谁觉得别扭就主动提出来问题才能越早得到改进。而且能发现问题、推动改进这件事本身就是个人能力成长的机会比闷头执行收获大得多。所以如果你想在团队里推行类似的东西个人建议是别整套搬。先找你团队最痛的那个点是问题没编号没法跟是群里刷屏没人汇总还是测试和开发互相等、没人定更新时间找到它对症抄上面那条规则先立一条就够试用看看。流程这东西别人给你一套完整的你未必用得起来自己乱过一次长出来的才守得住。