返工率从35%降到8%！测试左移3个月，我们团队发生了什么？（下）

上一篇文章《返工率从35%降到8%！测试左移3个月，我们团队发生了什么？》中为大家介绍了问题的发现，解决方案及深入实践等内容。

本文将继续为大家介绍实践中遇到的挑战与解决方案、实施建议与关键要点、三个月后的成果及总结。

遇到的挑战与解决方案

4.1 挑战一：产品经理觉得浪费时间

• 问题描述：

刚开始推行三方评审时，产品经理抱怨："需求评审要开1小时，太浪费时间了，以前15分钟就讲完了。"

• 解决方案：

我用数据说服了他："第一次迭代，我们在需求评审上花了15分钟，但后续因为需求不清晰，开了7次澄清会议，每次30分钟，总共210分钟。还不算开发返工的80小时。第二次迭代，我们在需求评审上花了60分钟，后续只开了1次澄清会议，总共90分钟。开发返工只有12小时。前期多花45分钟，后期节省120分钟，还避免了68小时的返工。这笔账怎么算都划算。"

看到数据后，产品经理不再抵触，反而主动要求把评审会开得更充分。

4.2 挑战二：开发人员不愿意参加评审会

• 问题描述：

有些开发人员认为："需求评审是产品和测试的事，我只要按需求文档开发就行了。"

• 解决方案：

我们调整了评审会的形式，让开发人员感受到参与的价值：

1. 让开发人员主导技术可行性讨论

• 产品提出需求后，先让开发评估技术实现方案
• 开发可以提出更优的实现方式
• 技术难点由开发来判断和说明

2. 让开发人员参与需求优化

• 某次评审中，产品要求"实时计算用户可用优惠券"
• 开发指出："如果用户有100张券，每次都实时计算会很慢"
• 最终方案改为："领券时预计算，使用时只做有效性校验"
• 这个优化让性能提升了10倍

3. 让开发人员提前识别风险

• 开发在评审会上指出："这个功能依赖第三方支付接口，如果接口不稳定会影响用户体验"
• 团队讨论后增加了降级方案
• 上线后第三方接口确实出现过问题，但因为有降级方案，用户没有受到影响

经过几次评审会后，开发人员发现自己的意见被重视，参与积极性明显提高。

4.3 挑战三：测试人员不知道问什么

• 问题描述：

刚开始时，测试人员在评审会上不知道该问什么问题，或者问的问题太表面。

• 解决方案：

1. 提供标准化的问题模板

   我整理了一个"测试质疑问题模板"，测试人员可以对照着提问：

功能完整性：

• 正常流程的每一步是否都清楚？
• 有哪些异常情况？如何处理？
• 边界条件是什么？
• 与其他功能有什么关联？

数据准确性：

• 数据从哪里来？
• 数据格式是什么？
• 数据范围是什么？
• 数据校验规则是什么？

业务规则：

• 业务规则是否明确？
• 多个规则的优先级？
• 规则冲突如何处理？

用户体验：

• 用户操作是否便捷？
• 错误提示是否清晰？
• 响应时间是否合理？

2. 案例学习和演练

• 每周选一个历史需求，团队一起演练如何提问
• 分析哪些问题问得好，为什么
• 总结提问的技巧和套路

3. 结对评审

• 让经验丰富的测试人员带新人参加评审会
• 会后一起复盘，讨论还可以问哪些问题
• 逐步提升提问能力

经过2个月的训练，测试人员的提问质量明显提升，能够发现很多深层次的问题。

实施建议与关键要点

5.1 从小范围试点开始

不要一开始就在所有项目中推行，建议：

1. 选择合适的试点项目

• 项目规模适中（不要太大也不要太小）
• 团队成员配合度高
• 业务复杂度适中

2. 设定明确的试点目标

• 试点周期：2-3个迭代
• 成功标准：需求返工率降低50%
• 评估方式：对比试点前后的数据

3. 及时总结和调整

• 每个迭代结束后进行复盘
• 收集团队反馈，优化流程
• 形成适合自己团队的实践方法

5.2 建立配套的工具和模板

工欲善其事，必先利其器。我们准备了这些工具：

1. 需求文档模板

• 包含必填项：功能描述、业务规则、异常处理、验收标准
• 提供示例，降低编写难度

2. 评审会议记录模板

• 记录讨论的问题和结论
• 明确待办事项和责任人
• 会后发送给所有参与者

3. 测试场景清单模板

• 基于需求快速生成测试场景
• 确保测试覆盖全面

5.3 持续度量和改进

建立数据度量体系，持续跟踪效果：

• 关键指标：
• 需求澄清率 = 需要澄清的需求数 / 总需求数
• 需求返工率 = 返工的需求数 / 总需求数
• 测试发现问题数（按阶段统计）
• 开发返工工时
• 目标设定：
• 需求澄清率：< 20%
• 需求返工率：< 10%
• 需求阶段发现问题占比：> 60%
• 定期回顾：
• 每月回顾一次数据
• 分析问题和改进点
• 调整实践方法

三个月后的成果

经过3个月的实践，我们的团队发生了显著变化：

• 量化成果：
• 需求返工率：从35%降低到8%
• 测试发现问题数：从平均每迭代20个降低到6个
• 迭代交付准时率：从60%提升到95%
• 生产环境问题：减少70%
• 团队变化：
• 产品经理：需求文档质量明显提升，很少再有歧义
• 开发人员：开发过程更顺畅，返工大幅减少
• 测试人员：对业务理解更深，测试更有针对性
• 团队氛围：协作更顺畅，相互理解和信任增强
• 客户反馈：
• 功能质量提升，投诉减少
• 交付更准时，满意度提高
• 愿意推荐给其他团队使用

结语

测试左移不是一个复杂的理论，而是一个简单但有效的实践。从需求阶段开始，让产品、开发、测试深度协作，提前发现和解决问题，就能显著提升交付质量和效率。

立即可以开始的三个行动：

1. 下周的需求评审会，邀请测试人员参加

• 不需要改变太多，只是让测试人员旁听
• 鼓励测试人员提出疑问
• 会后一起讨论收获

2. 为一个需求编写Given-When-Then格式的验收标准

• 选择一个简单的需求开始
• 尝试用Given-When-Then格式描述
• 看看是否能消除理解上的歧义

3. 统计一下上个迭代的需求返工情况

• 有多少需求需要返工？
• 返工的原因是什么？
• 如果提前发现，能节省多少时间？

记住：测试左移的核心不是增加流程，而是让正确的人在正确的时间做正确的事。从需求阶段开始，让质量成为每个人的责任，你会发现团队的工作方式发生根本性的改变。