此文已由作者夏君授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
BugBash源至微软概念,翻译为《缺陷大扫除》,顾名思义是集中大家力量全面清扫Bug,确保产品质量。
下面通过5w1h分析方法谈谈BugBash活动:
What 什么是BugBash?
BugBash活动就是给项目产品找出Bug的活动。该活动主要在产品发布前,由项目主管或者QA发起,召集各种角色来体验产品,让各种类型的Bug尽早发现,Bug趋势尽早收敛。
Why 为什么开展BugBash?
互联网行业产品迭代周期短,QA与开发处于半敏捷状态,包括前期的需求评审,发起BugBash,而不只是从测试人员角度发现问题,可以集产品、项目主管、运营、甚至其他业务团队成员所有人的力量,让各种类型的BUG尽早发现,可以在项目周期短的前提下,让Bug趋势尽早收敛。尤其是移动端产品、全新上线产品,介入BUGbash是十分必要的。
注意:
不是每个迭代都需要开展BugBash,可以在大版本或者累积好几个小迭代认认真真做一次大的BugBash、发发奖品,这样可以保持大家的新鲜感。另一个是,真的觉得有必要的时候,才做BugBash。团队如果平常会主动走查、用户反馈也很积极,到也就不必特别做BugBash,我们不用为了做而做,真的是发现有价值有需求,再推动效果反而更好。比如网易金融智投组合基金的项目,QA同学与开发负责人测试时间被压缩紧张,需要调动大家一起来BugBash,反而这样大家自己参与度高,积极性更高,最后大家体验得也high。
有人会问BugBash是不是什么功能都要测?其实也有限制。例如组合基金后台交易对账清算功能、需要时间效应,用户交互无感知,需要业务底层数据逻辑,会比较难在一两个小时内众人来做测试,对于团队来说,要真的体验整个产品整个生命周期、还是要调动相关人员关注几个交易日资产状态、金额及收益变化等,会比较麻烦,反而会阻碍其他功能的试用。这类功能,一般尽量让专业QA来做测试。当然如果项目组事前准备工作妥善,当然BugBash能覆盖这类功能是最棒。
Where 在哪里开展BugBash?
需要选择一个集中的环境,比如大培训室,这样保证大家都不被打扰和中断,能集中精力找Bug。
Who 谁来参加BugBash?
参与的人员,应该包括项目组全体成员,比如开发、测试、项目经理等等,有资源条件,也可以邀请非本部门团队来参与体验,比如会咨询用研部门的同事一同来体验产品
When 什么时候开展?
项目迭代测试一般为3个周期,建议是在上线前,QA第二轮测试结束通过后,确保线上没有重大bug影响试用、服务是稳定的状态下,可以举行BugBash。时间点我倾向于选择项目中后期,功能基本稳定后,但是也不能太晚,假设在快要发布前做Bug bash,发现的Bug没有时间得到修改,那作用也会打折扣。Bugbash的执行时间,根据项目的规模吧,我觉得可以定1个小时左右。但这边有个两难是:确实等到前面描述的状态完成后,bug bash比较正规,团队不会因为重大bug而block各环节的试用,而且是比较接近上线后用户的使用状态;但坏处是通常开发时间是很紧凑的,当到第二轮测试结束后,通常离上线也没几天,如果BugBash提出很多需求类的bug、新需求、大改动的部份,其实已经来不及在本版本实现,就会放入需求池或之后版本实现。经常最后BugBash很多提出的问题或需求都会越积越多,修复之日路漫漫。
当然解决方式,可以在提测后,就邀请产品策划、交互、视觉针对产品做个验收,确认产品是否跟设计符合,以及是否有些需求bug、新需求、改进提出,可以减少BugBash时的需求类bug的数量,及早让团队因应。
How 怎样开展?
前期准备:邮件内容覆盖(时间、地点、准备工作、规则、统计BUG工具、权限是否开通等)
说明测试内容:产品未实现功能告知,避免无用功。
安排答疑、环境解决人员。
报Bug的格式、标题内容需要说明。
组织者实时播报Bug战况,营造竞争氛围,提升参与者的士气。
Bug结束时,组织参与者进行Bug triage,评估Bug是否修复、何时修复。
组织者负责整理本次Bug bash活动的胜利成果(Bug数、Bug类型、找Bug获胜者),邮件通知参与者。
为发现Bug数量最多的人颁发小礼品。
统计工作:Bug Bash结束后,QA/产品主持人要统计全部issue数、有效bug数、需求数(案例见下图)。并检查是否有重复提交的问题,若有重复可以按照提交时间的先后顺序,决定这题算是谁的,或是各得一半的分数。然后再把bug跟需求区分开来。另外有些团队也可以根据提bug的价值与重要程度,给予不同奖励。当然BugBash如果经费允许,可根据不同表现,给予对应同学一些奖励,促进大家积极参与。
网易云免费体验馆,0成本体验20+款云产品!
更多网易技术、产品、运营经验分享请点击。
相关文章:
【推荐】 NOS跨分区灾备设计与实现
【推荐】 消息推送平台高可用实践(下)
【推荐】 分布式存储系统可靠性系列五:副本放置算法&CopySetReplication
所有评论(0)