缺陷大扫除(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)。这是一种积极的集体学习行为。在此过程中，测试员可以积累经验、分享技能，测试团队可以沉淀知识、凝聚士气。