项目迭代反馈
今天听到测试反馈近期版本出现的问题，顿时一惊醒，我好久没有做这样的复盘了，悲剧啊。回首当年，我可是这方面的好手，可以继续做下去。不在动手的第一线，只在动嘴的第一线，其实也可以做一些事情，比如流程改进，比如效率提升，比如全局思维。但今天重点不讲我自己，讲的是近期迭代发生的事情。
1. 引入重构工作导致开发工作量变更（由小变大或由大变小），没有第一时间沟通同步测试，影响测试工作量评估、测试计划与用例覆盖范围，导致后期风险增大；地址识别性能问题（解析长地址会经常失败），功能没有同步到位，令前端交互问题增多。引入三方会谈，开发或技术方案变化，产品、开发、测试一定要及时同步到位—可面对面沟通，提测邮件描述，微信或其他及时沟通工具等。
2. 产品文档缺少较多交互细节，开发比较依赖测试用例进行开发，测试驱动开发，可能要从验收场景开始。交互部分用例较少，导致开发关注较少，但比较容易出问题，用户界面相关，交互其实蛮重要的。原则上需求评审时主体交互已输出。测试提供开发自测场景，开发间交叉和开发间交叉是个好方法。
3. 开发负责人安排任务时，看到不同需求的工作量，要避免顾此失彼，一个人同时兼顾两个大需求，容易顾此失彼。针对别的团队借调资源，负责人更要多留心，毕竟熟悉代码也需要时间，通常的做法是给些逻辑清晰相对简单的需求给他们落地，组内大神则负责费脑力的需求。团队成员也要代替主观能动性，自行与产品对好需求问题，项目经理要意识到这个风险，好优先级应对它。
4. 对代码重构，需要考虑改动后的回归，对现有功能和分支的影响要评估到位，此时如果能有比较好的自动化覆盖率和持续集成就显得非常舒适，测试驱动开发，场景没变，自然重构心里会更有底气。需求分配时，尽量合理调配或拆解大需求，代码重构也不一定要一步到位，做到简单设计，多轮分阶段可能更加有效，这取决于实际影响。有时候快刀斩乱麻也是必要的。代码评审对交互部分无法起到很好的覆盖作用，安排开发环境的页面检查更有效。
5. 紧急项目，绿色通道，就是领导拍死时间那种，前中后端都需要发力，这种时间就不可能合理，只能集思广益但强制执行，此时一个良好的沟通机制必须建立，比如每日站会，定期周会，里程碑执行，联调同步会，前后端均有负责人，能够互相提醒。产品方案的充分理解，排期时应明确接口上线，上预发布，上测试环境时间。当后端有问题导致延迟或无法线上联调时，需及时同步。
6. 关于开发自测，我一直信仰质量是团队的事情，是在过程中保证出来的，而不是靠测试去把守最后一道关卡。自始至终都是，越在靠前的阶段解决问题，投入产出比就会越高。开发人员因时间问题不执行或少执行自测，需要提前通知负责人和测试，分配任务时也要明确责任、目标且记录结果。回归阶段发现不少问题遗漏，只要执行用例执行用例，就能发现，自测需满足一定标准才能算完成。
7. 关于产品测试，需要培养其能力，不能只是口头答应确不能做到。产品内部由有经验的同学统一做一次培训，减少沟通成本，培养产品经理的基本能力，如测试工具抓包，看埋点数据等。不要再让测试兜底，个人是期望产品在做需求时输出验收场景，确保端到端的需求交付。衡量产品输出质量，可以基于技术提出的需求问题考量，这也是个不错的方法，检查列表、需求模板都能够有效避免一些低级错误。
8. 三方会审，包括技术方案。测试很多时候比开发清楚，我作为过来人也非常清楚。前期讨论需要通知测试参加，发现潜在的坑，前期方案不清晰，了解方案沟通成本太高，原来技术方案存在很多缺陷，这些都可能是问题，导致技术实现方案一直在变更。很多情况下参与需求技术讨论的都是负责人，落地的一线没有参与，这也可能有存在实际开发者经过多重传递，会出现理解不一致。
有个观点，产品开发测试是同一个大领导比较好，在同一个小组才能敏捷，提BUG不是为了绩效，而且共同进步，团队一起完成需求的快速端到端价值交付才是最重要的。不晓得组织架构能否做这样的调整，但如果做Scrum Master，就试着融入和改变吧，毕竟我是一个喜欢模式和持续改进的人。
网友评论