百人团队质量内建：从0到1三步走
团队背景：质量内建三个阶段，从开始尝试到推广到整个技术团队，变成常态化，每个阶段大概都是1年时间。团队规模是150左右，分7,8个业务开发团队，推广过程中在试点团队观察3个月，每个月都会总结复盘，3个月试点结束，然后一个业务组一个业务组的推广。每阶段定好一个建设目标，然后
试点--->效果--->推广--->常态化。
百人团队质量内建从0到1三步走
困境：四大问题
第一步：破局，小步初试
第二步：巩固，自动化
第三步：推动，聚焦价值
经验心得
困境
传统开发模式的困境
第一步：破局，小步初试
破局三步：
造成问题的原因，抓关键点环节。共识理念、寻找方法的指导原则，引入必要的外部力量，比如培训，建立测试左移，Google的质量观等思想。
寻找试点团队，把握关键原则，找到最合适的团队，提供必要的保姆式服务。
具体做法：面向交付的开发方式
实施过程中的各角色遇到问题与解决方案
开发角色：
用例执行效果不理想：有些用例不执行或者用例不完全按照测试步骤执行；
○ 解决方案：
整理测试用例覆盖的bug数据，每个迭代关注数据督促开发执行；
将测试用例覆盖出现的bug数作为考核指标引起重视；
在本地或开发环境自测，自己构造数据导致测试结果不一致；
○ 解决方案：
统一到测试环境，开发完成后部署完先自测，完成后在进入测试阶段；
数据保证从业务层面构造，不能通过修改数据库等方式略过业务场景，无法发现问题；
开发对测试数据有疑问的，测试同学帮助构造业务数据，熟悉业务的数据流程；
开发每人负责一个模块，业务边界或流程上的没人负责；
○ 解决方案：明确组长或某个角色负责有交叉的业务自测验证；
对测试用例的理解与测试同学不一致；
○ 解决方案：进入测试前，测试与开发沟通测试用例（一对一）+测试用例评审
测试角色
测试用例不能及时提供：刚开始推行，既要写用例，提测后又要验证每条用例，测试时间并没有因为这种模式缩短，反 而更长了，且由于之前迭代的遗留测试任务，总是不能及时交付，加班也很难赶上开发的节奏； ○ 解决方案：
短期改善期是会比之前更忙，是不可避免的，过渡期；
逐步来，提供用例的需求覆盖度，从20%开始，逐步增加到80%；
优化简单的需求开发自测保证，大家共同努力；
跟开发沟通需求和测试点后，先提供能覆盖各种场景的测试点和粗略的预期结果，在开发完成代码时提供全部的测 试用例；
用例场景考虑不全，用例不充分；
○ 解决方案：测试用例评审；
提供的测试用例，颗粒度问题；
○ 解决方案：和开发团队约定一个大家都可接受、理解的程度
产品角色：
需求不明确，细节没有写清楚，影响测试输出的质量和时间； ○ 解决方案：
测试给出需求规约，由产品针对规约进行细化补充确定需求规范，并按照规范执行；
流程上约定测试同学先过一遍需求文档，符合评审要求才进迭代；
需求文档给出不及时，没时间充分的需求分析以及用例输出；
○ 解决方案：约定给出时间；
需求插入或变更没有同步到测试，导致测试用例无效、返工；
○ 解决方案：约定需求变更截止点+要求同步到测试
效果
解决的问题:
整个团队严重依赖测试，研发提测质量不稳定，越忙Bug越多，提测后的回归时间长； 通过测试用例的输出，提高开发提测质量，开发自测完成功能初验和修复的工作，减少测试同学发 现bug后的回归，缩短交付周期； 开发并行提交，测试串行，很多团队抱怨测试资源紧缺，功能测试周期长； 测试环节前置到开发，由测试同学串行测试任务到开发并行执行，缩短交付周期；
第二步：巩固，自动化
第三步：推动，聚焦价值
经验心得
、
从最痛的团队、最痛的点开始，先试点，看到效果在推广； 不为了工具而工具，不为了自动化而自动化，从实际问题出发解决问题； 容易出效果，建立信心； 角色间协作流程问题比自动化工具改善效果更大； 静态代码扫描等措施并不能直观的减少bug提高开发提测质量，更重要的作用是代码的可维 护性好，不易出问题，形成好的编码习惯； 接口自动化开展到一定程度，也会遇到瓶颈困难，需要变通； 建立数据度量，用于反馈改进效果； 自己和自己比，建立基线，看趋势变好还是变差； 根据不同阶段选择关键度量数据，并不断迭代； 重复低效的事情，可自动化工具解决，提升效率，解放人力
获得完整的演讲PPT，请关注公众号，输入“三步走”。
分享嘉宾
汽车之家经销商BU质保负责人
15年加入汽车之家后，辅助所在业务团队逐步搭建起多角色参与、多手段保证的质量保证体系；组建工具效能小组，推动工具平台从0到1的建设，并逐步完善，可提供数据工厂、静态代码扫描、接口自动化、流量回放平台、拨测系统、性能监控等专项能力，并通过质量罗盘、效率罗盘等观测指标提供数据反馈，驱动持续改进；
（已进入倒计时）
（早鸟票正在销售）
点击下方阅读原文，查看官网~~