缺陷大扫除(Bug Bash)是一项短期的全员测试活动。在微软,许多开发团队会在里程碑(milestone)的末期执行缺陷大扫除。程序员、测试员、程序经理、内部用户、市场人员在1~3天的时间窗口中,运用各自的技能和职业背景,集中精力来搜寻软件的缺陷。通常,每位参与者会获得一个小礼品,发现缺陷数目最多的冠军会获得一份大奖。
一般认为,缺陷大扫除的优势在于引入了“更多的眼睛”。程序员更了解程序逻辑和实现细节,有可能发现隐蔽的缺陷;测试员更擅长缺陷猜测和持续攻击,有可能发现其他测试员遗漏的缺陷;程序经理能够从业务角度考察软件,有可能发现业务流程、整体设计上的缺陷;内部用户是软件的使用者,有可能发现易用性、可达性上的缺陷。总之,参与者在技能和角色上的差异性有助于发现不同类型、不同层次的缺陷。
如果只有测试人员参与,缺陷大扫除还有意义吗?以我的观察,测试团队定期组织所有成员执行缺陷大扫除,是一项非常好的实践,有助于团队建设(team building)和个人成长。
在我的部门,测试团队有近20名测试员工。每个员工会负责一个子系统或独立模块的测试,这些子系统和模块会组成整个业务系统。我们大约2~3个月做一次发布(release),每次发布之前都会执行缺陷大扫除。其大致流程和要点如下:
缺陷大扫除持续一个完整的下午(大约3~4个小时)。这是一个天然的时间窗口,让测试员可以集中精力工作。超过这个窗口,测试员很有可能分心去做其他工作。
所有的测试员带着自己的笔记本电脑,在一个大会议室围桌而坐,一起测试。团队建设的一个手段就是团队成员协作去完成一个有挑战性的任务。缺陷大扫除就是测试团队一起工作去搜索整个业务系统的缺陷。
测试员测试一个陌生的子系统时,他可能不了解该系统的业务目标和使用方式。这时,他可以询问负责该系统测试的同事。由于所有人都坐在一个会议室,绝大部分业务问题都可以得到立即解答。这使得测试可以顺畅地推进,也强化了相互协作的团队精神。
测试主管(test lead)参与缺陷大扫除,他也在会议室执行测试。领导重视是团队建设的必要基础,它体现为领导亲自做那些他宣称是非常重要的事情。
测试主管会不定期通报测试进度:已经发现了多少缺陷、目前的冠军发现了多少缺陷等。这是对测试团队士气的鼓舞,也推动了测试员之间的良性竞争。
在“缺陷大扫除”会议结束之后,每个子系统的开发团队立即举行“缺陷分拣(triage)”会议。程序员、测试员、程序经理一起检查缺陷列表,决定哪些缺陷需要立即修复、哪些缺陷可以延迟修复、哪些缺陷不必修复。
在一周内,测试团队举行“缺陷检讨”会议,对有教益的缺陷进行深入分析。团队识别出有代表性的缺陷,分析根本原因,枚举错误症状,总结适用的测试方法,并提出避免再犯的建议。这个会议是缺陷大扫除最重要的一环,它使得测试技巧、开发知识、有效实践可以在团队中分享并沉淀,是团队学习、个人成长的有力工具。
对缺陷大扫除的冠亚季军给予适当奖励,奖品可以是运动装备、购物劵、书劵等小礼品。这是为了提高整个活动的趣味性,因此奖品不宜过于贵重。在我的团队,冠军奖品大约为150元,亚军奖品为100元,季军奖品为50元。
缺陷大扫除是常规测试的有效补充。测试团队将各个子系统连成业务系统,执行端到端(end-to-end)的系统测试,能够发现个人在子系统测试中难以发现的缺陷。此外,测试员在测试不熟悉的子系统时,没有任何先入为主的“偏见”,往往能立即发现那些被”熟视无睹“的缺陷。而资深测试员还可能发现一些初学者难以察觉的隐蔽问题。
不过,相比找到的缺陷,我认为缺陷大扫除在以下两个方面更有价值。
团队建设。在日常工作中,测试员更多的时间在独立地工作,彼此之间的联系并不紧密。在缺陷大扫除中,测试员进行渗透式交流,互通情报,一起嘲笑那些拙劣的设计、滑稽的缺陷,甚至说一些无关的笑话以相互逗乐。全部这些“小事”都在潜移默化中逐步构建一个团队。
团队学习。团队举行“缺陷检讨”会议,总结缺陷模式(bug pattern),完善测试策略,补充测试检查列表(check list)。这是一种积极的集体学习行为。在此过程中,测试员可以积累经验、分享技能,测试团队可以沉淀知识、凝聚士气。