测试管理:百人团队质量保障演进:从0到1三步走
测试开发技术
共 2201字,需浏览 5分钟
·
2021-10-21 14:36
来源:软件质量报道
本文是根据演讲嘉宾朱媛媛(汽车之家经销商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提高开发提测质量,更重要的作用是代码的可维 护性好,不易出问题,形成好的编码习惯。 接口自动化开展到一定程度,也会遇到瓶颈困难,需要变通。
自己和自己比,建立基线,看趋势变好还是变差。 根据不同阶段选择关键度量数据,并不断迭代。
END
长按二维码/微信扫码 添加作者
阅读原文
评论