Alina Avadani于2008年加入了一家专注医疗保健信息领域（移动保健，远程保健，电子保健）的软件开发公司，自此她的QA职业生涯开始了。重点是用瀑布模式手工测试桌面及web应用程序。2012年，她加入了XING（社交网络平台）公司执行手工测试和自动化，并在敏捷环境中提升了她的专业知识和实践工作。她足智多谋，有创意且擅长解决问题，经常能想出新的和创新的方法去解决分配给她的项目。她热衷技术，喜欢与别人合作创造惊奇的事物。认真享受软件测试的乐趣时，她一心专注于质量和按时交付。她曾参与组织Iasi（http:// tabaradetestare.ro / ）上的第一期“测试训练营”，她还是NRG测试比赛“佳整体软件测试，功能与性能“奖队的一员 。
	Katharina Gillmann自2012年一直在XING股份公司担任QA经理。在此之前，Katharina 学习重点是机器人的计算机科学。她那段时间对机器人杯特别感兴趣。她努力了5年，与B-Human队3次夺得世界机器人杯。卡塔琳娜在加入XING公司前对软件测试过程产生了浓厚兴趣。出于这个原因，她在MeVis医疗解决公司（一家开发用于检测乳腺癌的软件的医疗公司）当了五年软件测试人员。Katharina 目前专注于敏捷环境内Web应用程序的软件测试。

　　许多组织机构在软件开发过程中重点（或一心只）关注测试的功能方面。大多数情况下，可用性测试排得很靠后，且只在发布前不久甚至发布后才进行。为了尽早地提高对产品可用性的反馈，我们将常见的测试方法运用到我们公司组织的一次测试比赛里了。

　　实用性意味着什么？
　　“很大程度上，使某物可用是使用它毫无障碍”。这是可用性测试手册中对可用性的定义，接着里面还写到“用户可以用他或她希望能够做的方式去做他或她想要做的事，没有一丝阻碍，犹豫或疑问“[1]。因此，我们想出了一个基于此定义的内部测试比赛的主意。

　　组织一次内部测试比赛的动机
　　可用性通常是通过A / B测试，内部UX测试阶段，或beta测试检查的。但这些概念耗时且相对很昂贵。此外，在beta测试阶段分析产品可用性时，我们遇到了一些限制，如不能实际观察用户，不能减少探索范围。
　　至少有两种主要途径执行可用性测试：crowd测试及开发团队内的测试。一个公司自己的开发团队的可用性测试可以处理早期反馈，但仍带有局限性，比如该团队测试一个它已开发的产品有着高于平均水平的风险，且可能并不客观。这意味着，问题将与终端用户所评的不一致。
　　另一方面，Crowd测试为真实用户提供了反馈，因为外部测试人员的参与。但是，这也需要大量的培训和介绍，反之导致复杂的协调和准备。此外，它不容易跟进观察，因为不同的测试人员负责不同的crowd测试环节。为了解决crowd测试的挑战，且仍可以得到一个产品的可用性的早期反馈（发行前），XING开展了内部测试比赛。

　　概念
　　XING内部测试比赛结合了crowd测试，基于会话的测试，探索性测试。比赛的概念描述如下：

图1.几种测试方法结合构建内部测试比赛的概念

　　为了深入理解一个产品的可用性，有必要让一组有代表性的用户参与其中。这是为什么crowd测试方法适合，因为很多不同背景的人可以被要求来对软件进行测试并给出他们的反馈。我们的内部测试比赛涉及来自不同部门的人，例如产品经理，项目经理，行政总裁，用户关心员工，人力资源团队和开发人员。一个公司自己员工的参与使其能够解决crowd测试的一些难题。该事件的筹备和组织比较容易，因为员工已经对产品很熟悉了。非公开协议也可以跳过，很容易跟进随后的测试迭代中的发现。用测试比赛概念调整基于会话的测试方法的思路以实际使用可以很容易地定义一个明确的测试范围。这使得我们可以着眼于某一特征而不是整个产品。此外，会话可以被限制到一个特定的时间间隔。James Bach把探索性测试定义为“同步学习，测试设计和测试执行”。为了得到一个clean的用户见解，我们要鼓励测试人员在没有非常详细的产品介绍下自由探索。由于我们的员工来自不同的部门，他们对产品的认识也不同。测试环节之前为他们简短介绍一下会导致一个探索性测试环境。对于内部测试比赛，附加组是由不同部门的人构成的，使他们可能在测试时带上了对产品的不同看法。为了让员工在测试产品有积极性，使用了测试比赛的一般概念（灵感来自NRG全球测试比赛）。通过有奖竞赛，鼓励人们找到尽可能多的bugs及重要的/难以找到的bugs。一个比赛的概念也有助于鼓励人们参加进一步的版本。这消除了通常由crowd测试方法提出的限制。

　　XING内部测试比赛安排
　　在过去六个月XING已经举行了两次内部测试比赛，都侧重于Web应用程序，而第三次（也侧重移动应用程序）目前在酝酿中。期间要收集即将被发布的新特征，如覆盖用户配置文件的组合功能。该活动由XING的QA部门组织，每次总计两个小时。两小时包含范围的介绍和说明（30分钟），以及测试本身。平均而言，每次20人参加，他们分成来自不同部门（如开发人员，用户关怀，销售和人力资源团队，以及为行政总裁及副总裁）的两人或三人混搭组。参与者分别由在场的三个QA经理指导该如何进行测试并写出一个正确的bug和一份测试报告。让不同部门的员工参与，有可能测试各种计算机设置，如不同的操作系统（ MacOS， Windows）和不同的浏览器（Mozilla Firefox， Internet Explorer， Google Chrome， Opera）。每次比赛都有大约100个关于可用性和功能的bugs被发现，同时也产生了一些功能要求。比赛后这些bugs被QA部门评估，然后直接排序并分配给相应的生产队。对其中一个（测试比赛中发现其有测试发布前未被修复的可用性问题的）产品做了一次实验。超过80 ％的随后被用户报道的可用性问题事实上是在测试比赛中发现的，这正好证明这个概念的好处。