测试日变得对项目如此重要，我们创建了模板和辅助文件，这样即使志愿者都能让测试日活动运转起来。一旦我们开始做不同时区的测试日“轮班”，这就更显得尤为重要。但是，你要注意不要把帮助和交流文档写得好像味同嚼蜡。我们最近就遇到这样的问题，日历项目因此而失去了不少志愿者。即使你已经写了一万份这样的文档了，你还得让这些文档看上去保持新鲜而令人兴奋。
缺陷日活动致力于评估缺陷。在Mozilla 缺陷系统，我们每天都会有一些新的缺陷，还会有些老的缺陷好长时间没人管了。在缺陷日上，我们努力带领人们来走评估缺陷的流程，看老缺陷是否仍然成立，并尝试重现和清理新缺陷，让开发人员能有所行动。在这样的一个大项目中设置明确的目标很重要，这样才不会让志愿者感觉到不堪重负。例如，单是在日历项目中，我们一开始就有数千个或新或老的缺陷需要评估，这就应该让志愿者只关注其中的一个子集。
你还需要从外部用户的角度来评估缺陷系统的不足之处。有一件很关键的事是，我们希望得到志愿者帮助，那就是标记缺陷为“已核实”，这表明QA 评审了开发人员的改变，发现该缺陷的确被修复了。然而，在Mozilla 的Bugzilla 安装中，你需要特权才能设置“已核实”的标记。我们尽可能把这个权限给予用户，还发明了一种替代方案，以便权限有限的用户仍然可以作出贡献。但是，这始终是我们缺陷日的一个遗憾，我们总是没有获得足够的帮助来核实缺陷。
我们最少举行的活动是测试用例编写日。在第一次做这个不寻常活动的时候，如前所述，我们意外得到了新闻媒体的报道。活动当天，我们邀请社区同胞为我们编写手工和自动化测试用例。像这样一个活动的成败，与你提供的编写测试用例的模板有直接的关系。我们发现，许多人被关于编写这些用例的虚假想象所吓倒，但当我们解释说“把某人做了什么动作写下来，再写出应用程序为此应该如何响应”，大家立即理解了。我们并未经常举行这个活动，原因很简单，要办得成功还是很困难的。
目标设置和奖励
对于你所有的活动，你心中应该一直有个明确的目标：运行的测试用例数目、评估的缺陷数目、编写的测试用例数目。我们曾尝试为在活动中突出表现者颁发认证奖品，还是比较成功的。作为一个小的志愿者项目，很难提供任何真正的奖励，人们来只是因为想帮忙，而不是因为他们期待获得物质奖励。所以，尽管奖励在活动中是一个刺激团队之间竞争的有趣方式，它并未如我们预期的那样多地激励人们。然而，我们发现在活动中获得公开认可是一个巨大的激励方式。
在每个测试日之后，我们都会写博客描述活动，列出所有参与者，并感谢他们。我们还列出发现缺陷的人以及缺陷的名称。这种简单的博客文章带旺了社区，我们停止列举“成果”的博客文章之日，就是我们的持续志愿者减少之时。归结起来，这就是认可每个志愿者闲暇时候的时间和精力。写这样的“成果”博客文章，显示的是我们的感谢，当我们不这么做了，他们也就销声匿迹了。
结论
创建一个QA 项目的社区是你能为产品所做的最好的事情。它在流程早期就把产品摆在感兴趣的用户面前，并让他们能使用和试验正在开发的功能。它还可以把你的测试扩展到各种不同的最终用户配置、硬件和操作系统上。但是，说为QA 项目创建一个社区是“美丽的”称号的原因，是因为它汇集了一群感兴趣有活力的人和积极的志愿者，还创造了一个支持你产品的亲友团。该部落的推广传道和口口相传能让任何泛着光泽的广告相形见绌。把五湖四海来自各行各业的人，为了一个共同的目标凝聚在一起，是一项绝对美丽的有益活动。
相关链接：
