在Scrum中衡量QA的最佳方法是什么？
我们有成员通常会测试，并根据他们发现的错误进行衡量。如果他们没有发现任何错误，那么他们就被认为做得不好。
然而，我的理解是开发人员和优质人员被认为是同一个人。我认为他们应该根据相同的指标进行评判...而不是与可能也在进行测试工作的开发人员不同的指标......
处理质量保证指标的最佳方法是什么？质量保证人员是否应该从开发人员的scrum中获得单独的指标？
有人可以就此向我指出哪些文件或链接？
答案 0 :(得分：12)
你总会得到你所获得的回报，所以奖励人们寻找更多的错误会给你带来更多的错误。
如果您开始奖励开发者同时创建更少的错误，那么您将获得一些非常有趣的团队行为。非常适合心理实验，但不适合提供软件。
答案 1 :(得分：9)
衡量QA的最佳方法是什么？ 争球？
工作软件。快乐的PO。客户满意。
我们有成员通常测试和 他们是根据多少来衡量的 他们发现的错误。如果他们没有找到任何 虫子然后他们被认为是 做得不好。
Scrum是一项团队运动。我们不衡量个人。
然而，我的理解是 开发人员和优质人才 被认为是同一个。我会 认为他们应该被评判 反对相同的指标......不是 不同的指标然后开发人员 谁也可能正在做测试工作......
你有一个误解。质量保证和开发我们同一个团队的一部分，但有非常明显不同的工作。开发人员构建东西，测试人员想出如何打破它。这是一种完全不同的心态和独立的技能组合。 dev和QA都致力于相同的sprint目标。不过，他们的确被判断为相同的指标：工作软件。
答案 2 :(得分：3)
而不是没有。质量保证的错误指标，有这样的指标： -
质量保证人员的指标
QE自动化指标： -
提供工作软件是QA和Dev的责任。对于dev，可能会有以下指标： -
我们的目标是通过明确的要求，强大的沟通，高质量的代码，代码审查，彻底的单元测试和详细的测试计划来避免错误。仅依靠'错误计数'将导致我们的项目走向错误的方向。
答案 3 :(得分：2)
我们有一种用于开发和QA的测量形式。它的好处在于它是基于实际活动，而不是猜测发现的错误的“质量”。
它被称为Cost of Quality。
基本上，每个人（开发人员和测试人员）都会将他们花在项目上的时间记录到几个桶中。 （每天或每周记录一次。）
与此相似的桶：
（我们还有其他几个存储桶，例如支持（针对没有发生故障的问题），要求（针对sprint规划期间的设计时间等）以及其他所需的存储桶。
这里的想法是将创建所花费的时间与修复错误所花费的时间进行比较。
我们的方式，我们的QA团队在sprint期间在dev中进行测试。然后发现的时间和问题都计入创建（对于开发人员和QA）。将产品发送到我们的测试环境后，所有QA时间都会记录在Appraisal下。发现的任何问题以及修复和重新测试它们所花费的时间都记录在内部故障下。
产品发布到生产环境后，任何花在bug上的时间都会被记录在外部故障中。
我们的想法是找出在内部（甚至更糟）外部故障上花费了多少时间。这可以让您了解QA的表现如何。
我们发现这些数字反映的是现实，而不是人为的“错误计数”或某些此类测量。
就像scrum一样，这需要一段时间才能让每个人都记录下来。但是一旦你开始，它就会提供一些非常好的指标。
答案 4 :(得分：1)
我只是想找到答案，为C级管理人员展示什么，并在那里发现了一些有趣的文章......就像 Agile KPIs ，Agile performance management，Agile metrics v6以及迄今为止最合理的Scrum metrics and reporting。
我最初的问题是如何显示描述scrum项目实际状态的绿色/黄色/红色标志 - 而不是特别与质量相关。
答案 5 :(得分：1)
作为曾经是测试人员的软件测试团队的高级经理，我看到度量标准在不断发展。我们曾经判断我们的测试人员发现了缺陷，事后看来这是一种愚蠢的做法。我看到并且是＃34;喂养＆＃34;当一个新的软件在旧的瀑布方法下被扔给我们时，每个测试人员都争先恐后地提出尽可能多的低悬的水果缺陷，以提高他们的查找率。当我们搬到敏捷时，一切都消失了。我现在每年做两次360评估，以评估每个测试人员的表现。这是一种通过直接反馈来衡量测试人员在敏捷团队中的有效性，开发人员如何将他们视为测试人员以及他们的技术专长和知识的方法。我的团队首先是地球科学家，第二是测试人员。他们必须有域知识来知道软件是否正在做它应该正确做的事情。仅仅缺陷数字是对某些人有效性的一种非常误导的衡量标准。关于数字偏差的AGile的另一个问题是我们提交了在短跑期间修复的问题，以及仅在冲刺结束后的缺陷。因此，仅测量缺陷只能让您了解故事的一半。我们发现，敏捷的早期测试可以将后来发现的缺陷数量减少80％以上。这在很大程度上归功于有效的测试用例编写。然后发现早期问题。测试人员还应评估用户故事的有效性。人格也是一个重要组成部分，他们与开发人员，项目经理，项目所有者和Scrum管理员的关系如何。所以我看看整个蜡球，而不只是页面上的几个数字，因为所有这些都用于生产客户想要的高质量软件。通过这种方式，我能够识别出几个低绩效者，他们的缺陷发现率并没有表明，但他们在其他领域的表现却很糟糕。由于缺陷报告以外的原因，项目经理不希望他们的团队在他们的产品上工作。
答案 6 :(得分：0)
这是来自游戏开发方面的事情所以考虑到这一点：
作为主要开发人员，我不会根据他们发现的错误数量判断我的测试人员，而是评估他们工作的质量和完整性。他们可以做的最糟糕的事情是报告一堆弱的，猜想类型的错误，以便制定一些错误配额。我宁愿看到记录完备的错误，它们可以准确地解释问题是什么以及它们如何复制它。如果只发现了一些质量错误的副本，那就这样吧，没有人应该遇到麻烦。
因此，是的，测试人员应该有来自开发人员的单独指标。他们根本没有做同样的事情。一个编写代码的开发人员会被许多很多错误所谴责，就像一个无法找到并标记容易重现的错误的测试人员一样。应该鼓励编写干净，易于阅读和管理的代码的开发人员，就像测试人员发现隐藏的错误，但记录错误。鉴于此，他们怎么能有相同的指标，scrum或没有？
答案 7 :(得分：0)
我们有QA验收标准，每个Sprint后由测试人员检查。如果不符合标准，Sprint要么失败要么需要一些改进才能集成到发布代码行。
最重要的标准是：
这确保了所有参与者都可以努力使QA快乐。标准不是那么技术性，以至于非开发人员无法检查它们（测试人员有一些技术背景），并且Scrum团队知道他们需要做什么来通过验收标准。这也意味着没有随机的度量质量检查，智能人员很容易解决或为他们的优势工作。一个好的测试脚本是一个很好的测试脚本，不能假装只是看起来像一个。
答案 8 :(得分：0)
我最喜欢的指标是转义缺陷的数量。在敏捷项目中，转义缺陷可以定义为
在sprint / iteration期间未识别的缺陷
通常，由于常规版本，我们忘记了sprint中实现的功能仍应正确测试。跟踪此数字有助于您在一个sprint / iteration中规划更少或更多的功能。
答案 9 :(得分：0)
此处的帖子已添加一些内容：