《测试之美》连载：创建开源的QA社区

创建开源的 QA 社区

作者：Martin Schr ö der  &   Clint Talbert

 

 

 

一个开源项目的存亡取决于它的志愿者队伍。 越轻量级的项目，越是如此。随着我们开始使用越来越多的在线社交网络，我们有机会去把每一个项目，甚至是那些传统意义上的闭源项目，变成一个大众参与的项目。我们曾参与 Mozilla 日历项目，也就是一个 Mozilla 平台上的日历程序。我们开发两个产品：一个独立运行的日历程序—— Sunbird 和流行电子邮件客户端 Thunderbird 的一个插件 Lightning 。

在该项目的初期，有 4 个志愿开发人员，还雇用了两名专职的项目人员。唯一的质量保证（ quality assurance ， QA ）就是有 1 个人交替测试新的功能并根据紧迫性和严重性为新出现的缺陷设定优先级。随着代码库逐渐成熟，这条聊胜于无的 QA 之路很明显已经走到头了。我们决定为日历项目创建一个 QA 团队。大概花了近 6 个月，我们才让一个负责日常 QA 的团队运转起来。

这一过程很美，无论是在最困难时期还是在最成功时期都是如此。

 

交流

项目中的交流是至关重要的。我们使用互联网中继聊天（ Internet relay chat ， IRC ）作为主要交流手段。在 IRC ，你登录到一个论坛，在那里所有登录的用户都可以看到彼此间实时的交谈。有一个机制让社区与你互动是很重要的，社区中成员的相互交流同样如此。如果人们觉得自己是“大项目”中的一员，他们会从此与大家站在一条战线上，成为竭力奉献的志愿者。

至于其他交流手段，因为我们做的是质量保证的工作，缺陷追踪系统几乎充当了一个社交网络站点。我们使用 Bugzilla ，在每个缺陷的评论部分往往总会有对好多缺陷的讨论。

一般来说，在互联网上的交流，特别是 IRC ，总有某些方面的限制需要解决。在任何电子媒介中，人的情绪都是难以衡量的，分歧很容易引起争执。请注意，除非问过，否则你永远不会知道志愿者的母语是什么，因此放手让他们怀疑并努力消除各种误解。很早以前我们就发现俚语不好翻译，所以你得谨慎使用和解释其含义。

如果你有机会与志愿者见面，或组织一个志愿者会议，你应该排除万难去参加。我们的所有技术都还不能替代面对面的交流，所以如果你能让社区的人聚一聚，这将大大激励他们为项目发热发光。

 

志愿者

在 Mozilla 日历项目开始时，我们这一小伙志愿者，要么是计算机科学家，要么是经验丰富的软件开发老兵，大家都了解彼此间的行话。我们没想到用户和志愿者可能与我们大相径庭。第一次面临“什么是 QA ？”的问题时，我们意识到我们对典型志愿者的想法错得离谱。看到神秘的行话并不令人欢欣鼓舞。我们中有些志愿者日常工作就是做

QA ，但他们想要的并不是“ QA ”。把“ QA ”换成“测试”也不对。当我们问频道中的志愿者，是什么让他们来到这个项目，他们想要从中收获什么？两个主要原因是“回馈开源”和“成为项目的一份子”。我们努力创造和维护一个开放的、好客的群体，这最终融入了日历项目的 DNA 。

“志愿服务”（来自拉丁文 voluntarius ，“一个人的自由意志”）这个概念，是指没有经济或物质利益奖励的工作。从这个定义出发，有这样一些问题：为什么人们会感兴趣，他们对什么感兴趣，什么是可以实现的？社区包含一大群拥有不同测试软件和质量保证知识的个人，从只有最基础知识的初级用户，到每天都使用这一软件产品的用户，再到具有专业知识技能的程序员。

我们可能要面临和解决的任务同样形形色色。在日历项目中，我们先创建测试用例，然后创建测试会话。每个人的先验知识决定了哪些活动在这新兴的 QA 社区中是可行的。

虽然大多数用户很容易忘记软件质量保证的概念，我们发现普通用户成长为 QA 志愿者的学习曲线，并没有我们想象的那么夸张。典型的用户，在一些指导下，经过约三四个星期的持续兼职参与，就可以成为一个不错的测试人员。

