【问题标题】:Demonstrate QA Improvement展示质量保证改进
【发布时间】:2009-09-17 15:39:51
【问题描述】:

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

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

【问题讨论】:

  • 感谢大家的回复。我们正在研究生产中的自动化和缺陷泄漏百分比。我不想特别提及任何事情,所以我不会“播种”讨论。我确实同意计数错误(在 QA 中发现)是没有用的,并且不能真正反映团队的努力或有效性。我还在考虑对错误报告进行审核,以确保它们符合准则(它们是否包括重现的步骤等)。但是,我更喜欢使用我已经拥有的数据,而不是创建一个流程来生成数据。

标签: metrics qa measurement


【解决方案1】:

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

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

【讨论】:

    【解决方案2】:

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

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

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

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

    如果还指定了您的目标(例如迁移到自动化测试系统),这可能是一种衡量方式。因此,如果您有 10,000 个测试用例,您的指标可能是自动化测试用例的数量,其中有多少通过/失败。

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

    【讨论】:

      【解决方案3】:

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

      发送错误以进行澄清的频率也可能很有用,就像开发人员花费大量时间与 QA 合作只是为了了解错误一样,这并不是最有用的消磨时间的方式。

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

      【讨论】:

        【解决方案4】:

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

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2014-01-26
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2015-12-27
          • 2015-05-10
          相关资源
          最近更新 更多