敏捷实践之Bug Bash

简介

• Bug Bash，顾名思义就是缺陷大扫荡，是软件测试的一个很重要的实践，是对日常测试的有效补充，让大家在产品版本发布前，一起集中精力来找缺陷。在产品稳定的阶段，选取一个特定时间段邀请一组不同角色和背景的人员在会议室里对被测产品找Bug。一旦发现问题后可以请熟知产品的观察员确定是否是Bug，对发现多或者严重Bug的人员给予一些奖励。项目组成员在搜集好所有Bug和潜在Bug的清单之后，全员进行Bug分析，制定出解决的方案并实施。
• Bug Bash是一个可以给所有人学习自家产品的大好时机，是一个可以提高自家产品的质量的大好时机，是一个可以减轻上线后的工作量的大好时机。虽然我们的职责并不一样，但是我们的目标是一致的，只是希望产品发展的好，受用户喜爱，收到一份份用户给予我们的感动，公司更好的发展。
• 跟QA做的测试区别是什么？其实QA是有更专业、更全面、更完整的测试计划与策略，Bug Bash则可以补充QA的工作，发现一些QA可能没发现的问题。产品质量需要在开发的各个环节中来保证，Bug Bash作为常规测试的有效补充，也是产品上线前的重要一环。

好处

• 执行更多的测试：(1)进行更多的用户测试；(2)并发的测试，尤其是多用户同时执行不同的场景。通过Bug Bash，我们可以更好地接近用户真实使用产品的并发场景。(3)了解不在预期之内的用户行为。通过了解这些不同的预期之外的用户行为，我们能分析出哪些用户旅程User Journey是需要添加进我们的测试场景中，甚至需要加入自动化测试的。

• 更充分的测试：缺陷大扫除是常规测试的有效补充。测试团队将各个子系统连成业务系统，执行端到端（end–to–end）的系统测试，能够发现个人在子系统测试中难以发现的缺陷。此外，测试员在测试不熟悉的子系统时，没有任何先入为主的“偏见”，往往能立即发现那些被”熟视无睹“的缺陷。而资深测试员还可能发现一些初学者难以察觉的隐蔽问题。

• 更早发现更多问题：由于参与人数不同角色，更容易发现不同类型、不同层次的缺陷。程序员更了解程序逻辑和实现细节，有可能发现隐蔽的缺陷；测试员更擅长缺陷猜测和持续攻击，有可能发现其他测试员遗漏的缺陷；程序经理能够从业务角度考察软件，有可能发现业务流程、整体设计上的缺陷；内部用户是软件的使用者，有可能发现易用性、可达性上的缺陷。总之，参与者在技能和角色上的差异性有助于发现不同类型、不同层次的缺陷。

• 团队建设：在日常工作中，更多的时间在独立地工作，彼此之间的联系并不紧密，很少就产品问题进行集体交流。在缺陷大扫除中，测试员进行渗透式交流，互通情报，一起嘲笑那些拙劣的设计、滑稽的缺陷，甚至说一些无关的笑话以相互逗乐。这些小小的交流逐渐让我们的团队更加稳定。

• 团队学习：首先，大家往往很少深度使用产品，通过Bug Bash可以让团队其他角色作为用户体验产品，深入了解业务。其次，团队可以借此，总结缺陷模式（bug pattern），完善测试策略，补充测试检查列表（check list）。这是一种积极的集体学习行为，测试同学也可以从问题中累积经验。

• 更多附加价值：1）宣传项目。通过Bug Bash，我们可以邀请不同部门，不同角色，不同背景的人员参与，无形中向更多受众宣传；2）引发更多产品的思考。根据Bug Bash搜集的问题列表，项目组成员会对这些问题进行集中讨论，并详细解释如何处理以及为什么这么处理，让项目组所有成员对于产品都各抒己见，而且通过这些讨论，引发更多的思考。

局限性

• Bug Bash往往发生在开发后期，临近发布，这与敏捷测试中测试左移的思想不符，所以需要搭配开卡、桌面检查等其他实践，Bug Bash只是补充，不能单纯完全依靠Bug Bash的测试。

• Bug Bash中我们往往更关注较大的功能点，无法覆盖到很多产品业务细节，细节的用例还是需要测试能够在最初测试用户故事时设计比较详尽的的测试用例来覆盖这些测试点。

• 事先的准备：例如支付功能、权限类等功能，会比较难在一两个小时内众人来做测试，例如充值、调整权限等会比较麻烦，需要事前准备工作妥善，避免影响正常的测试。

如何成功的组织

活动准备

• 确定时间：最好在上线前，QA第二轮测试结束通过后，确保线上没有重大bug影响试用、服务是稳定的状态下，可以举行Bug Bash。
• 确定人员：提前确定好参与人员，包括测试或者团队全员，也可以邀请其他团队中有相关经验的人，提前发好会邀，沟通日程安排，尽量适合所有参与人员的时间段和时长。
• 确定地点：提前订好会议室，也可以基于宣传的考虑，我们也可以选择公共区域作为活动场地。
• 环境准备： 测试开始前，准备好稳定的预发环境，提前走一轮系统测试，确保被测产品功能基本稳定，避免出现低级问题卡点全员。其次，如果有设备、账号、用户手册等其他的要求，也需要提前准备好。
• 特性列表：准备一个产品的特性列表以供大家选择。确保我们产品中重要的特性都被覆盖到的同时，也能很大程度减少重复性测试。
• 小组划分：当所有人都开始测试，大概率会重复测试一些热点功能和场景。通过划分小组，让每个小组关注不同的领域和软件部分。
• 奖励机制：Bug Bush 需要动员团队，可以通过一些小的礼品激励团队，让大家的参与感更强、积极性更高。
• 收集方式：在开始前统一Bug的报告方式，Bug收集需要注意操作场景、步骤、测试数据、用户等。