促使志愿者参与项目的动机是多种多样的。有的是学生，花费闲暇时间作测试以便获得开源软件开发的技能；其他一般的用户推动项目前进，因为他们希望看到它的改善或希望为自己喜欢的免费产品做一些“回馈”；许多志愿者是新用户，这对我们格外有好处，因为他们让我们定期通过全新的眼光来看产品。找到志愿者参与其中有什么期望是很重要的。了解了这些期望，才能理解社区，才能设法让他们进一步参与该项目。

志愿者社区是一个动态的团队，你不能指望每个人都对项目投入同等的时间和精力。确定一个志愿者有多少时间投身于项目是很重要的，这样你才能安排出他们时间允许的最佳任务。我们看到很多次“消失和重现的成员”。日常贡献者突然消失，数月后返回，并一如既往地贡献力量的情形并不罕见。遇到这些情况，我们总是欢迎他们回来，并表示我们很高兴再次相逢。

你可以把志愿者的流程看作是一系列步骤，我们自身就这么经历过。大多数感兴趣的人一开始在交流频道里潜水倾听，开始学习交流的风格。在变得熟悉和自信之后，他们就开始与其他志愿者互动。经过一段时期参与定期测试活动，他们有时要求，甚至自己找出一些他们想要承担责任的项目。但是，不要等他们开口要求。正如我们马上要讨论的，尽快给他们小的任务是很重要的。日益增加的责任能深化他们对项目的认同，并有助于鼓励志愿者成为社区永久性的成员。

协调

首先，团队成功地建立起来了，我们把我们之前所做的工作称为“领导”。虽然表面上如此，但似乎这个词并不能反映我们平时做的事情。后来，我们开始改口为“协调”，而后沿用至今。日历 QA 团队是自我选择的一群人，他们从来不需要一个传统意义上的领导者。他们自己决定来到这个项目，决定参与其中，效忠于项目，而不是效忠于通过言辞或行动自立的领导者。因此，一旦我们把自己定位为协调员，整个项目开始更为顺利地运行。拥有一支志愿者队伍，就像管理一条河流，你不能要求它往某一方向流动，但如果为它挖一条运河，那么就可以引导它随你左右。

协调这样一个项目，要记住一些原则：

• 不搞特殊。
• 总是招人。
• 总是鼓励参与。

不搞特殊

通常，成为一个领导者，总是有些诱人的。就像我们又变成操场上玩耍的孩子，领导者可以指挥其他所有孩子。在线社区里不能搞这个，你必须高举平等的大旗。团队里的每个人都将你视为团队的一分子，而不是从中分裂开去，否则，他们不会愿意呆在你的团队里。说白了，就是没人会喜欢声称“更了解”却言行不一的人跳出来对其他人指手画脚。

你得亲身去做你要求志愿者做的事情，你不能说忙得没空去做他们做的工作。也许你会因为带一个新人而做得少一点，但你也必须去做一些。通常当一个项目成功后，领导者往往把关注点切换到新的任务，脱离其他志愿者在做的核心工作。这总是导致项目参与度下降，因为志愿者认为领导者的新关注点是一个“更为重要的”领域，因此，很自然他们手头在做的就“不太重要”了。作为社区组织者，你探索新领域、增加测试深度是一件好事，但是当你这么做时，也应该积极鼓励你的志愿者跨入这个新领域。通过将他们带入新的领域，他们就会与你一同探索。

我们在写手工测试用例的时候犯过这个错误。我们有些很棒的志愿者能创建出很多测试用例。最后，我们自己不写测试用例了，认为即使没有我们的帮助，志愿者也将做好这件事，然后我们将时间和精力用于测试日活动。短期内，这个策略还是奏效的。如果我们又再回来重新编写测试用例，情况还能有所好转。但是，我们在杂七杂八的测试和测试日的准备上花的时间和精力更多了。最后，我们失去了测试用例编写者，才明白事情的严重性。他们罢工只是觉得，既然我们不再关注于编写测试用例，说明它已经不再重要了。

