集体缺陷大扫除,也称为缺陷大扫雷,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真是太刺激了,之前我觉得抓虫就是测试的责任,我们提提意见就好,现在深入的感受到,测试过程也是可以很愉悦的,让团队的关系更亲密!
参与者不约而同地希望缺陷大扫除能够常态化。从此,在每个关键版本正式发布前,我们都会把缺陷大扫除活动作为“卡点”,必须完成,并输出总结。
想学习却无从下手,该如何学习?
这里我准备了对应上面的每个知识点的学习资料、可以自学神器,已经项目练手。
如果我的博客对你有帮助、如果你喜欢我的文章内容,请 “点赞” “评论” “收藏” 一键三连哦!