百人团队质量内建：从0到1三步走 | IDCF

来源：软件质量报道

本文是根据演讲嘉宾朱媛媛（汽车之家经销商BU质保负责人） 2021年8月21日在 Q&E meetup online 分享整理而成。

团队背景：质量内建三个阶段，从开始尝试到推广到整个技术团队，变成常态化，每个阶段大概都是1年时间。团队规模是150左右，分7、8个业务开发团队，推广过程中在试点团队观察3个月，每个月都会总结复盘，3个月试点结束，然后一个业务组一个业务组的推广。每阶段定好一个建设目标，然后：试点--->效果--->推广--->常态化。

一、困境 

1.1 传统开发模式的困境

这种模式下，测试作为上线前最后一个环节，整个产品的质量都压在测试环节，没有充分的测试时间，通常情况是bug能被测出来就会被提前发现，测不出来就会留到线上，变成线上问题，再靠团队“救火” ，而且这阶段Bug发现成本也很高。这种模式下，测试人员是最痛的角色。 

二、第一步：破局，小步初试

2.1 从测试团队开始推进，搭建质量体系三步

破局三步：

• 造成问题的原因，抓关键点环节。
• 共识理念、寻找方法的指导原则，引入必要的外部力量，比如培训，建立测试左移，Google的质量观等思想。
• 寻找试点团队，把握关键原则，找到最合适的团队，提供必要的保姆式服务。

• 整理测试用例覆盖的bug数据，每个迭代关注数据督促开发执行。
• 将测试用例覆盖出现的bug数作为考核指标引起重视。

• 统一到测试环境，开发完成后部署完先自测，完成后在进入测试阶段。
• 数据保证从业务层面构造，不能通过修改数据库等方式略过业务场景，无法发现问题。
• 开发对测试数据有疑问的，测试同学帮助构造业务数据，熟悉业务的数据流程。

• 明确组长或某个角色负责有交叉的业务自测验证。

• 进入测试前，测试与开发沟通测试用例（一对一）+测试用例评审。

• 短期改善期是会比之前更忙，是不可避免的，过渡期。
• 逐步来，提供用例的需求覆盖度，从20%开始，逐步增加到80%。
• 优化简单的需求开发自测保证，大家共同努力。
• 跟开发沟通需求和测试点后，先提供能覆盖各种场景的测试点和粗略的预期结果，在开发完成代码时提供全部的测 试用例。

• 测试用例评审。

• 和开发团队约定一个大家都可接受、理解的程度。

• 测试给出需求规约，由产品针对规约进行细化补充确定需求规范，并按照规范执行。
• 流程上约定测试同学先过一遍需求文档，符合评审要求才进迭代。

• 约定给出时间。

• 约定需求变更截止点+要求同步到测试。

• 通过测试用例的输出，提高开发提测质量，开发自测完成功能初验和修复的工作，减少测试同学发 现bug后的回归，缩短交付周期。

• 测试环节前置到开发，由测试同学串行测试任务到开发并行执行，缩短交付周期。

三、第二步：巩固，自动化

四、第三步：推动，聚焦价值

五、经验心得

• 不为了工具而工具，不为了自动化而自动化，从实际问题出发解决问题。
• 容易出效果，建立信心。

• 静态代码扫描等措施并不能直观的减少bug提高开发提测质量，更重要的作用是代码的可维 护性好，不易出问题，形成好的编码习惯。
• 接口自动化开展到一定程度，也会遇到瓶颈困难，需要变通。

• 自己和自己比，建立基线，看趋势变好还是变差。
• 根据不同阶段选择关键度量数据，并不断迭代。