但是，我注意到来自团队本身。我们有4个Scrum团队，而错误搜寻使每个团队的QA相互冲突。这开始让我自己和其他质量检查领导者感到头痛。尝试使用该系统的测试人员，对其他团队作弊的抱怨，以及对狩猎的不满于办公室闲聊。每个人似乎都非常喜欢狩猎，但是每个人都有一个理由，为什么其他团队发现问题不符合条件，或者他们只是对其他团队的工作普遍抱有偏执。
还有其他人吗必须解决因bug搜寻而引起的冲突，如果是这样，那么您如何解决它们？最初，此过程进行得很顺利，现在，质量检查（QA）花费了尽可能多的时间，甚至更多地花时间争论发现的问题的有效性。有人有替代方法吗？
#1 楼
让上司们很高兴看到结果，获胜的QA成员可以享用午餐。
由于您已经建立了系统，因此有“获胜者”和基于错误计数的“失败者”，测试人员试图找到一种获胜的方式并不奇怪。您专注于错误的目标。您基本上已经告诉他们，目标并不是提高质量-目标是拥有最高的bug数量。相反，请考虑质量是每个人的工作。应该没有赢家，也没有输家。每个人都应该从您的测试中受益。
立即停止宣布获胜者。停止单挑个人或团队。奖励每个人出色的工作和改进的产品-而不是为了获得更高的bug数量。
这可能有助于：
https://strazzere.blogspot.com/2010/04/misuse- and-abuse-of-bug-counts.html
这可能是一个警告：
http://www.dilbert.com/fast/1995-11-13/
#2 楼
猎虫对于整个团队来说应该是有趣且富有成效的，而且进行一些专业比赛可以大大改善整个团队的道德水平并帮助他们成长。我很少遇到这种情况不同意乔。我也喜欢积分系统的想法。
但将扩展为包括：
每个人都参与错误查找；不只是测试人员。让开发人员，项目经理，业务分析师以及产品团队中的任何其他人员参与错误查找，使每个人都对“优质”游戏有所了解。
进行“季节性”错误搜寻。例如，有1个针对安全性的bug猎物，另一个针对全球化的性，等等，当然还有1或2个“开放”季节的bug猎物。这分散了“财富”，因为很少有1个人/团队可以“赢得”各种类别。
通过扩展类别来认识1个贡献者/团队。例如。最可复制的功能错误，严重性最高的问题，最具创意的错误等。
奖励团队中的每个人-在错误重击期间进行披萨或其他对待，在活动结束后立即进行团队士气活动，并对错误进行分类（例如，团队午餐，等等）
对漏洞进行分类之后，高层应将邮件发送给团队，概述漏洞修复的高水平结果，讨论对客户和团队的价值支持，并感谢大家的参与和继续“自我托管”。 '
使用错误搜寻作为学习工具。让有最多错误/最严重错误的人等解释或分享他们用来帮助他们发现这些问题的一些技术或方法。
#3 楼
我和乔在一起。当只为“最佳”奖励时-无论如何确定“最佳”，都将立即受到诱惑来玩这个系统，并有动机破坏团队合作。我希望采用一种面向群体的安排，这种安排不一定能奖励发现的bug数量（您想要的最后一件事是，人们每输入一个错字就提交一个bug报告-这是在浪费他们的精力。时间和开发人员时间），而是奖励整个团队-为解决这些问题的开发人员单独奖励。可能会获得更多“有趣”的奖项（证书和派对帽式的奖项），例如“最严重的错误”，“具有最复杂复制的错误”，“为什么有人会这样做？错误”等类别-无论您的想象力如何可以设计（您将领导一个测试团队-我敢肯定您可以提出一些好的建议，并使奖励幽默而适当）-在午餐时获得奖励。我还将包括一些通用奖项，例如从事此工作的“插件”，也许找到了一些有趣的错误，但没有发现很多，或者“幸运的某某”在最干净的代码中进行了测试。系统，无论他/她做什么都找不到很多（对于参与其中的开发团队来说，这也是一个有趣的奖项，也不会误入歧途），“最具想象力的测试方法”（不，将西瓜放在键盘上并不是我们真正期望的用户，但是我们会给您带来想象力），等等。
如果您的公司将寻宝活动视为团队建设活动，而不是团队之间的竞争，他们更有可能拥有更幸福的质量检查团队-它可以帮助您的测试人员在较小的Scrum团队中以更大的凝聚力团队的身份运作。
#4 楼
可供选择的几种替代方法如果每个人都尝试测试整个系统，则会出现此问题。首先，您可以为每个团队分配一个组件。他们可以报告该区域的缺陷。 30分钟后，可以将此组件移至另一个团队。现在，如果下一个团队记录了缺陷，那么就可以知道以前的团队是否错过了缺陷。
测试人员的成熟度和团队都很重要。我确信只有一两个团队成员的行为会导致冲突。最好的办法是教育他们或将那些测试人员放在同一个团队中
#5 楼
搜索错误是一个好主意。但是，如果已变成竞争，则必须校准规则以鼓励您想要的行为。这里是一个例子。许多年前，我在一家最初没有使用错误跟踪系统的公司工作。当我们最终采用它时，每当发现问题时，我都会尽力针对自己的代码记录缺陷。我已经习惯于在文本文件中跟踪我的错误，因此将它们记录在错误跟踪系统中是一项轻松的调整。后来我知道我的行为是少数。大多数开发人员避免根据自己的代码记录缺陷，并要求测试人员直接向他们报告问题。显然，这些开发人员认为，将根据记录在他们身上的错误的数量来判断他们，因此，他们在游戏系统上的方式击败了首先拥有错误跟踪系统的某些优势。
管理层可以通过告诉所有人开发人员没有通过其错误计数来判断问题，从而解决了该问题。或者，他们可以声明每个签入都应具有关联的错误编号。解决此问题的方法有很多，每种方法都有自己的取舍，在此我不会尝试列出所有方法。我的观点是，更改规则（更改激励措施）可能会将一些不良行为重定向到更好的行为。
我认为您的技术人员（包括质量检查人员和开发人员）都喜欢设计一种积分系统，该积分系统可以进一步促进漏洞发现和发现的目标。鼓励您所有人都希望自己的组织采取这种行为。为什么不问他们中的一些人呢？
#6 楼
在我们的案例中，我们在面对一个团队中的个人对他人的欣赏时遇到了类似的问题。生产力没有提高，反而下降了。我们所做的是，根据严重性级别将每个缺陷的点数记入积分，然后将其转换为“团队奖”。根据所收集的金额，团队决定了如何以道德的方式使用这笔奖金：)我们没有必要着重指出谁给管理层带来了最大数量的缺陷，但与此同时，团队很小，每个人都知道他们的努力/成果，每次我们进行此练习时，目标都是尽可能多地积累积分。后来的管理层限制了上限。
评论
好建议，北京。我特别喜欢“使用错误搜寻作为学习工具”。
–乔·斯特拉泽（Joe Strazzere）
2012年3月1日下午16:38
是的，我也很喜欢“将漏洞搜寻作为学习工具”的想法。我还喜欢让高管mgmt提醒所有人，为什么进行错误查找很重要。
–user246
2012年3月1日在17:54
+1以扩大奖项...否则，我不确定如果您定期举办这些活动，您将如何激励一大群人。
– Steve Miskiewicz
2012年3月2日15:32