汽车之家测试团队质量建设三部曲

Python测试开发

共 2292字,需浏览 5分钟

 ·

2021-09-05 21:36




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

试点--->效果--->推广--->常态化。




百人团队质量内建从0到1三步走‍




内容分为5部分,带大家一起感受下百人团队---质量内建走过的路程
  • 境:

  • 第一步:破局,小步初试

  • 第二步:巩固,自动化

  • 第三步:推动,聚焦价值

  • 经验心得 




困境




传统开发模式的困境



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



第一步:破局,小步初试



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


破局三步:


造成问题的原因,抓关键点环节。
共识理念、寻找方法的指导原则,引入必要的外部力量,比如培训,建立测试左移,Google的质量观等思想。

寻找试点团队,把握关键原则,找到最合适的团队,提供必要的保姆式服务。



具体做法:面向交付的开发方式








实施过程中的各角色遇到问题与解决方案



开发角色:

  • 用例执行效果不理想:有些用例不执行或者用例不完全按照测试步骤执行; 

    ○ 解决方案:

    • 整理测试用例覆盖的bug数据,每个迭代关注数据督促开发执行;

    • 将测试用例覆盖出现的bug数作为考核指标引起重视;


  • 在本地或开发环境自测,自己构造数据导致测试结果不一致;

    ○ 解决方案:

    • 统一到测试环境,开发完成后部署完先自测,完成后在进入测试阶段;

    • 数据保证从业务层面构造,不能通过修改数据库等方式略过业务场景,无法发现问题;

    • 开发对测试数据有疑问的,测试同学帮助构造业务数据,熟悉业务的数据流程;


  • 开发每人负责一个模块,业务边界或流程上的没人负责;

    ○ 解决方案:明确组长或某个角色负责有交叉的业务自测验证;


  • 对测试用例的理解与测试同学不一致;

    ○ 解决方案:进入测试前,测试与开发沟通测试用例(一对一)+测试用例评审



测试角色

  • 测试用例不能及时提供:刚开始推行,既要写用例,提测后又要验证每条用例,测试时间并没有因为这种模式缩短,反 而更长了,且由于之前迭代的遗留测试任务,总是不能及时交付,加班也很难赶上开发的节奏;

    ○ 解决方案:

    • 短期改善期是会比之前更忙,是不可避免的,过渡期;

    • 逐步来,提供用例的需求覆盖度,从20%开始,逐步增加到80%;

    • 优化简单的需求开发自测保证,大家共同努力;

    • 跟开发沟通需求和测试点后,先提供能覆盖各种场景的测试点和粗略的预期结果,在开发完成代码时提供全部的测 试用例;


  • 用例场景考虑不全,用例不充分;

    ○ 解决方案:测试用例评审;


  • 提供的测试用例,颗粒度问题;

    ○ 解决方案:和开发团队约定一个大家都可接受、理解的程度



产品角色:

  • 需求不明确,细节没有写清楚,影响测试输出的质量和时间;

    ○ 解决方案:

    • 测试给出需求规约,由产品针对规约进行细化补充确定需求规范,并按照规范执行;

    • 流程上约定测试同学先过一遍需求文档,符合评审要求才进迭代;


  • 需求文档给出不及时,没时间充分的需求分析以及用例输出;

    ○ 解决方案:约定给出时间;


  • 需求插入或变更没有同步到测试,导致测试用例无效、返工;

    ○ 解决方案:约定需求变更截止点+要求同步到测试


效果



解决的问题:


  • 整个团队严重依赖测试,研发提测质量不稳定,越忙Bug越多,提测后的回归时间长;
    • 通过测试用例的输出,提高开发提测质量,开发自测完成功能初验和修复的工作,减少测试同学发 现bug后的回归,缩短交付周期;
  • 开发并行提交,测试串行,很多团队抱怨测试资源紧缺,功能测试周期长;
    • 测试环节前置到开发,由测试同学串行测试任务到开发并行执行,缩短交付周期;



第二步:巩固,自动化












第三步:推动,聚焦价值









 

 


经验心得


 


 

  • 从最痛的团队、最痛的点开始,先试点,看到效果在推广;
    • 不为了工具而工具,不为了自动化而自动化,从实际问题出发解决问题;
    • 容易出效果,建立信心;
  • 角色间协作流程问题比自动化工具改善效果更大;
    • 静态代码扫描等措施并不能直观的减少bug提高提测质量,更重要的作用是代码的可维 护性好,不易出问题,形成好的编码习惯;
    • 接口自动化开展到一定程度,也会遇到瓶颈困难,需要变通;
  • 建立数据度量,用于反馈改进效果;
    • 自己和自己比,建立基线,看趋势变好还是变差;
    • 根据不同阶段选择关键度量数据,并不断迭代;
  • 重复低效的事情,可自动化工具解决,提升效率,解放人力

 


分享嘉宾



朱媛媛

汽车之家经销商BU质保负责人



15年加入汽车之家后,辅助所在业务团队逐步搭建起多角色参与、多手段保证的质量保证体系;组建工具效能小组,推动工具平台从0到1的建设,并逐步完善,可提供数据工厂、静态代码扫描、接口自动化、流量回放平台、拨测系统、性能监控等专项能力,并通过质量罗盘、效率罗盘等观测指标提供数据反馈,驱动持续改进;


来源:QECon质效前沿



-------- THE END --------

🍁

浏览 52
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报