业务转型中测试左移的文化建设挑战

1.

2.

3.

4. O1 O2 O3 O4 讲一个故事目前的困难突破的方法落地的问题

5. 讲一个故事背景/经过/结果

6. 讲一个故事-背景公司：中小规模团队：和开发团队一起，测试团队 20 人左右 0 4 模式：敏捷（快速）开发（迭代）需求：周一确定需求，周三提测，周五发布 0 3 结果疲劳发布，问题漏出，紧急修复 0 2 0 1 背景小公司，小团队，紧急需求经过需求变更，提测延期，冒烟失败问题前序流程缺失或不规范

7. 讲一个故事-经过需求：没有需求文档，产品和开发口头沟通，开发过程中需要反复确认细节。 0 4 开发：没有需求文档，加上没有技术评审，直接上手操作，开发进度出现延误。 0 3 结果问题前序流程缺失或不规范疲劳发布，问题漏出，紧急修复 0 2 0 1 背景小公司，小团队，紧急需求经过需求变更，提测延期，冒烟失败测试：发现一个常规异常逻辑没有考虑，出现需求变更，冒烟测试发现一个关键实现问题，提测打回。

8. 讲一个故事-结果 0 4 0 3 结果问题前序流程缺失或不规范疲劳发布，问题漏出，紧急修复 0 2 0 1 背景小公司，小团队，紧急需求经过需求变更，提测延期，冒烟失败因为时间被压缩，周五半夜才发布上线；因为发布太晚，周末需要加班值守；因为流程时间太紧张，测试平台覆盖不全，导致漏出一个文件依赖的问题；周末加班继续做问题的紧急修复，身体累，心累，感觉被掏空。

9. 讲一个故事-问题 0 4 0 3 结果问题前序流程缺失或不规范疲劳发布，问题漏出，紧急修复 0 2 0 1 背景小公司，小团队，紧急需求经过需求变更，提测延期，冒烟失败需求评审环节缺失；技术评审环节缺失；开发自测和基本代码质量没保证；提测卡点不到位；

10. 目前的困难业务优先/困在当下/责任重大

11. 目前的困难-业务优先你先帮我试一下，没问题我再提测我没有环境，你帮忙冒个烟研发这版先这样，下一版再说我先简单说一下，后面再补文档我就改了一行代码，简单测下就行功能我测了没问题，冒烟下就可以发测试需求一切为了业务质量效率这个风险比较大 VS 出了问题算我的这个问题必须修 VS 我去走特批什么时候上线？什么时候上线？什么时候上线？

12. 目前的困难-困在当下流程不规范需求评审，技术评审，开发自测，代码扫描，提测卡点等环节缺失时间没保障需求变更，提测打回，压缩测试时间资源不充足主要是人力资源，会出现并行工作，或者马不停蹄的情况

13. 目前的困难-责任重大为什么没有发现这个问题？需求不清晰，修改影响范围不明确，没有足够时间覆盖所有的兼容性场景为什么为什么为什么为什么允许带这个问题就发布？测试的一票否决权，往往让步于业务目标的达成，毕竟质量嘛，真的出现了问题，才意识到问题的严重性为什么为什么为什么测试时间这么长？需求细节传递不明，修改影响范围界定不清，反复出现不该出现的问题

14. 突破的方法流程左移/工具左移

15. 突破的方法流程左移工具左移项目相关人员都尽可能的需求合理性确认后，就需要考参与需求评审，优先讨论虑需求的全面性，特别是异常需求的合理性问题，并需场景和异常分支，这部分是最要经过各角色确认容易导致需求变更的

16. 突破的方法-流程左移需求调研左移需求质量左移让测试也参与需求调研的讨论阶段，相对来说，测试同学必须参加需求评审会议，分别从需求合我们对于用户视角的问题会有更多关注，特别是理性（如果参与调研，可以不关注）和全面性上需求合理性上，可以提出自己的观点。进行补充。设计质量左移代码质量左移有条件的话，尽可能的在编码前，推动开发进行推进开发提测 Review 的流程，有条件的话，可以技术评审，包括技术实现的架构，接口定义等等。做到提交 Review 的程度，尽量避免在发布前才进行代码 Review。

17. 突破的方法-流程左移

18. 突破的方法-工具左移冒烟测试工具静态代码检查工具比如我们会有功能模块的 PVT 工具，可以提现在有很多开源的静态代码检查工具，可以供给开发在提测前进行冒烟测试。根据自己项目使用的语言选择合适的工具，当然也可以定制化开发。接口测试工具单接口，以及接口间的调用，尽可能通过单元测试进行覆盖，测试可以提供支持。代码覆盖率有条件的，可以进行代码覆盖率的支持，进一步增加测试的粒度，更多维度进行质量保证。

19. 突破的方法-工具左移

20. 落地的问题改进内容太多/队友不配合

21. 落地的问题-待改进内容太多怎么办先主后次由大及小先解决效果明显的关键问先把该有的做起来，哪怕只有一题，再解决其他问题点，后面可以逐步完善 1 2 3 4 5 先找关键问题并落实到行动需求评审的流程是关键问静态代码的规则可能有很需求评审环节逐渐加强要题，而且是流程的起始，多，可以先只生效一条确求，静态代码检查可以逐必须优先解决定的规则，保证落地步增加检查规则再优化完善细节

22. 落地的问题-队友不配合怎么办卡需求确认卡代码红线卡编译提测异常数据记录提测时必须关联已编译发现代码红线的，自测不通过，或者提测冒烟失败，需确认通过的需求，不准提测，必须处理基本属性检查不通求变更，可以提前测试需要参与需求完红线问题后，才可过的，禁止提测。规避的问题发现，确认的流程中去。以继续流程。都进行详细数据记录。

23. 落地的问题-队友不配合怎么办

24. 落地的问题-队友不配合怎么办

25. 落地的问题-队友不配合怎么办

26. 360技术 THANKS 360质量效能