网易方法论：手把手教你做Bug Bash（缺陷大扫荡）
|
副标题[/!--empirenews.page--]
BugBash，即，缺陷大扫荡。产品版本发布前，团队全员集中起来、共同找Bug。是软件工程、互联网产品开发过程中，验证环节很重要的一个活动。
Bug Bash，顾名思义就是缺陷大扫荡，让大家在产品版本发布前，一起集中精力来找缺陷。是软件工程、互联网产品开发过程中，产品验证很重要的一个活动。通常可以由项目经理或QA主导发起。 什么时候做？建议是在上线前，QA第二轮测试结束通过后，确保线上没有重大bug影响试用、服务是稳定的状态下，可以举行Bug Bash。 但这边有个两难是：确实等到前面描述的状态完成后，bug bash比较正规，团队不会因为重大bug而block各环节的试用，而且是比较接近上线后用户的使用状态；但坏处是通常开发时间是很紧凑的，当到第二轮测试结束后，通常离上线也没几天，如果BugBash提出很多需求类的bug、新需求、大改动的部份，其实已经来不及在本版本实现，就会放入需求池或之后版本实现。经常最后BugBash很多提出的问题或需求都会越积越多，修复之日路漫漫。 当然解决方式，可以在提测后，就邀请产品策划、交互、视觉针对产品做个验收，确认产品是否跟设计符合，以及是否有些需求bug、新需求、改进提出，可以减少Bug Bash时的需求类bug的数量，及早让团队因应。 跟QA做的测试区别是什么？有同学会问：那是不是我们可以只做Bug Bash，不需要QA了？其实QA是有更专业、更全面、更完整的测试计划与策略，Bug Bash则可以补充QA的工作，发现一些QA可能没发现的问题。或者当QA人力不足时，众人一起找bug的效率也较高。 加上Bug Bash参与者多，更能发现兼容性或用户登入、权限差异等问题， 事先就可以约定好哪些人分别使用不同浏览器、手机、作业系统来找问题。而且一样米养百样人，大家对於产品操作的理解，也会差距十万八千里；加上多人同时协作来使用系统，这个操作的复杂度就会呈现指数级的差异，可能会发现在测试环节不容易找出的复杂bug。QA在设计测试用例只能针对功能点来测，但许多新功能点交叉加上老的功能点，复杂度也会增加，这就需要众人齐力发现复杂性bug，使得质量更有保障。 有QA同学做测试，不做Bug Bash是可以的；但是只做Bug Bash，没有QA则是很大问题。 为什么做Bug Bash？团队集体试用，发现需求可能有人觉得Bug Bash都提需求会不会走偏？其实提新需求也是很重要的，因为Bug Bash中，我们的角色就不只是研发团队，也是以用户的角度来看产品。如果内部团队自己都有觉得很多需要添加的需求，那产品经理或策划也该好好考虑调整产品的设计。网易教育产品的项目经理也针对这问题做过问卷，团队原本都是对於在Bug Bash提建议有疑虑，问卷统计出来，大部分人还是支持在Bug Bash提需求与bug都可以。 此外在Bug Bash前，开发都只是专注在自己的部份，可能都没有完整真正试用过整个产品，要促使团队自己主动去试用比较难。当测试第一二轮结束后，Bug Bash是一个强制的活动，促使大家真正把自己做的产品用一遍。很多之前只是在设计、交互稿看到的都只是纸上谈兵，真正用起来，才会发现问题或需求，也是看交互与文案是否容易被大家理解。所以我负责的兩個项目，经常是新需求以及需求类的bug多过开发产生的bug数。 及时梳理，发布前的剩余事项用户手册、环境、帐号等等，由于大家要开始使用，会促使团队思考上线还缺什么。由于开发与测试同学对于产品操作、环境都很熟，但在BugBash时，视觉、交互、策划、项目管理都可能第一次看到成品，应该思考：用户手册看的懂吗？数据库资料有没有准备好？等问题，让产品上线前准备更完善。 游戏化激励团队如果光只是宣导：「大家要注意质量喔」、「QA要尽量找出bug喔」，或者要求大家工作职责，可能团队成员执行的动力就比较薄弱。但藉着bug bash，其实就是一种工作游戏化，透过大家聚集一起参与，然后加一些比赛的元素，会让大家有个冲劲要努力找出bug，比谁找的bug数最多。这边有一点要注意，主持人项目经理或QA不用只是在旁边观看或加油，也应该积极参与，一马当先多找一些bug出来，来提升大家参与度。当然最后可以利用统计工具，计算一下大家的排名与bug数给予奖励。 团队平时自己可能会做团建，有些团队不一定常搞活动。在这种类似游戏化的活动中，会促进团队间彼此的沟通、良性竞争，对于整体团队建设也是很有帮助的。如果项目经理要办Bug Bash，其实可以弄的热闹一点，变成一种团建。 如何做BugBash？说明规则：准备一份ppt可以在周会上，跟团队宣导说明：什么是bug bash、宗旨跟目的是什么、时间地点是什么、准备工作确认、游戏规则等，方便大家可以随时查阅Bug Bash规则。问题记录的工具：如果有用jira，先确认大家都有jira 6的权限、并可以建立一个叫Bug Bash的模块（也可以是标签，只要方便筛选、统计）。没有jira也可以用云协作、Google doc、Wiki工具来代替，甚至每人发一张纸笔也一样可行，只要方便大家纪录，结束好统计即可。提醒大家做好准备：包括用户手册、环境是否都准备好、权限都开了没、测试是否确保重大bug修复并验证完毕。如果有经费，准备一些点心、水果、奖品，更有助于提到大家参与的兴致。会议场地：项目组如果人少且都有笔记本电脑，可以借一间大会议室，方便随时讨论、合作、排除问题，让大家能更集中投入这活动，气氛也会更热烈。但是如果没有办法借到大会议室或者大家都是台式机不方便移动也没关系，只要座位距离不远、使用即时通讯软件沟通，也一样可以把BugBash做的有声有色。统计工作：Bug Bash结束后，项目经理要统计全部issue数、有效bug数、需求数（案例见下图）。并检查是否有重复提交的问题，若有重复可以按照提交时间的先后顺序，决定这题算是谁的，或是各得一半的分数。然后再把bug跟需求区分开来。另外有些团队也可以根据提bug的价值与重要程度，给予不同奖励。当然bug bash如果经费允许，可根据不同表现，给予对应同学一些奖励，促进大家积极参与。最后也最重要的是，Bug Bash活动之后的问题落实。团队要开个会，大家一起整理所有提出issue的优先级：判断到产品上线前，哪些bug是要修好的、哪些是可以留到未来修。因为Bug Bash到产品上线时间可能已经很接近，除非是很严重的bug，或者是工作量小、效果大的（性价比高），可以考虑处理；其余都不应该做，这样才能保障代码的稳定性，以及准时交付。当然这版本不修的bug、不能实现的需求，可以标示重要性为minor放到需求池，在未来版本去实现。BugBash问题反思每迭代都做，容易失去新鲜感我在几个项目内推动，第一次一定是大家非常有新鲜感，参与度高。但是每个月迭代下来，大家逐渐对於这活动会失去激情。项目经理这时候就要好好反思一下，该如何改善与调整。我自己的经验有两个思路： 不一定每个迭代都搞，可以在大版本或者累积好几个小迭代认认真真做一次大的Bug Bash、发发奖品，这样可以保持大家的新鲜感。 （编辑：南京站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
