评估软件QA团队性能的最佳指标是什么？

Question

评估软件QA团队性能的最佳指标是什么？

我正在寻找与以下指标类似的度量标准：

1.测试效率

 Test Efficiency = ((A-C)  /  (A+B))*100

 A = Defects found by test team

 B = Defects Found by customer

 C = Total number of Invalid defects found during Phase "A". 

2.缺陷泄漏可以用

 Defect Leakage = (A  /  (B-C))*100 

 Where

 A = Total Defects found in production.

 B = Total defect found by test team.

 C = Total number of Invalid defects found during Phase "B". 

3.缺陷抑制率

 Defect Rejection Ratio = ( A  /  B) * 100

 A = Number of defects rejected by development team

 B = Total number of defects raised

这个度量对于测量测试人员的效率非常重要:在记录缺陷时，测试人员不应该通过创建无效的缺陷而浪费开发团队的时间。

Answer 1

没有最佳度量

我还没有遇到一个测试人员，他想要创建无效的缺陷、遗漏缺陷，或者提出后来被拒绝的缺陷。如果这种情况经常发生，那么问题可能不在于您的测试团队，而在于您流程中的其他问题。

更详细地考虑你的建议：

测试效率/缺陷泄漏(测试团队漏掉的缺陷比例/由客户发现或逃往生产的比例)

• 每个项目是不同的-一个可以有良好的资源，客户谁积极地与团队合作，并帮助确保客户联络和团队之间的所有沟通是明确的。另一个可以让客户告诉你他们想要什么，然后什么也不说，直到你发现客户说他们想要的不是他们真正需要的。测试小组对此不负责。
• 应用程序复杂性很重要--向一个大型、复杂的应用程序添加新特性，可能会比一个小型、独立的应用程序有更多的bug逃逸给客户。
• 功能完成/准时/彻底测试--选择任意两个--如果您的软件受到客户强加的截止日期的限制，通常不会牺牲功能。测试就是。如果您的测试人员报告说，他们已经测试了基于您和他们对客户需求的理解的最高优先级区域，但没有时间进行更多的测试，那么您作为测试领导或项目领导的责任是确保客户理解他们所承担的风险和他们咄咄逼人的时间表，而不是用一个不现实的标准来击败您的团队，每次发生这种情况都会惩罚他们。
• 客户报告缺陷，以获得免费的新功能-这是方式，方式太普遍了。我曾经见过这样的情况:客户会在一份明确表示不会做某事的文档上签名，然后报告同样的缺陷的缺失。很少有跟踪系统区分这些情况和实际缺陷，许多公司会将这些隐形功能请求作为bug修复来实现，以维护客户的信誉。

无效缺陷/拒绝缺陷

• 您有什么保证规范或用户故事足够完整，使被拒绝的缺陷不只是不同的视图或期望？
• 谁在抚养他们，谁拒绝他们？我曾与程序员合作过，他们会拒绝屏幕无法读取的布局缺陷，因为设计规范没有包括用于间隔的像素数。
• 缺陷是无效的，琐碎的，还是根本没有足够的优先级立即修复。这造成了很大的不同--也没有被简单的衡量标准所考虑。
• 需求变化的速度有多快？我曾经在很多领域工作过，在这些领域，需求(不管它们是如何表达的)每天都会发生几次变化。也许测试人员的最新版本要比开发人员多，反之亦然。

衡量你的团队的最好方法是知道他们在做什么，他们遇到了什么问题。您在这个问题中讨论的度量标准是可以用来度量跨团队沟通问题、外部沟通问题、团队和部门挑战等问题的类型。用它们来衡量团队的表现是不准确的，在我看来是滥用的，而且在最好的情况下会让你的数字被玩弄，在最坏的情况下，让你和一个没有功能的，充满怨恨的团队在一起。

Answer 2

测试人员不应通过创建无效的缺陷而浪费开发团队的时间。

我认为测试人员也不应该因为微小的缺陷而浪费开发人员团队的时间。

玩游戏系统:度量的问题是人们会尝试玩游戏系统。

我个人认为我很擅长发现许多实际用户不会遇到的缺陷。一些例子可能是不一致的边距/填充、不正确的语言使用、在以表单形式提交千兆字节数据时出现的错误以及单击流会导致实际用户永远不会遵循的错误。报告这些问题可能会浪费无数个小时的开发时间。

根据您的统计数据，我可能是一个很棒的测试人员，因为我发现了大量的“有效”缺陷。

指标:引用一些来自另一个问题的度量。

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

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

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

也请阅读这个问题及其答案：软件QA的好KPI是什么？

Answer 3

这在很大程度上取决于你想达到什么程度。有些测试方法可以完全不使用度量。应该有理由进行一些度量和度量收集。

问题太广，不能被接受，所以您可以在这里举一些QA度量的例子：http://www.getzephyr.com/resources/whitepapers/qa-metrics-value-testing-metrics-within-software-development