我一直在考虑将手动测试工作进行弥补，一些带有徽章和奖励的“竞赛”，以下是一些想法：
一次测试马拉松的错误数量-在有限的时间内竞争许多已发现的错误时间量（例如，每个测试冲刺迭代）。错误可能具有严重性系数，以使每个错误的加权分数
与每个版本中最有趣/最怪异的错误竞争，并具有维持的“成名堂”
，从而在以下情况下建立“人为错误”场景：测试人员会遇到某种类型的现有问题（例如，由于未正确验证输入而导致的SQL注入漏洞），但没有给出重现位置和步骤的方法
您还想着其他什么主意？
请让我知道这听起来像是愚蠢的，适得其反并且永远不会起作用:)
#1 楼
我支持这个主意。这可以作为常规测试的一部分。但是，这是否会对生产力产生积极影响；在很大程度上取决于您实现此想法的方式。当然，您在上面已经谈到过游戏化的积极方面。
我只想着重于实现的一部分。因为我们也必须照顾它的不利方面。：
竞争可能导致个人之间的自我冲突，这对团队不利。
为了获得认可，一些团队成员可能会参加这种甚至在有时甚至报告废话的bug竞赛。
人们可能会提出重复的bug，然后再次争论谁的bug将被标记为重复并关闭。
团队成员，即使在过去的一两次冲刺中也没有被识别过，可能会士气低落。因此，我们也必须注意这一点。
但话虽如此，我并不只是反对。因此，我想在您的列表中添加一些要点：
我认为，这样做的目的是尽可能地认识更多的人，因为这会激发所有人的积极性。
对于报告了前5个错误（最重要）的团队成员的认可。
我建议授予该奖项，因为根据我的经验，我曾与不太快的人一起工作。他们花费自己的时间来测试功能，但是非常彻底。因此，他们记录的错误对项目非常重要。因此，该奖项将覆盖此类人员。
缺陷泄漏：报告了对测试特定功能且没有缺陷（或1个或2个低优先级缺陷）的个人或团队的另一个奖项。 UAT中的功能。
评审效果奖：这将确保更好的评审。您可以为此设置目标。我的意思是，例如，如果审阅效率大于30％，则该审阅者将获得认可（如果在审阅过程中捕获到功能中引发的总错误中的30％以上）。
没有无效的缺陷：这将提高所报告错误的质量。渐渐地，如果所有团队成员最终都得到了这个，并且没有报告任何无效的东西，那么我很乐意将此信息提供给所有人。
除此之外，还可以有团队事件也是如此。您也可以在团队级别设置一些度量。例如，如果团队发布了符合某些质量参数的版本，那么整个团队就会受到某种对待/淘汰（某些情况下，我们会有质量矩阵的目标，例如缺陷去除效率，缺陷泄漏和评审有效性）。这对于保持团队合作精神至关重要。否则，我个人认为太多的个人奖项/认可会对团队精神产生不利影响。因此，我们应该在两者之间保持平衡。
评论
非常全面；我的一种猜测；在避免自我冲突和士气低落方面，我们如何私下奖励人们？但这可能剥夺了公众认可的好处。
–张瑜
17年7月11日在7:43
好。是的，我同意你们的看法，人们喜欢在公开场合谈论自己的优点和任何缺点；私下。因此，人们喜欢被公众认可。假设您团队中有些人的表现“非常好”并为团队增添了价值，但他们却不是“杰出的”表现者。因此，如果未因一两次冲刺/发布而获得奖励，则可以添加诸如“沉默杀手”或“表演稳定者”或“隐藏宝藏”之类的奖励。
–阿拉克
17年7月11日在8:35
但是，自我问题；很难处理。在这种情况下，对于每个识别，您都可以添加一个强制性标准，即“软技能”。您可以设置一些标准，例如，如果某人卷入了冲突，那么将从软技能评分中扣除1或2分，而任何软技能得分低于“ X”的人将不符合资格。我的意思是，这可以进一步处理。因此，人们将尽量不要参加任何可能影响软技能的对话。只是一个想法...
–阿拉克
17年7月11日在8:38
@YuZhang私下奖励别人没有帮助。您仍然知道您没有获得该奖项。并且您是否建议团队成员将自己的成就与团队中的其他人隐藏起来？这听起来像是在团队中工作的一种非常糟糕的方式:)
–罗安
17年7月11日在9:39
有些人喜欢将自己的成就公之于众，但有些人则讨厌。一种可能的选择是只列出前五个错误，而不用说出是谁发现的。希望将其公开的人会吹牛。那些没有的人可以对自己微笑，保持沉默。
–凯特
17年7月11日在20:17
#2 楼
正如他们所说的要小心，要测量的东西-您会成功的。工作场所论坛中有很多关于度量标准和激励提议的问题，这些问题都在讨论着如何滥用和使用不同的度量标准。 />
使用“游戏化”可以使任务更加有趣。 “游戏”也以相反的含义使用：针对原始意图使用指标。
可悲的是，在SE上按标签搜索有时会中断，但是请尝试搜索“指标”和“生产力” 。我知道有很多相关的问题，很难通过残破的搜索找到它们。
此外，墨菲定律也适用：如果出现任何问题，都会发生。
关于游戏（任何）度量标准的Workplace Exchange上很少有线程：
https://workplace.stackexchange.com/questions/69894/how-to-handle-a-test-工程师偏向我们团队中的一个成员
https://workplace.stackexchange.com/questions/5940/how-to-measure-the-creative-workers-output-who-are -not-filling-in-the-timesheet
https://workplace.stackexchange.com/questions/87887/how-to-objectively-measure-colleague-cooperation（提及：
http://cuberules.com/2008/02/07/management-by-numbers-be-very-afraid/）
https://workplace.stackexchange.com/questions/22087/measure-competence-of -公司不同技术领域
https://workplace.stackexchange.com/questions/48053/how-productivity-or-working-hours-are-measured-in-software-development-职位
评论
彼得您好，您可能滥用指标是什么意思？我们已经使用矩阵大约四年了。在每次冲刺后准备好矩阵，然后向团队提供演练。每个团队成员都知道如何进行每个计算。准备时，我们的经理会参与其中。为什么他会通过玩弄价值观念或以任何方式滥用它来为自己挖一个坟墓？
–阿拉克
17年7月12日在2:54
@Aalok-您从未见过任何废弃的指标吗？您必须是街区的新手吗？ :-)从OP的评论中查看此Dilbert卡通。顺便说一句，准备指标的经理并不能保证它会正常工作-参见PHB的动画片。我也不确定为什么您使用“度量”和“矩阵”，因为它们是相同的。
–Peter M.-代表莫妮卡（Monica）
17年7月12日在13:49
是的，彼得。你做对了。我是这个街区的新手。但是，与像您这样的有经验的人进行交流不会让我长期处于新状态。干杯!在这之间，我非常佩服你。已经阅读了许多答案。很有说服力..！
–阿拉克
17年7月12日在16:50
#3 楼
我已经看到一个外部beta程序成功完成了该任务，该程序使用了数百名当前产品的热情用户来测试下一版本。每天仅使用该产品n分钟即可获得积分，因为它是第一个报告错误（对于严重性更高的错误，得分更高）。我们还将在未充分测试的功能的用户界面中嵌入“奖词”，并将积分奖励给发现它们的测试人员。
在Beta周期结束时，积分可以兑换为t -衬衫，咖啡杯，免费软件等。具有较高分数的测试人员被邀请再次参加下一个Beta周期。
很久以前，因此它需要大量的beta协调员来回答问题面向Beta测试人员，分类他们的错误报告等。如今，其中很多可以实现自动化。
评论
我同意这可能对外部Beta版计划有益-在这种情况下，您实际上不想为专业的质量检查工作付费。我不会为实际员工做同样的事情。
–乔·斯特拉泽（Joe Strazzere）
17年7月11日在20:23
#4 楼
有很多恐怖故事是为了增加错误报告而做出的，它们仅仅是为了增加错误报告而已。它会在开发人员和质量保证工程师之间造成很大的敌意。对于将其发布到软件中的开发人员，“最怪异的臭名昭著堂”可能是一个耻辱。当我进行手动测试时，我宁愿只听到“谢谢”。我建议对培训工作进行游戏化，并建立一套自动化测试，以使手动质量检查工程师不必重复测试同一组代码。这将使他们能够专注于分析和探索性测试。
#5 楼
我对此会非常谨慎。如果公司的文化是正确的，并且团队开放，透明且非常信任，那么这可能是一项出色而有趣的活动。知道了这一点，添加任何“度量”（无论是针对娱乐还是认真跟踪的目标）都会对团队的心态产生重大影响。我肯定会回避bug的数量，因为这鼓励了人们尽可能多地提出错误，并且通过使用术语“错误”这一事实，您已经暗示了您对团队内部“确定尚未完成的工作”持否定看法。
此外，这个问题引起了关于您的开发方法的一些问题。您提到了sprint，所以我将假设您正在使用Scrum或某些变体，在这种情况下，在sprint中不应出现“错误”，而只是团队尚未完成的任务或工作。无论开发人员还是测试人员都可以识别这些东西，早日识别这些东西是积极的。您的语言似乎在“开发”和“测试”之间拉开了距离，鼓励微型瀑布而不是敏捷实践。您创建的任何“游戏”都应同样适用于测试人员，因为质量保证是敏捷团队的整体团队责任。
我可能对此读得太深了，但是您使用的术语使我认为这种游戏化对团队来说不是积极的举动。
#6 楼
游戏化是将类似游戏的特征应用于非游戏情况以增加“用户”互动的行为。我的游戏（计算机，棋盘或角色扮演）朋友进行的一项非正式调查发现，几乎一致的结论是，他们从游戏测试或Beta测试获得的回报是参与的荣誉，早期参与游戏以及当他们看到产品根据其反馈而改变时的良好感觉的荣誉。值得一提的是，如果他们的名字出现在发行版的游戏中，他们也很感激。寻找挑战很容易，但是很难找到解决方案。很难看清整个测试范围，而从一个部分开始可能会更好。在最近一次针对测试中游戏化的聚会中，我们讨论了选择哪个部分，并同意回归测试可能是开始的有效部分。每个人都有关于如何使其更具动力的想法。在许多情况下，讨论是关于参与者不想以无意义的方式进行回归测试的。该小组确定了可以避免避免毫无意义地完成任务的几件事。我们考虑了如何添加游戏化机制以使其更具激励性。我们的想法是，我们认为可以游戏化的很多事情都与反馈给他人或他人，信息共享以及基本上与改善沟通有关。我对聚会的反思是，可以使用游戏化来与可能对测试有不同想法的人交流测试中的价值。
这是一种经济有效的方法提高产品质量
激励您的团队进行更优质的工作
如果我们一次又一次地重复相同的例程，那么软件开发和测试可能会很无聊。那么，为什么在编码完成后不做一个有趣的游戏呢？为了使测试活动有趣，您需要保持公平。您需要以不同的方式定义不同类型的错误的权重。您需要设置不同级别的排名（例如，神灵，骑士，大人，婴儿），作为参与者的目标。您需要通过每天发布结果来保持所有人的状态更新。在活动结束时，您需要公开奖励表现最好的人并使其狂欢。这可能很有趣，并且可以在公司内部建立士气。
软件测试中的游戏化绝对不能替代所有其他软件测试选项。但是，它可以带来独特的价值，并且可以成为组织中软件测试策略的一部分。手动评估和计算所有计分板结果可能需要大量工作。
#7 楼
我支持和反对！！！我反对将其与以下因素一起使用：
发现的错误数量最多
最高编写的端到端测试数量
本月关闭的错误数量最多
随着时间的推移，我们了解到很容易陷入专注于测量的陷阱，不是结果。这可能会导致诸如提交越来越多与业务成功无关的错误的情况。
当考虑到诸如以下因素时，我会这样做：
给予其他人更多的帮助
间歇性故障的发生率更低
更高的测试覆盖率
#8 楼
尽管在服务台团队中，我过去也尝试过类似的游戏化想法。以下是一些经验：一些团队参加了，有些没有参加-因此对团队不感兴趣的团队成员变得更加孤僻，没有参与不可避免的玩笑发烧友：不利于团队
发烧友创建了更多票证（重复/更改应该是先前票证的扩展）：测试人员可能会记录多个错误版本
发烧友不想与其他团队成员合作/讨论一个问题，以防解决方案被盗。我可以在测试中看到这种情况的发生：测试人员不会一起讨论问题并根据集体智慧得出结论-他们只会记录错误
以前在某些领域具有专长的团队成员将获得票证，但是其他人希望保持他们的得分：问题没有得到有效解决，因此对客户不利。
还有其他一些想法：
使用更复杂的软件的测试人员将获得更多的分数
测试人员将希望与质量较低的开发人员一起使用！
与测试人员一起使用可能会更好，但是团队行为不可避免地会有变化，这不会t始终为正= /
评论
重现并缩小间歇性遗留错误。许多人未能杀死的龙。@dzieciou，很好的主意，但是根据我自己的经验，间歇性遗留错误通常会在一段时间内无法生成后关闭；如果发生这种情况，它们将永远丢失。
相关的迪尔伯特：今天下午我要给我写一辆新的小型货车。
请不要将游戏化作为常规工作的一部分-恕我直言，您会拖累该行业。完成大部分工作后，在发行即将结束时进行游戏之夜-好的。徽章，奖励和积分是常规工作的一部分-很快就会变旧并降低本应有价值的专业工作的成本。
您可能会喜欢阅读Aubrey C. Daniels的“展现最好的人”。这是关于使用正强化来增加您发现所需的行为，而这基本上就是您在说的。如果正确完成，它可能会非常有效，但是可能存在许多陷阱。