敏捷测试转型 聊聊集体缺陷大扫除

鼎叔 · 2022年10月17日 · 最后由 鼎叔 回复于 2022年10月22日 · 6964 次阅读

这是鼎叔的第三十六篇原创文章。

行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》,大量原创思考文章陆续推出。
集体缺陷大扫除,我也叫它 “集体冒烟探索测试”,是敏捷团队质量共建最重要的活动,没有之一。探索式测试天然就适合集体进行,在正确的组织形式下,通过团队放大探索测试的惊人效果,让探索测试理念深入人心。按照测算,有了团队的氛围加成,单位时间内探索的成果收益可以提高 4 倍以上!

本文是关于探索式测试第五篇文章。相关文章在本专栏可以查阅:聊聊什么是探索式测试,聊聊产品的局部探索和全局探索,聊聊探索式测试落地的全流程,聊聊谁能成为探索式测试高手

集体缺陷大扫除,也可以命名为缺陷大扫雷,Bug BASH,Team Explore 等,目标是在发布前最后检查一轮,尽可能发现残留的严重缺陷。在本活动的组织形式上牢牢把握三点,即比赛制、不争论、跨角色参与

比赛是最好的氛围催化剂。那能否把找 Bug 当作比赛呢?

参与者在 1-2 个小时的测程中,集中全部精力,运用各方面的知识经验,比赛谁找到的 Bug(也可以包括好的产品建议)数量最多,获胜者有惊喜小奖励。
比赛过程时间有限,如果因为提出 Bug 被质疑有效性,陷入着急澄清业务逻辑的环节,那时间就很快过去了,影响比赛效果。建议比赛中设置一个记录员,专门确认各位参赛同学提出的缺陷名称和截图,作为汇总的参考。
比赛鼓励项目组不同岗位角色共同参与,包括产品人员、开发人员、项目经理、运营人员,甚至普通用户。也可以跨业务团队互相邀请。

组织这个缺陷大扫除的通用流程如图所示。

挑选适合做缺陷大扫除的产品,最好是有 UI 界面,能快速验证结果的项目。对于复杂的算法测试,底层框架测试,可能不太适合这种全民活动。在活动前进行预热,鼓励大家积极参与集体探索,占用时间有限,优胜者有奖励。
如果报名人数较多,产品比较复杂,可以对探索产品做一定程度的分区,比如以本次新发布的功能探索为主,每个人以特定的特性分区为主要探索区域。
准备好集体大扫除的环境,会议室,如果有零食饮料更佳!
准备好测试环境,必要的测试数据和工具,安装包,足够的终端设备。
活动进行中,组织者强调大扫除的纪律,规则,并介绍本次测试对象(产品)的探索重点。
活动完成时,组织者根据搜集有效问题的数量(和等级),宣布优胜获得者,并颁发奖品。

最关键的环节来了:每个参与者谈一谈,自己参加缺陷大扫除的体会,以及收获。

缺陷大扫除过程的现场图片


活动结束后数天,组织者将精心准备的缺陷大扫除报告,发布给业务团队,对参与同学表示感谢,激励更多同学积极参与未来的大扫除活动。

收获和启示
缺陷大扫除的收益往往出乎意料,根据我的实际组织情况,10 个参与人,2 个小时往往能发现高达 80,甚至 100 个有效缺陷及建议!相较于日常测试过程,发现 Bug 的效率提高了 4 倍,而且还是在已经完成了一轮系统测试的稳定版本上,新发现了很多的问题。

正因为数量惊人,质疑声也随之而来。缺陷大扫除在稳定版本还发现这么多问题,是不是测试人员专业度不够,漏测严重?

并非如此。

不同角色、不同人员在测试产品的探索角度不同,对产品各维度信息的认知不同,他们的输入对于现有测试计划是非常完整的补充。测试人员在日常测试中会逐渐形成自己的习惯,通过在本次活动中对其他成员探索 Bug 方式的观察,对于扩展自己找 Bug 的技巧盲区会有很大启示。

另外,测试人员作为缺陷探索的组织者和分析者,自身也实现了测试产出的关键价值,把 Bug 暴露在发布之前。

大扫除最后一个环节-所有角色谈感想,是点睛之笔,因为大扫除的核心价值是全民为质量负责,团队并肩作战,质量必须内建,通过理性和感性的形式把共同负责的文化传承下去。我们经常能听到令人动容的感想,比如:

测试外部合作伙伴:以往时常感觉自己是个提 Bug 的机器,通过这类活动,我能够对产品和开发提出更多有建设性的意见,同时我看到其他岗位的同学还有这种找 Bug 的技巧,开了眼界,感觉测试也是很有乐趣的:)

测试组长:活动的数据打破了我的固有认知,从来没测过这个产品的测试同学,发现 Bug 的效率甚至高于经常测这个产品的同学,看来找 Bug 有经验并不是优势,固有思维是有害的。

开发工程师:我自己写的代码,没想到质量这么差,我第一次感到如此汗颜!刚才我差点偷偷提交修改代码,在比赛完成前把 Bug 赶紧消灭掉:(

刚才已和主管达成一致,下个月我们把新版本需求计划修改一下,专门做一轮重构,消灭掉大多数遗留问题!

产品经理:不同成员从不同的视角来体验我们的产品,共同思考,产生了实际的效果,请将活动常态化进行吧!不,应该强制执行, 两个小时过得太快了:)

设计同学:集体比赛找 Bug 真是太刺激了,之前我觉得抓虫就是测试的责任,我们提提意见就好,现在深入的感受到,测试过程也是可以很愉悦的,让团队的关系更亲密!

参与者不约而同地希望缺陷大扫除能够常态化。从此,在每个关键版本正式发布前,我们都会把缺陷大扫除活动作为“卡点”,必须完成,并输出总结。

共收到 8 条回复 时间 点赞

如何避免缺陷大扫除流于形式,除了发起者例行发起外,几乎收集不到有效缺陷反馈

事实上,a 组测试完毕的东西给 b 组测,确实可以发现很多之前忽略的问题,给我的感觉有点类似交叉测试

不错,让大家参与,从不同的角度发现问题

不错的团队活动。

挺有意义的活动

之前的测试 leader 对于平时产出 bug 多的成员也会有奖励,导致大家都很积极,这个活动很有意义呀,有竞争就有效率~

imath60 回复

我的一些经验:组织一次不要过于频繁,针对核心发布版本,尤其是 APP,前端发布的。
拉的人可以轮换,不用太多,8-15 人足以
文中介绍了,比赛制,有奖励,有复盘谈心,有成果输出
除了测试,鼓励拉其他角色参与,领导重视
这个活动还是会火的

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