活动进行

• 欢迎并感谢所有参与人员，说明本次测试目的、时间、流程、规范和奖励规则等，使所有人都明确Bug Bash会如何进行，以及他们在活动中需要如何测试和记录Bug。随后，我们向每个测试组分发需要测试的任务列表、测试环境和账号等。
• 当正式开始Bug Bash后，大家按照分配好的任务测试，对于确定的Bug，测试组需要记录其重现步骤，并且记录在Bug报告上。如果条件允许，还需要让测试组在测试报告中添加对应的截图。对于不确定的问题，作为观察员的QA可以适时参与确认，减少测试组在一个Bug上花费的时间。
• QA作为观察员，除了在测试组中进行协助并帮助确认发现的Bug是否有效之外，还需要观察每个测试组的行为，必要时还需要了解他们这么做的原因。如果测试组在完成某项特定的任务时有不能解决的争议时，如果QA作为观察员也没有办法说服双方，那可以暂停并切换到别的任务。此时我们也需要记录任务切换的原因和相应的细节信息。

活动结束

• 准时结束Bug Bash，并对参与者赠送一些小礼物（比如酸奶，巧克力等）来感谢大家参与测试。我们还需要对发现多Bug或者发现严重Bug的参与人员给予特殊的物质奖励，例如具有团队Logo的徽章或者T恤等。
• 整理与合并：搜集并整理所有发现的Bug，及时的确认 Bug、分类 Bug 类型、对 Bug 的优先级定级。合并重复的Bug，并且验证它们的重现步骤，尽可能附上对应的截图。然后，所有成员进行问题优先级排序，这样便于尽早解决高优先级的Bug。对需要解决的问题和团队达成一致。最后将整理结果记录并发送给团队成员。
• 问题落实：对整理好的问题达成一致后，需要落实和判断到产品上线前，哪些bug是要修好的、哪些是可以留到未来修。因为Bug Bash到产品上线时间可能已经很接近，除非是很严重的bug，或者是工作量小、效果大，可以考虑处理；其余都不应该做，这样才能保障代码的稳定性，以及准时交付。
• 自动化测试：对需要解决的问题可以考虑把它们添加到手动测试用例集和自动化测试中。从而考虑是否需要把新添加的自动化测试用例和已有的自动化测试用例进行合并，以保证所有的测试都是分层的，而且是符合测试金字塔的。
• 收集反馈：在会后收集大家对于本次Bug Bash的体验和建议，有反馈才能帮助我们提升后续活动质量。
• 学习提升：测试团队举行“缺陷检讨”会议，对有教益的缺陷进行深入分析，识别出有代表性的缺陷，分析根本原因，枚举错误症状，总结适用的测试方法，并提出避免再犯的建议。测试技巧、开发知识、有效实践可以在团队中分享并沉淀，是团队学习、个人成长的有力工具。

注意事项

• 固定时间：活动都需要固定时间，否则一下午可能直接就过去了，一般来说Bug Bash的效果会随着时间边际递减，开始的 30 mins 会发现 80% 的问题；
• 未能就此次Release的功能和代码修改的部分进行说明，使大家测试没有侧重点；
• 划分测试范围：纯粹的随机测试导致重复测试率较高效率底下；
• 避免注意力流失。 Bug Bash 会让开发人员参与，开发人员最大的特点是容易限于细节，如果在活动中发现的问题，及时报告即可，不需要对细节讨论；
• 没有奖励机制大家的积极性不高；
• 反复的Bug Bash，要有始有终，确定每次的范围、时间、目标；
• 做好记录，问题的详细记录是对后续的分析很重要的事情；
• 未能在事后积极收集反馈导致同样的问题延续到了第二次；
• 没有积极落实修复：开发时间是很紧凑的，当到第二轮测试结束后，通常离上线也没几天，如果Bug Bash提出很多需求类的bug、新需求、大改动的部份，其实已经来不及在本版本实现，就会放入需求池或之后版本实现。经常最后Bug Bash很多提出的问题或需求都会越积越多，修复之日路漫漫。
• 每迭代都做，容易失去新鲜感。不一定每个迭代都搞，可以在大版本或者累积好几个小迭代认认真真做一次大的Bug Bash、发发奖品，这样可以保持大家的新鲜感。真的觉得有必要的时候，才做Bug Bash。团队如果平常会主动走查、用户反馈也很积极，到也就不必特别做Bug Bash，我们不用为了做而做，真的是发现有价值有需求，再推动效果反而更好。

参考文档；
https://insights.thoughtworks.cn/how–to–facilitate–bug-bash/
http://t.zoukankan.com/liangshi–p-1903947.html
https://www.woshipm.com/pd/698379.html
http://www.spasvo.com/news/html/2015121141754.html

代码007普通

打赏 收藏 海报 链接