要避免首先探索某一领域，然后向大家汇报。这也在“知情的”你和“不知情的”其他人中间划了一道错误的三八线。最好是早期就带人一起进入新的领域，让他们看到你也会犯错。你不必做一个完人，事实上，你不是完人更好。让人看到你和他们一起学习新的领域。这样做是需要勇气的，因为没有人喜欢被别人看到不足。但是，在志愿者的眼中，这表明你与大家是平等的，你是在为这个项目竭尽全力，这将有助于他们进一步融入项目做好工作。

同样地，好的想法不是你一个人才有。你可能会带头做某些努力，但并不意味着你的话就是金科玉律。要允许社区的其他人主导事情，要让他们辩论和改变你做事的方式。如果改动行不通，把他们带回行得通的方式，但不要害怕改变，不要害怕失败，失败乃成功之母。在日历项目中，我们有一套人人可以运行的手工测试用例。我们担心人们会对运行手工测试用例感到厌倦，因此鼓励他们做一些随机测试。然而，没有经过强化培训和如何制作出软件的知识，很难做出相关的随机测试。每次这种尝试失败了，这不是社区的过错，而是因为我们根本无法提供深入的学习让他们成功。我们最终放弃了社区主导的随机测试，而是更侧重于努力写出更好的手工测试用例。

欢迎新人

这是非常不言自明的。不管你为项目所了些什么，有一个目标必须是建立你的志愿者队伍。这不仅是指你得在公共场所欢迎他们，还包括你要亲自结识他们。这意味着要不断寻求降低进入项目门槛的方法。因此，在我们组织的每个活动中，我们始终保证给人们一个简单而易于理解的方法来作出贡献，我们始终给予他们大量详细的指示，我们始终研究如何让事情变得更容易。我们的 IRC 主频道更像是一群人围坐在客厅的炉火边，而不是一个工作场所。虽然我们的确为了工作团聚在此，但让人们彼此交流是很重要的，而聊天正给了我们这样一个机会与他们互通有无。这些随机的非技术性的讨论，让只是潜水的人有信心开口发言。为了实现项目目标，你得在互通有无和实际工作中做好权衡，但总要努力设法吸引人们进来参与。你永远不知道是什么让人们钻出套子参与进来，总之不管做什么，都尽可能地欢迎他们。

 

鼓励参与

开源项目里有一种精英制度。你做得越多，你就有更多的权限，你能做的就越多。对参与予以奖励是完全正确的。但是，让人们早点参与也很重要。这不像学习武术，头三个月新人要跪大米。曾经有个人在频道中要求获得编写手工测试用例的权限，我们比较犹豫，因为我们的测试用例管理系统中有一个缺陷：能写测试用例的人就可以管理整个系统（包括删除它）。他在我们的某次活动中再次要求访问权限，我们仍旧没有同意，但他一再坚持，我们也就给了他那把王国的钥匙，并告诫了他前述问题。后来他写了很多目前仍存在于日历项目中的测试用例。

做事要谨慎，但不能谨慎过头，以致不让志愿者参与项目。你得找到简单的方法，早点赋予他们权力，让他们觉得自己贡献了力量，发挥了作用。通常，仅仅是公开指出一件做得好的事情就足够鼓励人们更多地参与。我们每周举行一次测试日，将活动和成果写在博客上，并点名感谢每个参与者。当不再将测试日的成果写在博客时，我们失去了很多多次参与的志愿者。我们没能鼓励人们参与其中。他们可能感觉（也确实是）我们将他们的贡献视为理所当然。你得一直设法让志愿者参与到项目中。

有一种简单的机制，可以让志愿者参与项目：动力、合作、及时回应和成功。让有兴趣的志愿者参与的最好结果就是得到他系统的支持。要达到这个状态，志愿者必须始终保持动力，因此要明白它如何受其他因素影响是很重要的。请记住，单个志愿者，绝对不如一个团队行之有效，你应该尽力促进 QA 社区的所有成员精诚合作。友好竞争是可以的，但如果人们不互帮互助，产品就惨了。资深志愿者和协调员应该尽可能快地回应其他志愿者的问题和要求。每当一个志愿者停滞在一个死胡同手足无措时，需要有人作出回应并提供帮助。否则，她可能会开始离开项目。此外，不要低估成功给志愿者带来的能量。告诉志愿者他们的行动为项目贡献了多大力量非常重要。这就又产生了动力，创建了一个良性循环。

 

