赞
踩
落地前:分析因素
从我个人的工作实践经验来看,在决定是否引入新的技术框架或者开展技术项目前,足够详尽的分析调研必不可少。
这样做的好处在于一方面可以避免重复建设;另一方面,尽可能确保投入的资源能获得足够的收益。落地自动化测试之前,主要有如下几点因素需要考量。
1、当前面临的痛点是什么?
引入自动化测试是为了解决工作过程中遇到的问题或痛点,所以在引入之前第一个要考虑的是当前面临的痛点是什么。
比如:线上功能bug频发,人力资源时间不足导致团队加班太多,版本迭代快/多版本并行等,且这些痛点都已经严重影响到了团队的日常工作效率和氛围。
先将面临的问题和痛点列出来,按照影响范围和优先级排序,然后分析背后的原因。
2、痛点背后的原因有哪些?
线上功能bug频发,可能的原因有漏测/case覆盖率不足/需求变更快/发布流程不规范等原因。
人力或者时间不足,背后的原因可能有团队同学能力不足/团队效率不高/管理混乱/缺乏提效手段和工具。
版本迭代快多版本并行的情况,背后的原因就更复杂了,涉及到流程/管理/业务成熟度/企业所处阶段等多种因素。
3、有什么可以解决问题的方案?
分析出团队面临的痛点以及背后的原因,我的建议是将原因列出来进行归类,比如:
资源问题:人手不足/工时评估不合理;
流程问题:研发交付流程混乱,发布不可控;
管理问题:团队效率不高,管理混乱,职责不清;
技术建设问题:缺乏CI/CD工具&需求/代码/case/bug管理工具,团队同学缺乏相关经验;
4、自动化是不是最合适的解决方案?
问题分类和排优先级之后,就是case by case的分析有哪些解决方案了。假设某部分问题可以通过自动化测试来解决或者改善,那就可以着手进行下一步分析。
5、当前的情况是否适合开展自动化测试?
“自动化测试适用于重复度较高的工作,且不是一蹴而就即插即用就能解决问题的。需要相对稳定的业务需求迭代、比较成熟稳定的研发团队和一定的技术基础设施建设,以及较为规范的流程才能更好的落地,达到提效的目的”。
举个例子:某创业公司,当前处于产品初创和快速迭代期,追求的是快速推出MVP产品推向市场,业务不稳定,人力资源紧张,技术基础设施很差,那这个时候是不适合做开展自动化测试的。
开展前:评估价值
罗列问题,分析原因,制定优化方案后,接下来就是项目立项及调研了。自动化测试的调研,主要关注如下几点:
工具框架选型:业内有哪些自动化测试工具或框架?功能是否满足需求?产品稳定性如何?社区活跃度如何?是否有足够详细的说明文档和使用案例。
选定试点范围:选择哪个业务或者团队进行试点?试点对场景覆盖范围和case的粒度要求是什么?
团队成员技术栈匹配度:如果工具需要一定的代码开发,团队成员编码能力如何?对哪种语言熟悉?培训和学习成本?
要投入多少人力时间资源:确定范围和case粒度后,预期需要投入多少人日/工时才能达到预期结果?
预期的投入产出比是多少:投入预期的人日/工时后,预期的效果如何?是否能解决当前面临的痛点问题?
落地过程:解决问题
其实到了研发落地阶段,只需要遇到问题解决问题即可。自动化工具或框架落地过程中,常见的问题有:
学习培训:工具或框架对于团队同学来说需要一定学习成本,建议提供使用说明手册并开展几次培训。
案例演示:其实自动化case或者脚本写起来很简单,但还是建议提供一些demo或者案例,能让其他同学更快速上手。
二次开发:很多开源的自动化工具已经具备了大部分常见功能,但落地过程中还是要解决一些定制化功能,或者修复开源工具的一些bug,这就需要一定的开发能力对工具进行二次开发或者优化。
构建效率:自动化测试并不是拿着工具把case写好就完事了,要考虑到自动化落地的初衷就是解决效率问题,因此落地后的构建执行效率是重点关注的因素。
构建成功率:除了关注构建执行效率,每次构建执行的成功率也要高度关注,否则会耗费大量时间在排查问题上。
推广运营:关注反馈&输出价值
项目落地后,真正的挑战才开始。
假设你是自动化测试落地的负责人,如何让其他团队的测试同学也能很好的用起来,并且真的解决他们的问题?
如何衡量这个项目的投入和产出,用哪些指标度量?关于这点,我建议大家从下面两点去考虑:
业务运营:解决了业务什么痛点,对业务目标达成的促进;
技术运营:用户体验、交付效率、质量提升、用户满意度。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。