如何有效开展大型项目的测试复盘
在工作的这些年里，我们需要参与和组织不少复盘，比如：日常工作中每个迭代结束后的阶段性复盘、项目结束后的总结性复盘等等。
针对如何开展大型项目的测试复盘这个话题，邀请到了最近担任【ke离线渲染上云图】重点项目的优秀主测分——歪林，她把组织项目测试复盘的经历和感想进行了分享，希望对大家有所启发。以下是她的分享内容：
一、背景
在【ke离线渲染上云图】项目即将结束之际，我收到了来自主测分委员会的通知，希望我们能够进行一次项目测试复盘。相比于项目复盘，项目测试复盘更关注质量的过程。
通过对项目质量过程进行复盘、输出过程与总结文档，对自我提升和团队沉淀有积极意义。
二、明确复盘目的
在开展工作前，我们需先注意以下两点：
1、明确复盘的目的——聚焦重点问题的改进
复盘是个先发现问题，然后期望解决问题的过程。但如果问题较多，往往不是一次复盘就能彻底有结果。
在一个项目中往往能遇到各种引起质量问题事件，对于组织者，应该从ROI的角度考虑，先解决高优的问题。比如需求变动频繁导致研发返工、测试时间紧张的问题，可能对当前项目而言就没有改进的空间。
因此，我们在复盘文档收集完后，先聚焦一些重点问题，然后在会上积极探索有效的解决和改进的方法。
2、调整复盘的心态——不要过于主观、推卸责任，重在改进
心态上，有些成员会抗拒复盘，认为复盘就是浪费时间，是一件配合性、对个人无收益的工作。
有一部分人可能是被组织者硬拉或者碍于情面参加，他们参与度和积极性就不会太高。还有一部分人是害怕复盘，认为复盘是为了问责，如果组织者没有掌控好节奏，复盘的问题甚至会引战到个人。
因此，在整个复盘过程中，我们都应理性看待，对事不对人，积极思考如何从流程上或者其他层面进行改进。
三、开展项目测试复盘
具体开展项目测试复盘工作，可以分为以下几个步骤：
1.按复盘文档模版补充项目相关数据
2.开展复盘会议，进行讨论及输出
3.收集大家的反馈
3.1.准备复盘文档
首先，鉴于各位成员在日常业务中都较为忙碌，预计参会积极性可能较低，我事先在群组中详尽阐明了会议的丰益之处，旨在为后续二期项目的融洽合作与效率提升等方面创造更为有利的条件。除了要求测试成员都参与，也在项目群里邀请了研发、产品等人员，他们可选择性参加。
其次，提前在会前收集复盘相关的数据：结合项目特点和主测分委员会提供的模版（如图：项目测试复盘模板），补充项目过程中测试角度相关的资料作为会议讨论的素材。
我先自己完成了自己部分的内容，再邀请项目组其他成员，主要是测试人员补充了该复盘文档。
这些资料不仅是我们在项目过程中的总结，也是相互学习和参考的重要资源，同时也可作为主测分对项目组成员进行评分的参考依据。复盘文档主要由以下几个模块组成：
回顾项目信息：包括项目背景、项目目标和达成的结果，这些内容往往在项目复盘中，由项目经理进行了整理，可以直接摘录。
项目质量过程复盘：项目各个阶段，从测试角度对项目质量的过程进行分析。
包括：需求分析、测试分析、测试过程管理、测试中、发布过程把控等。收集了做的好的、待提升的部分，以及可改善的action。项目质量分析：可以对工作量、bug数，特殊的问题，常见的问题进行分析，以总结经验和教训。比如某个组，bug数异常高，可以对原因进行分析。在我们这个项目中，主要是效果问题特别多，这放在第二个步骤里细谈。
成果总结：收集了成员们在项目中的收获，并对本次复盘的结果进行总结。
3.2.开展复盘会议
复盘会上，我们鼓励每个人畅所欲言，主要是为了发现问题并讨论解决方案。即使有些成员不太主动发言，我们也要确保给予他们适当的提示和引导。在这个过程中，确实能够发现一些问题。以下是一些例子：
信息差，认知不对齐
在项目的后期阶段，技术和产品团队达成了共识，认为材质效果方面的问题是可以接受的。这是因为后续的项目二期将专注于云图streaming实时渲染，而在这个方向上，材质效果问题并不会显得十分突出。然而，这一信息仅在技术团队内部的群组中进行了同步，并且项目目标并未发生变更。因此，部分人员认为项目的达成情况未达到预期，并在会议上提出了质疑。
风险暴露意识不足
有些block的问题，成员会私下试图解决且受阻，但没有反馈到主测分这边，其实可以一起探讨更合理高效的方式。
ke侧设计师验收效果是通过的，但是在集群设计师验证效果又是不达预期的。大家普遍提出了效果目标不明确的问题，然而，效果验收是相对主观，依赖于设计师的判断。我们希望能够像vray的效果对齐，但不同的渲染引擎很难做到一致。总体而言，我们的上线标准是以集群设计师和产品团队共同验收通过为准。
针对这几点，我在开展二期主测分工作时，强调了有block的问题可以直接联系本人，并在周会的文档模版上，新增了一列 【风险项】。
如果没有进行复盘会，我们应该不会探讨的那么细致。另外，我们还总结了一些经验给二期做参考：
共同整理了排查问题的工具和常见问题（如图：云图实时渲染-问题排查总结）。比如：前端界面可能容易出现的问题是传参问题，渲染中台可能出现的问题是业务方超时丢失问题等。既是对排查问题的提效，也对二期项目用例设计提供了思路，比如业务方异常降级验证等。
对二期功能上线后的痛点和风险点做了预估，因为该技术在kooshot是类似的应用，推测多数工单将是streaming 和离线效果不一致的问题。
针对数据不一致导致渲染效果验证时差异的问题，二期在设计师调整渲染参数阶段，对数据一致性进行了保障（回归平台ke离线渲染任务获取的材质数据是已经完成转换的，并提供了灵活的toad配置可进行效果参数配置）。
3.3.收集反馈
会议结束后，要求各位成员协助填写对主测分的评价。接着，主测分委员会将收集的反馈进行统计和分析，并将结果及改进建议和计划反馈给了主测分。
这一流程具有较为完善的闭环性，能够使我们对自己主负责的项目工作有更直观和深入的了解。比如在我这次项目的反馈报告（摘取了部分）中，综合评估还是具有参考性的：
有一部分项目成员认为项目主测分已经明确了测试边界，但仍需进一步完善测试规约和协作流程来确保全面性。
大部分项目成员认为项目主测分能够及时识别并提出风险解决方案，并且积极关注风险的进展。
大部分项目成员认为项目主测分能够提前制定发布计划，并按计划进行发布，但仍需要更好地利用发布计划来确保顺利上线。
跟大部分项目成员项目主测分在与其他团队的协作中展现出良好的沟通和协调能力，但仍需加强日常沟通以确保团队之间的顺畅合作。
大多数项目成员对项目主测分制定测试计划和测试方案的专业水平表示基本满意或满意。
四、心得体会
我认为主测分可通过多次项目复盘来总结经验教训，这样才能不断积累大型项目把控能力；除了上述的介绍，还有些主测分工作积累的小tips可与大家分享：
我们在项目测试过程中，需要注意积极沉淀文档，否则在复盘时在进行回顾和总结会变得有些困难。
主测分的职责与项目管理存在相似之处，除了关注质量问题和进度问题外，还需要加强沟通并推动解决各项事务。
除了对业务技术的熟悉，在项目这类大需求中，需要整合各个组已有的问题定位能力以提升整体的问题排查效率。
为了避免认知不统一的问题，我们需要加强信息的同步。日常虽然有开展周会，但无法确保所有相关人员都能全员到场。因此，我们需要确保重要事项能够逐一得到确认。这样可以保证团队的共识和一致性，并避免因信息不同步而引发的误解或偏差。
推荐阅读