scrum质量度量[关闭]

你总是会得到你想要的,所以奖励那些发现更多错误的人会给你更多错误。

如果你开始奖励开发人员在创建更少的bug的同时,你会得到一些真正有趣的团队行为。很适合心理学实验,但不适合交付软件。

测量质量保证的最佳方法是什么 并列争球?

工作软件。快乐的阿宝。快乐的顾客。

我们的成员通常会测试 他们是根据多少人来衡量的 他们发现的虫子。如果他们找不到 那么它们被认为是 干得不好。

scrum是一项团队运动。我们不衡量个人。

然而,据我所知 开发人员和质量人员 认为是同一个。我会的 认为他们应该受到审判 根据同样的标准…不 与开发人员不同的指标 可能也在做测试工作…

你有误会。qa和dev我们是同一个团队的一部分,但有非常明显不同的工作。开发人员构建东西,测试人员找出如何打破它。这是一个完全不同的心态和独立的技能集。dev和qa都致力于相同的sprint目标。不过,他们的评判标准确实是一样的:工作软件。

不是没有针对qa的bug度量,而是有这样的度量:

质量保证人员指标

• %缺陷的年龄(问题)来自于分配给qe的特性的customer/beta/prerelease/internal user。将其与qe记录的总bug进行比较。
• %被qa撤销的缺陷/无有效缺陷记录的期限(标记为notabug/asdesigned/notreproductable)

量化宽松自动化指标:

• 文档化的测试用例中有多少%的年龄是自动化的。旨在实现高自动化覆盖率。
• %代码覆盖的年龄。通过单元测试/白盒/自动化。
• %通过自动化和手动发现的老化错误。

交付工作软件是qa和dev的责任。对于dev,可能有如下指标:

• 在估计的时间内将特性交付给QA。延迟方差是一个指标
• 在对等代码评审中发现的错误(在发布给qa之前)。例如,标准可以是每1k个位置,错误不应超过5个
• 为unittest编写了多少代码。%单元测试中包含的测试用例。
• 每1K位置发现的漏洞
• 如何灵活和可重用的代码,以便未来的增强/错误修复可以做而不做重大的改变(这样就不需要大的QE工作,因此不影响我们的计划估计)

我们的目标是通过明确的需求、强大的通信、高质量的代码、代码评审、彻底的单元测试和详细的测试计划来避免错误。仅仅依靠“错误计数”将导致我们的项目走向错误的方向。

我们有一种用于开发和qa的度量形式。它的好处是基于实际的活动,而不是猜测发现的错误的“质量”。

它被称为 Cost of Quality 是的。

基本上,每个人(开发人员和测试人员)都将他们在一个项目上花费的时间记录在几个bucket中的一个bucket中。(时间可以每天或每周记录。)

与此类似的桶:

• sprint(在dev env中开发和测试所花的时间)
• 测试(在测试环境中测试所花费的时间)
• 发布前bug(bug发布到生产环境之前花在bug上的时间)
• 发布后bug(bug发布到生产环境后花在bug上的时间)

