专栏文章 小团队质量管理破局之路 (一篇来自 2019 年的笔记)

Jerry li · 2021年08月29日 · 最后由 Jerry li 回复于 2021年08月31日 · 6022 次阅读

背景

最近在工作中遇到一些瓶颈和困扰,然后在久违的云笔记里发现了两年前在前公司时写的这篇笔记,感觉对打开思路有点帮助。分享给大家一起思考。

前言

上次(2019 年)参加广州测试沙龙分享后最大的感触,就是大团队做的事情和我们小团队的很不一样,今天就来总结一下我们小团队的质量管理破局之路吧。

团队简介

人员对比:

我们团队的开发、测试人员比例:

  • 开发团队:7-20 人; 测试小组:1-3 人
  • 最高比例:1 vs 10 ; 最低比例:3 vs 20

工作职责

1. 产品功能范围:

  • 服务端:包括接口服务、管理后台、数据接收及处理服务等
  • SDK 客户端:包括 android、ios、h5 等
  • 大数据服务:包括数据统计和报表展现等
  • 平台前端:包括 PC 端、手机端等
  • 质量管理: -- 产品迭代开发过程中的质量管理 -- 需求收集和问题反馈跟进 -- 线上数据对比监控
  • 测试执行: -- 常规的测试用例设计、测试执行等 -- 部分服务的性能测试执行等
  • 其他: -- 业务、技术文档维护管理 -- 客户对接支持及问题跟进

工作中的难点

  • 产品各模块间关联性强,所以前期经常出现一个小修改影响到下游业务。
  • 产品初期为堆功能、赶进度,忽略了需求、设计等流程管理,偶尔出现流程出错导致的故障。
  • 产品功能不断堆积,回归测试的维护难度增大。每次上线都没有充分的测试保障。

如何解决难点

1.质量管理流程规范化

针对研发管理流程混乱的问题,与领导充分沟通后,整理发布了以下流程:

开发代码管理规范。要求开发团队将代码划分为开发库、测试库、上线库上个版本,提测的功能在完成自测后提测到测试库,测试人员测试通过后,合并到上线库进行回归测试,最后完成上线。有效减少了由于代码管理混乱,导致将未经测试的功能误发布到线上的问题。
质量管理流程。补充了需求评审、设计评审等流程,有效提高了需求开发的完成度和匹配度,减少需求返工的情况;同时也提高了设计的可靠性和扩展性。
团队分工规范化。所有需求统一由产品人员作为入口,测试人员作为最后的出口,杜绝开发人员跳过产品直接接受需求、跳过测试直接上线的情况。

2.引入自动化测试工具

  • 分别引入 UI 和接口自动化测试框架,以自动化测试用例替代部分手工测试用例,用例模板化更高
  • 以自动化替代回归测试工作中大部分的手动回归执行,有效提高回归测试的执行效率和可靠性。
  • 自动化测试于 jenkins 集成,并加入 allure 等报表工具,测试结果更直观。
  • 引入云测平台,协助完成 android、ios 端的兼容性测试。
  • 针对业务性强的数据分析模块,设计、开发对应的造数平台,实现数据自动生成和提交。

以上自动化工具的引入,逐步替代了 80% 以上的手动回归测试,充分释放人力,使测试人员可以专注于新功能的测试。

共收到 27 条回复 时间 点赞

引入自动化,确定可以释放工作量么?

恒温 回复

起码把大部分稳定模块的回归测试工作量通过自动化替代了
当然那是两年前小团队的模式,产品和环境依赖没那么大,现在的产品各种依赖太多了,自动化很难稳定下来

Jerry li 回复

大部分稳定模块的回归测试工作量通过自动化替代

这一块,怎么让它不会腐烂呢?可能一直跑,都是通过的,但是线上还是会出问题。

恒温 回复
  1. 我们每天都在测试环境跑完整的自动化,在线上环境跑冒烟用例的自动化,并且每天有对失败的用例进行维护,所以可靠性还是有保障的。 2.我们线上有对应的预警系统,捕捉到相关错误的时候会给团队成员发送邮件和短信进行报警。所以对于自动化用例覆盖不到的地方,也能比较及时地处理。

