2

高层管理人员希望每个小组都表现出逐年的进步(即用数据证明收益,而不仅仅是陈述意见)。您在 QA 方面的改进情况如何?您使用了哪些指标?

这不是要对一个测试人员进行评级。它是关于展示一个部门的成长,并为个别测试人员提供突出个人改进的能力。

4

4 回答 4

3

有许多被误导的 QA 指标,包括发现的错误。这很简单,但如果软件没有太大变化,随着时间的推移,发现的错误数量将趋于零。

衡量单个测试人员以及他们提出了多少错误是在竞争类型中提供激励的一种方式,但也可能导致提出许多小问题(这可能是好事也可能是坏事)。

一些可能有用的指标包括:

  • 测量在现场发现的新错误的数量(即你错过的) - 这应该会下降
  • 是时候重新测试和关闭已修复的问题了
  • 发回澄清的错误数量(应该减少)
  • 因无效测试断言而关闭的错误报告数量 - 表示理解,应该减少

如果你的目标也被指定了——例如转向自动化测试系统——这可能是一种衡量方式。因此,如果您有 10,000 个测试用例,您的指标可能是自动化测试用例的数量,其中有多少通过/失败。

有一篇非常好的文章在讨论这个问题:http: //www.claudefenner.com/content/detail/QAMetricsPage.htm

于 2009-09-17T16:43:02.300 回答
3

重要的是要清楚您的 QA 部门是做什么的。这会因公司而异,但归根结底,QA 是一种数据收集操作。每个人/项目提交的错误数量很容易衡量,但与 QA 团队正在做的工作量或工作效率无关。

最好查看发布后客户发现的严重错误与 QA 发现的严重错误的百分比。随着测试的改进,这个数字应该会下降。此外,测量针对每个版本执行的测试用例的数量。随着 QA 流程的成熟,您应该会看到测试人员变得更有效率(通过熟悉或通过自动化)。

于 2009-09-17T16:28:48.647 回答
1

发现的错误有多复杂,例如,它是不是很简单,只是加载一个网页然后它就崩溃了,或者是否需要许多步骤来重现错误,这可能是一个使用的指标,可能会很有趣,看看它是如何进行的,尽管这在某种程度上取决于开发人员首先构建软件的能力。

发送 bug 以进行澄清的频率也很有用,就好像开发人员花费大量时间与 QA 配对只是为了了解 bug,这并不是最有用的消磨时间的方式。

最后,可能值得有人在这里创建一份 QA 101 手册,以便可以记录一些实践和知识并随着时间的推移进行修订,以显示在理解各种测试实践和使用有用的测试实践方面的增长。这些是我的建议。

于 2009-09-17T16:53:47.077 回答
0

我认为,通过报告的错误比率来衡量 QA 团队绩效的最佳方法:已修复错误。如果您的大部分错误都由开发人员修复,那么这表明您正在寻找质量错误,这确实需要注意。无效错误的数量应该是一个负面的衡量标准,因为这种错误会浪费开发人员的时间。

于 2012-06-18T06:54:31.650 回答