(我们还有其他几个bucket,比如支持(对于没有失败的问题)、需求(对于sprint规划期间的设计时间等)和其他需要的bucket。

这里的想法是把在创建中花费的时间与修复bug的时间花费在一起。

按照我们的方式,我们的qa团队在sprint期间在dev中进行测试。找到的时间和问题对创建(对于开发人员和qa)都很重要。一旦产品被发送到我们的测试环境,所有的质量保证时间都会记录在评估中。发现的任何问题和修复和重新测试的时间都是在内部故障下记录的。

在产品发布到生产环境之后,花在bug上的任何时间都会记录在外部故障下。

我们的想法是找出在内部(甚至更糟的)外部故障上花费了多少时间。这可以让您了解qa的实际执行情况。

我们发现这些数字比人工的“错误计数”或一些类似的测量更能反映现实。

就像scrum一样,这需要一段时间大家才能正确记录。但一旦你开始,它提供了一些非常好的指标。

我只是想为C级主管找到答案,并在那里找到了一些有趣的文章…喜欢 Agile KPIs ,请 Agile performance management ,请 Agile metrics v6 到目前为止最合理的(如果有的话) Scrum metrics and reporting 是的。

我最初的问题是如何显示一个绿色/黄色/红色的标志来描述scrum项目的实际状态——与质量无关。

作为一个软件测试团队的高级经理,曾经是一名测试人员,我看到了度量的发展。我们曾经根据发现的缺陷来判断测试人员,事后看来这是一种愚蠢的做法。当一个新的软件在旧的瀑布方法下被扔给我们时,我看到了并且成为了“喂养”狂热的错误归档的一部分,因为每个测试人员都争先恐后地归档尽可能多的低挂果缺陷,以提高他们的发现率。当我们转向敏捷时,一切都消失了。我现在每年做两次360度评估来评估每个测试人员的表现。这是我通过直接反馈来衡量测试人员在敏捷团队中的效率,开发人员对他们作为测试人员的感觉,以及他们的技术专长和知识的一种方式。我的团队首先是地球科学家,其次是测试员。他们必须有领域经验,以知道软件是否正在做它应该做的正确。仅仅是缺陷数是衡量某个人有效性的一个非常误导性的指标。敏捷的另一个扭曲数字的地方是,我们在sprint期间提交要修复的问题,只有在sprint结束后才提交缺陷。所以只测量缺陷只会给你一半的故事。我们发现,敏捷中的早期测试可以将后来发现的缺陷数量减少80%以上。这在很大程度上是由于有效的测试用例编写。早期的问题被发现了。测试人员还需要评估用户情景的有效性。个性也是很重要的一部分,他们与开发人员、项目经理、项目所有者和scrum管理员相处得如何。所以我看的是整个蜡球,而不仅仅是一页上的几个数字,因为所有这些都用于生产客户想要的高质量软件。通过这种方式,我能够识别出几个表现不佳的人,他们的缺陷发现率本不会显示出来,但他们在其他领域的表现却糟糕透顶。由于缺陷报告以外的原因,项目经理不想让他们加入他们的团队来开发他们的产品。

这是从游戏开发的角度考虑的,所以要考虑到:

作为一名开发主管,我判断我的测试人员不是看他们发现的bug数量,而是看他们工作的质量和完整性。他们所能做的最糟糕的事情就是报告一堆弱的、推测型的错误,以便制定一些错误配额。我宁愿看到有详细记录的bug,它们能准确地解释问题是什么以及它们是如何复制的。如果只发现了一个具有thsi质量的小虫子,那就这样吧,没有人会有麻烦。

因此,是的,测试人员应该有独立于开发人员的度量标准。他们根本不是在做同一件事。一个开发人员,他写的代码会被很多很多的错误所困扰,而这些错误会被指责,就像一个测试人员,他无法找到并标记容易复制的错误一样。应该鼓励编写干净、易于阅读和管理的代码的开发人员,就像鼓励发现晦涩的错误、但有良好文档记录的错误的测试人员一样。既然如此,他们怎么会有相同的标准,scrum还是no?

我们有qa验收标准,测试人员在每次sprint之后都会检查这些标准。如果不满足标准,sprint要么失败,要么需要一些改进,然后才可以集成到发布代码行中。

最重要的标准是:

• 完整而合理的测试脚本。 最新通过的测试脚本 适用或适当的错误案例 被归档。
• 所有错误都正确归档 并且很好的解释了为什么 没关系在 冲刺。
• 自动测试运行,是 完整,可以理解 非开发人员和代码覆盖率 没事的。(这是为了整合 仅测试,单元测试不关心 质量保证。)

这确保了所有相关人员都能工作,让qa感到高兴。这些标准技术性不强,非开发人员无法检查(测试人员有一些技术背景),scrum团队知道他们需要做什么才能通过验收标准。这也意味着,没有随机的度量质量检查,聪明人很容易解决问题或为自己的利益而工作。一个好的测试脚本是一个好的测试脚本,不能被伪装成一个样子。

我最喜欢的指标是漏掉的缺陷数量。在敏捷项目中,逃逸的缺陷可以定义为

在sprint/iteration期间未识别的缺陷

通常情况下,由于定期发布,我们会忘记在sprint中实现的功能应该仍然得到正确的测试。跟踪这个数字可以帮助您在一个sprint/迭代中计划更少或更多的功能。

已经在这里添加了一些帖子:

• 测试用例通过率=(通过的测试数)/有效的数量
• 分组测试
• 每个生成发现的错误数
• 每个模块发现的错误数
• 发现错误间隔时间
• 找到的缺陷的限定优先级
• P1缺陷之间的平均时间
• 执行每个测试发现的错误的测试时间