听起来没问题,走起来问题还很多

余good' 回复

是的,当时也是出了不少问题之后,测试才有了足够的发言权去推到很多流程的改进和得到开发的配合;而且小团队,落实下来也很快。

能详细写下落地这一个么,这个感觉是大多数人遇到的瓶颈

OBJ 回复

落地这个话题太大了吧😂

我尝试简单说一下:

  1. 整理有什么影响开发测试流程的问题,包括:需求 - 设计 - 开发 - 测试 - 上线全流程;分支管理;上线规范。

  2. 自动化落地:挑选使用最广泛的框架快速落地。我们使用的就是 pytest+request+allure +Jenkins 做接口自动化,pytest+selenium/appium 做 UI 自动化,基本上就可以保证你落地是没大问题的。不要在选择工具上浪费太多时间。

  3. 落地的过程不要追求一步到位。我们的过程是小步快跑,慢慢优化。以下是大概的里程碑(UI 和接口自动化都适用):
    -- 找网上的 demo 搭好本地环境,跑通 hello world。
    -- 用自己的产品界面跑通第一条 case。
    -- 调通第一个 suite,把 setup/teardown 调通。
    -- 配好 Jenkins pipeline,保证每天能跑起来。
    -- 分工,写 case。
    -- 保证每天都能有一个良性循环:早上回来看结果,修复失败用例,写新用例,晚上再跑新的 job。

只有循环开始了,用例数量不断增加和稳定通过,才能节省手工回归测试的工作量,解放人力。

上次(2019 年)参加广州测试沙龙分享后最大的感触,就是大团队做的事情和我们小团队的很不一样

小团队做得好且愿意出来分享的真的很少。下半年广州计划再来一次沙龙,有兴趣来分享下么?

逐步替代了 80% 以上的手动测试 ---- 我绝对不相信

财宝 回复

这个不太严谨,说的是 80% 的手工回归测试。

说实话,细节不够,很多地方疑问很大。举个例子,第一点,质量管理流程规范化,这个怎么做到的?仅仅是与领导充分沟通?问个实际一点问题:一个团队就 1 或者 2 个测试,主程来自某大厂(我就不点名黑了)。因为是大厂,说话权很大,但是程序对于质量管理流程不是很感冒,你如何做到推动 “开发代码管理规范”?你是测试还是开发?你如何在开发中有话语权?你进入公司前肯定已经有一套代码管理规范了,你如何推动新的代码管理规范?新旧规范又如何不同,旧规范是如何产生?太多了就不说了。哪天你去分享沙龙,能够不这么宽泛,那一定会给测试界带了不小影响的。

陈随想 回复

软技能:和开发老大搞好关系就可以推动吧,最理想的是开发团队都关系不错。
硬技能:自己有过硬的技术素质,能让开发信服。
不过具体落地的规则肯定也不只是测试一方的意见,应该是测试开发双方沟通之后形成共识的方案。

陈随想 回复

篇幅有限,就不能逐个展开说了。
对于你说的如何推动,我过来的经验,是逐个问题,逐个解决。

比如分支管理:以前的分支设计没有考虑到实际产品中的开发节奏和发布节奏的不同步问题。以前的设计只有主干开发分支和已发布的 tag,非常简单粗暴,每次发布都可能把未完成的代码给带上了;而我们测试就是针对这种设计缺陷提出质疑,并且主导和开发团队讨论之后,梳理了开发分支,测试分支,待上线分支的管理流程,并且趁机制定代码管理规范。

比如质量管理流程,契机也是某次出现了开发的功能与需求不一致,从而引发的风险。我们作为测试,也是拉着开发和需求团队一起,把整个流程中的问题给分析出来,并且主导梳理出一个完整的需求 - 设计 - 开发 - 测试 - 上线,以及缺陷修复的流程,并且监督开发团队去执行。

我知道这些流程其实大家作为质量管理人员都有对应的意识,面试的时候都会作为基本功来考察。但是落地的时候永远有这样那样的困难。