活动

与志愿者开展的活动是协调的基石。组织一些协调 QA 的活动是吸引志愿者和让他们融入这个项目的最好方式。组织在线的活动和“现实生活”中的活动有许多相似之处。但组织好公开的网络活动也有一些独特的挑战。跟一般的活动一样，你要选择一个位置和时间。位置通常很简单，只要使用你平时用来与志愿者交流的渠道就行了。就我们而言， IRC 则是一个很自然的选择。我们清清楚楚说明，人们无须加入 IRC 就能参与活动，但我们也集中资源，并不希望在活动当日管理多个不同交流渠道。这有助于增加在 IRC 频道上的活动、反应能力和关注度，促成参与更多、兴奋更多的活动。

虽然选择位置很简单，但时间却不简单。我们的志愿者遍布全球，主要集中在北美、欧洲、亚洲和澳大利亚。没有任何一段时间对大家的地理位置都合适，但随着志愿者团队的发展，有很多种方式来应对这一挑战。如果在每个地理位置上都有资深志愿者，你可以让他们负责活动的“一个轮班”，并给予他们自由去领导“一个轮班”，与该时区的新志愿者一起工作。这是解决这个问题的最好方式，当然这是建立在你有一个志愿者队伍的基础上的。

一开始，我们举行了 12 小时长的活动，时间主要照顾那些贡献者最多的地区，也就是从 UTC 时间的中午至午夜。作为另一种选择，我们尝试了多天的活动，但却失败了。看起来，比起天的偏差，人们更容易理解小时的偏差，多天活动的整个概念似乎太不明确。

另一个解决办法可能是结合两种想法，在相邻的两天指出明确的小时，但我们没这么试过。对于规划时间，我能给出的最好建议，就是从小规模开始做起，当你的志愿者队伍壮大后延长活动时间，增加轮班。

 

宣传

宣传活动是接下来要关心的步骤。你可以把你的潜在志愿者队伍想象成体育馆中的球迷。有的人已经在球场上比赛，有的人坐在替补席，还有些人坐在前排，更多的人坐在离你极远的高高席位上。理想情况下，你的宣传要触及所有人，并吸引他们下到赛场来。实际上，你只能打动那些坐在体育馆最前排的观众，但一旦这些人参与进来，由此产生的活动将带来更多好奇的人接近赛场，你的下一个活动就能影响到他们了。

在日历项目中，我们在更大的 Mozilla 社区论坛给更大范围的观众宣布了我们的活动。我们通过博客定期发布公告， Planet Mozilla 上也会同步发布。我们发布到邮件列表、 Mozilla 项目新闻组和 Mozilla 论坛中。为了项目，你必须回答这个问题：“用户在看什么？”那里就是你想要去宣传的地方。例如，如果你的用户在用 Facebook ，那就在上面创建和使用一个群。我们试过这一招了，但我们在 Facebook 上没有结识到足够多的日历用户，所以那个群不是很成功。

另一个想法是把你的一些活动写成标准新闻稿提交给新闻媒体。传统的技术新闻媒体很少会报道一个小的 QA 活动，除非你真有什么独特之处。不过，如果你走运能够把活动塞进传统新闻报道，那么将触及大量从没听说过该项目的受众。所以，时不时花些时间和精力给传统媒体供稿还是值得的。我们有一次走大运，传统新闻媒体报道了我们早期的一个活动，我们发现这一报道比任何其他努力都能激励和吸引日历 QA 团队人员的眼球。当天我们有超过 50 名志愿者参与活动，其中约有 15 个在一段时间后仍参与项目，有些人甚至一直参与到今天。

 

我们实际上做了什么

我们举行了几种类型的 QA 活动，每个活动的 QA 主题有所不同。我们希望通过不同的活动来吸引不同技能和兴趣的志愿者。第一个也是最成功的活动，是测试日。恰如其名，专门抽出一块时间邀请你的志愿者来测试应用程序的功能。事情最具体的测试日是最好的测试日，一套完整的测试用例，配以完整的文档以及如何运行这些测试的指示，人们比我们让他们做随机测试时有着更多的参与热情。在测试日，我们鼓励资深志愿者运行较难的测试用例，如对时区的支持，让新志愿者去运行文档写得较好的手工测试用例。在这两种情况下，鼓励用户参与测试日直接影响了该项目的质量，因为应用程序得以在多种不同的运行环境、操作系统和硬件配置运行。

