测量和控制产品质量

你是敏捷吗?看 敏捷团队的转向产品质量

如果您可以对产品的质量有更多的洞察力,那么它不会很好,而它是开发的,而不是之后?如果您可以衡量产品的质量,并且当存在质量低于客户需求的风险时行为?

测量质量的一种方法是通过使用缺陷数据以您开发和测试软件的方式了解漏洞。测试期间或客户在客户中找到的缺陷包含许多信息,您可以用来了解和改进您的工作方式。通过使用您可以衡量您的质量的数据,并且说明您无法管理您无法衡量的内容。因此,管理(和改进)质量从测量它开始。

可以用故障密度测量产品的质量。故障密度是已发现与产品大小相关的缺陷的数量(例如,在功能点或代码线中)。衡量和报告相对容易。但故障密度有一些主要的缺点;如果产品具有质量风险,您只能在阶段完成后衡量它的识别。

等一下你可能会说,我们很敏捷。我们还能转向产品质量吗?当然可以!我还通过公制应用了故障滑动,也可以在敏捷和scrum项目中进行,描述 敏捷团队中的产品质量。它’非常类似于增量或瀑布项目,所以让’我先看看那个。

缺陷滑动

我的偏好是 衡量缺陷滑动或故障滑移。该测量显示了在评论,测试和客户中发现了多少缺陷。通过进行根本原因分析(RCA),您可以获得早先检测缺陷的方法,从而节省时间和金钱。

您可以制作数据矩阵,显示您发现缺陷的位置,并且可以找到它们的位置。缺陷滑动,即通过审查或早期测试滑动的缺陷的百分比是您测试质量和产品质量的指标。

要构建具有缺陷数据的矩阵,您需要收集来自评论和测试的数据,并对缺陷进行分类。最小分类是发现缺陷的位置,并且可以找到缺陷的位置。此外,您可以对缺陷进行分类。这可能是在要求定义期间,或者在设置产品架构时,或者它可能是编码错误。当然,分类缺陷需要专业判断,并且必须由开发和测试软件的团队的成员来完成。

减少故障滑移

让我给一些 例子 如何使用故障滑动。在一个项目,我们为每个增量收集缺陷数据。经过一定的增量,我们发现功能测试中发现的缺陷数量正在增加,而在同一时间评论发现缺陷较少。

在分析某些缺陷之后,我们发现开发人员对设计规则的了解不足,因此在评论期间没有找到他们未找到的代码中的缺陷。在设计规则中培训他们有助于降低所做的缺陷次数,并增加评论期间发现的缺陷数量。功能测试发现缺陷较少,因为他们中的大多数都已早先找到。缺陷滑动显着减少,项目测试中的项目节省时间,然后在培训和评论中投入更多时间。

另一个例子是通过分析使用故障滑动,从而显着减少客户发现的缺陷,从而降低了维护成本。如果客户发现缺陷,则在释放之前发现它们的成本要高得多。已经测量了故障滑动,并证明了早期寻找缺陷并防止缺陷的投资确实退还了。即使在几个月内超过5%或10%的缺陷滑度也可以达到5%或10%,给出了大量的储蓄。当您还考虑到产品质量声誉时,您还考虑了哪些缺陷,那么对降低缺陷滑动变得更加重要。

项目缺陷模型

我创建了一个Excel电子表格来测量和分析缺陷滑动,并估计释放产品中的产品潜在缺陷数量。它’S称为项目缺陷模型。该模型支持分析数据,其中包含计算值和图表在当前状态和趋势方面比较实际估计。

当我为爱立信工作时,我开发了项目缺陷模型。我们在许多(瀑布,迭代和敏捷)项目中使用此模型来控制产品质量,并帮助我们达到交货日期,留在预算范围内,评估风险,并作出关于释放和维护的决定。我们还收集流程和产品数据以提高R的性能&D organization.

有关项目缺陷模型的更多详细信息,我们尝试过的试点项目以及在爱立信中的应用此模型,请参阅:

我的书的第二版 什么推动质量 将有一个详细描述此模型,并解释如何由敏捷团队使用。

结论

作为我的第一个例子,通过可以帮助您提高产品的质量,测量和管理故障滑动。它也可以用于增量项目。在未来的文章中,我会描述如何 敏捷团队中的产品质量.

(这篇博客发布了2011年5月22日,并更新了2011年10月6日:用图表扩展,2013年1月27日更新:添加了敏捷,并更新了2018年6月18日:增加了项目缺陷模型)。

分享这种经历
  • 29
    分享

本林德林

我帮助组织具有有效的软件开发和管理实践。有关敏捷,精益和质量的多个网络的活跃成员,以及常见的演讲者和作家。

这篇文章有6条评论

  1. Sankaran Natarajan.

    你好Ben,

    我看到缺陷密度有一个重要的措施,也有助于估计产品或项目需要揭示的缺陷,基于产品/项目的大小/复杂性。这有助于确保特定于缺陷渗透前的阶段。

    当您所说的实际缺陷密度只能在完成实施阶段之后找到,但是需要提供这种措施,以便将释放质量视为客户并估算未来项目的缺陷。

    另外,通过跟踪实际缺陷数量,阶段明智我们可以到达未来项目的项目缺陷模型,考虑到项目环境也是相同的。通过相关或回归分析,我们可以获得某些缺陷预测模型的变化因素。

    整体上FST的一篇好文章

  2. Cirilo Wortel.

    嗨本,我真的很喜欢这个想法!当它在一个敏捷上下文中使用时,没有预期错误留下Sprints,用于测量从生产中反馈的实际质量至关重要。如果实际上透过的错误是分析团队可以真正改善。

    1. 本林德林

      Exactly. It’s not about the figures, but about defects that customers find, which should have been found earliet. Or shouldn’t be made at all, that where Root Cause Analysis helps: http://www.022rl.com/2011/business-reason-for-root-cause-analysis/

  3. 百思南希

    虽然这篇文章是相当的“old” it’s仍然有效。我正在尝试设置一种方法来测量每个期间发现的缺陷数量“quality check”。但是,有一件事我难以做到。您如何衡量代码审查期间发现的问题数量?特别是当团队正在研究在工具(JIRA)中创建的故事时,并向故事添加评论。除非您想通过每张票证,否则手动计数为注释添加的缺陷数量。你有这件事吗?

  4. 贝纳莱德

    测量审查缺陷确实可能很难。作为替代方案,您可以测量代码模块的修订次数。

    It’S不是直接替代,但可以用作触发器:当代码模块经常更改时,您可以调查原因。可能是开发人员正在执行TDD,并且该模块经常更改。但它也可以是代码模块容易出错,也许是质量风险。

    为了测量敏捷质量,我使用不同的方法,看 敏捷团队的转向产品质量.

发表评论

本网站使用AkisMet减少垃圾邮件。 了解如何处理评论数据.