回到我这个团队的例子,能把这些落地离不开以下几个方面:

  1. 充分借助合适的契机去向你的开发团队推销这套流程,从测试的专业角度去为团队发现问题,预警风险和改进。不要轻易放过任何一个现有流程上问题,抓住改进的机会。

  2. 如何赢取开发团队的信任和配合。针对发现的问题进行改进,而不是针对人;列举风险和合理,可行的改进建议,并且主导落地。

  3. 另一个有趣的方面,是我们测试在这个团队的一个优势在于对产品,业务的熟悉程度比开发要强很多,能在需求评审,设计评审阶段提出很多正确的建议,替开发减少很多潜在的风险。当开发面对着一个能帮他兜底的业务专家时,自然也会配合测试做对应的工作。

  4. 能为团队效率提升贡献能力。比如把接口测试封装好,让开发可以直接在 Jenkins 触发去做测试;比如写个造数脚本,方便开发进行自测,等等,测试自然会成为团队里有一定话语权的人。

同意。 一个处于发展期的团队,特别是早期,其实有非常多环节是会被选择性忽略的,有些团队甚至前期都不会有测试,而是开发自测;但是一旦测试团队接人了,就有责任把这些缺少的环节一一补上:把没有的流程梳理起来,把简单粗暴的开发行为引导,约束起来。

陈恒捷 回复

谢谢邀请。不过那是我两年前的团队了,估计现在讲也不合适。

小团队 搞自动化,投入是多大啊

老哥,你这个理解其实不是很准确的。软技能不仅仅指测试和开发关系好,更重要的是产品和开发关系好。有很多时候测试和开发关系不好,是因为产品(策划)和开发有矛盾,战火烧到了测试这边。真正待过小团队的人才深有感悟(鄙人不才,做过大厂外包(偷学技术,偷学流程管理),也待过小团队,真的是从 0 到 1 的那种小团队)。所以光是测试和开发关系好,没什么卵用的。至于硬技能,过硬的技术永远没有上限,开发信服你和你技术过硬没有必然联系,最多就是有那么一丢丢影响。我做外包,有个服务端老哥和我关系特别好,甚至主动开车送我下班(顺路),但那个时候我刚毕业,没有所谓的过硬技术。这种事要看人的,我那个服务端老哥深知,他做的系统质量不止我,还有他都是要负责任的,所以他也很希望我能够测试好;而有些人则是认为,系统质量和开发无关,出事了都是优先丢锅给产品或者测试,这种心态的人永远都教不好的。这种思想才是真正决定开发愿不愿意去相信一个测试,去和测试合作共扶质量。当你真心认为你是团队一员的时候,你就会愿意去相信你的队友,去和他们共同成长。

陈随想 回复

我觉得你这个也是特例吧,我也在小团队呆了三年多,然而并没有这种复杂的办公室政治关系。

Jerry li 回复

说实话,我苦思冥想破局之法,如今苦战快 2 年,无不以失败告终。如今方明白,人之品德,重如泰山。在现在压力颇大的社会中,很多人的心早已变质了。只是唯恐我,哪一天也变成和他们一样。(我多说一句,我司有一人,上家公司开除过他,原因为嘴臭,此事是项目主管和我亲口所说。此人影响极大,因为该职位只他艺一人,其余众人皆与他矛盾,苦他久矣)

陈随想 回复

感觉老哥你对这个团队有点执念啊😂

如果是我的话,努力也改变不了团队,可能是这个团队不适合你,换一个更好的呗

Jerry li 回复

主程走了,另一个老哥暂时充当。我答应过这个老哥,陪他一起支撑一下团队。

HouYuanbing 回复

pytest+ selenium 做 UI 自动化,pytest+request 做接口自动化。都是网上很多介绍的框架,不需要花很多时间来搭建。

至于写用例和维护,看你们团队和产品是否合适了,我们当时可能 20% 到 30% 的时间在自动化上。

财宝 回复

看这个回归怎么定义,如果仅仅是系统的主流程,80% 还是很容易覆盖的,不管是 UI 的还是接口的,能够称之为核心的会有多少。

还以为是小团队管理经验😂

陈小猫 回复

小团队,就是自己管自己😅

lee 回复

环境不同,理解不一样。
连我自己到了新团队之后看着那惨不忍睹的自动化通过率,也一度怀疑自己以前做的是假自动化😂

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册