测试日变得对项目如此重要，我们创建了模板和辅助文件，这样即使志愿者都能让测试日活动运转起来。一旦我们开始做不同时区的测试日“轮班”，这就更显得尤为重要。但是，你要注意不要把帮助和交流文档写得好像味同嚼蜡。我们最近就遇到这样的问题，日历项目因此而失去了不少志愿者。即使你已经写了一万份这样的文档了，你还得让这些文档看上去保持新鲜而令人兴奋。

缺陷日活动致力于评估缺陷。在 Mozilla 缺陷系统，我们每天都会有一些新的缺陷，还会有些老的缺陷好长时间没人管了。在缺陷日上，我们努力带领人们来走评估缺陷的流程，看老缺陷是否仍然成立，并尝试重现和清理新缺陷，让开发人员能有所行动。在这样的一个大项目中设置明确的目标很重要，这样才不会让志愿者感觉到不堪重负。例如，单是在日历项目中，我们一开始就有数千个或新或老的缺陷需要评估，这就应该让志愿者只关注其中的一个子集。

你还需要从外部用户的角度来评估缺陷系统的不足之处。有一件很关键的事是，我们希望得到志愿者帮助，那就是标记缺陷为“已核实”，这表明 QA 评审了开发人员的改变，发现该缺陷的确被修复了。然而，在 Mozilla 的 Bugzilla 安装中，你需要特权才能设置“已核实”的标记。我们尽可能把这个权限给予用户，还发明了一种替代方案，以便权限有限的用户仍然可以作出贡献。但是，这始终是我们缺陷日的一个遗憾，我们总是没有获得足够的帮助来核实缺陷。

我们最少举行的活动是测试用例编写日。在第一次做这个不寻常活动的时候，如前所述，我们意外得到了新闻媒体的报道。活动当天，我们邀请社区同胞为我们编写手工和自动化测试用例。像这样一个活动的成败，与你提供的编写测试用例的模板有直接的关系。我们发现，许多人被关于编写这些用例的虚假想象所吓倒，但当我们解释说“把某人做了什么动作写下来，再写出应用程序为此应该如何响应”，大家立即理解了。我们并未经常举行这个活动，原因很简单，要办得成功还是很困难的。

 

目标设置和奖励

对于你所有的活动，你心中应该一直有个明确的目标：运行的测试用例数目、评估的缺陷数目、编写的测试用例数目。我们曾尝试为在活动中突出表现者颁发认证奖品，还是比较成功的。作为一个小的志愿者项目，很难提供任何真正的奖励，人们来只是因为想帮忙，而不是因为他们期待获得物质奖励。所以，尽管奖励在活动中是一个刺激团队之间竞争的有趣方式，它并未如我们预期的那样多地激励人们。然而，我们发现在活动中获得公开认可是一个巨大的激励方式。

在每个测试日之后，我们都会写博客描述活动，列出所有参与者，并感谢他们。我们还列出发现缺陷的人以及缺陷的名称。这种简单的博客文章带旺了社区，我们停止列举“成果”的博客文章之日，就是我们的持续志愿者减少之时。归结起来，这就是认可每个志愿者闲暇时候的时间和精力。写这样的“成果”博客文章，显示的是我们的感谢，当我们不这么做了，他们也就销声匿迹了。

 

结论

创建一个 QA 项目的社区是你能为产品所做的最好的事情。它在流程早期就把产品摆在感兴趣的用户面前，并让他们能使用和试验正在开发的功能。它还可以把你的测试扩展到各种不同的最终用户配置、硬件和操作系统上。但是，说为 QA 项目创建一个社区是“美丽的”称号的原因，是因为它汇集了一群感兴趣有活力的人和积极的志愿者，还创造了一个支持你产品的亲友团。该部落的推广传道和口口相传能让任何泛着光泽的广告相形见绌。把五湖四海来自各行各业的人，为了一个共同的目标凝聚在一起，是一项绝对美丽的有益活动。