软件QA的好KPI是什么？

Question

如何衡量QA团队的效率？

你会安排什么KPI？

Answer 1

KPI可能是危险的--很容易测量错的东西或者更糟的东西，奖励错误的东西。一般的规则是人们会做更多得到回报的事情。

一些你应该考虑的事情：

• 如果您使用团队提出的bug数量，您将看到错误引起的错误，比如错误的像素。将其修改为使用超过指定严重级别的错误数将使您的错误像素被归类为紧急像素。
• 使用作为KPI测试或清除的bug的数量，往往会鼓励测试人员不那么彻底，集中精力检查所描述的bug是否已修复，而不涉及任何可能影响其统计数据的内容。
• 每个人的测试吞吐量同样危险:为了达到指标设定的标准，不那么彻底地进行测试的诱惑就会出现。
• 您使用的任何度量都将严重依赖于上下文--一个与开发人员一起工作的测试人员，该开发人员对其进行彻底的单元测试，确保他的集成是干净的，并且检查他所做的正确的事情不会在该开发人员的工作中发现很多bug。一个项目的时间表已经被削减，以满足外部的最后期限，将产生更多的错误，并有更多的错误到达客户，而不是一个良好的计划和执行，没有重大的时间或资源压力。
• 没有一个指标能够捕捉到测试的复杂性。谁做的更好，通过复杂的新特性并在一周内发现十几个严重错误的测试人员，还是通过复杂的新特性工作并在那一周发现一个灾难性错误的测试人员？答案都不是:两位测试人员都在寻找需要浮出水面的信息，但他们发现的信息不同，因为他们在不同的领域与不同的开发人员一起工作。
• 几乎没有人有资源让多个测试人员对同一个软件执行相同的测试。这意味着没有任何度量能够捕获性能，因为没有什么可以直接比较。涉及的变量太多了，包括测试人员在多大的压力下完成测试，以便能够发布该软件(不，这并不理想，但这是它在很多地方的工作方式)。
• 无论您使用什么方法，最好将它作为一个信息工具:这个团队平均测试这么多bug，所以如果我们要使用它们，我们需要安排这么多时间。使用一个度量来对测试人员进行排序会给出以下结果.比你想的要少。

我希望这张单子能帮你决定你需要做什么。

Answer 2

用于测试的最好的KPI是你想不到的。

• 团队能以令人厌烦的可预见性吗？
• 顾客开心吗？
• 产品销售吗？
• 在生产中发现的关键问题很少吗？
• 预算和时间表是否得到满足？

这些巧合是“整个团队”的KPI，其中测试起着关键的作用。

Answer 3

1. 被拒绝的缺陷的百分比-确保你的QA真正理解他在做什么。
2. 测试一个特性的时间-- QA需要多长时间才能真正测试一个特性
3. 逃脱缺陷的百分比-客户发布发布时发现了多少缺陷？
4. 系统的可用性等级
5. 我还会计算QA打开了多少个增强请求--确保它们也为系统提供了新的想法。