衡量测试效率

本文的目的是为读者提供一些通用的想法,以帮助他们衡量自己或团队的测试效率

“您无法控制无法衡量的事物” – Tom DeMarco

尽管在所有流程都趋于标准化的时候,这个想法可能已经100%正确了,但在快速发展的数字领域,它逐渐开始失去其字面意义。

在衡量测试效率时,这是一个非常有争议且相对的主题,并且有多种解决方法。

那么我们应该如何处理这个话题呢? 当我们要衡量测试工作的效率时,我们应该看到什么?

重要的第一步是要定义成功对于团队的测试工作意味着什么。 这项任务通常会落在项目管理职位上的人们的肩膀上,但也应该与团队讨论。 使用一组特定的指标来衡量成功。

没有通用指标,但每个项目都应该有一些指标。 部分地,可以将测试效率定义为报告给那些度量。

在我看来,诸如报告的错误数量或编写的测试数量或进行的自动测试数量之类的指标完全没有用。 您可能有1000个自动测试,这些测试实际上并没有检查任何重要的或重复的项目。 因此,大量测试毫无意义。

我们应该掌握哪些可能的指标?

请注意,以下内容是从一般角度介绍的,您可以找到详细信息,甚至可以找到准确的数学公式来计算其中的一些公式,但这并不属于本文的范围。

1.例如,测试成本是大多数管理者视为参考的非常重要的指标。 这取决于分配给该项目的测试人员的数量以及他们在该项目上专门工作的小时数。

2.团队测试工作的测试可重用性 -例如,可以参考由测试团队创建的测试文档,或者所有应用程序组件的术语表,甚至包含用户流程和测试案例的文档。 这些可以被重用,以帮助项目的新手更好地理解应用程序。 可重用性还可以指自动测试的编写水平以及如何重用它们,或者是否存在例如可以重用的错误报告模板。

3.缺陷解决时间 -该KPI与测试人员对错误的所有权有关。 重要的是不断跟踪您报告的错误以及在合理的时间内已将其修复以满足客户需求的错误。 缺陷解决时间对于严重的bug以及用户容易偶然发现并影响其正常使用情况的bug尤其重要。

4.拒收缺陷的百分比 —如果拒收的缺陷数量很多并且被拒收是有充分理由的(例如,不是由于测试和生产环境的差异),则意味着测试人员无法完全理解他们正在测试的组件,因此测试还没有完全发挥出来。

5.遗漏的bug的百分比 -这些是应用程序用户报告的缺陷,测试团队未发现这些缺陷。 如果有大量错误逃逸到测试人员手中并投入生产,以供用户稍后报告,尤其是如果这些错误易于复制或非常重要,则测试团队的效率值得怀疑。 当涉及逃逸的错误时,第三方应用程序也可以用来隔离它们。 诸如hotjar之类的应用程序可显示您的应用程序或哨兵的用户记录,该应用程序返回用户浏览器中生成的所有javascript错误以及用户在发现该错误之前所采取的步骤的痕迹,在隔离这些bug方面会大有帮助。

6.测试团队建议的增强功能 -如果测试团队不断提出有关产品的新想法和增强功能,则意味着他们参与并渴望帮助应用改进,因此这也可能成为衡量效率的指标。测试。 在我的其他一篇文章中,您可以找到有关改善应用程序可用性的一些指示。

7.测试范围 -这意味着要测试多少应用程序,但是相对来说很难确定,尤其是对于大型,复杂的应用程序。 重要的是要知道,在这种情况下,您无法全面测试所有内容。 相反,您可以做的是专注于重要的组件,而不是极端情况和非常不可能的情况。

8.测试时间 -这是测试人员检查新功能或错误修正所花费的实际时间。

9.自动化测试的百分比 -这对于稳定且每隔几个月不变的成熟应用程序尤其有效。 %由定义的测试总数计算得出。

10.涵盖的要求 -测量每个功能通过的要求也可能是测试效率的重要指标。 当需求被完整记录和详细说明(通常不会发生)时,该指标就显得尤为重要。

11.用户的积极反馈 -这是整体定性产品的指标,也是有效测试工作的指标。 对于拥有大量用户的应用程序尤其如此,因为增加了发现各种错误的机会。 因此,如果反馈保持肯定,并且用户没有遇到阻碍,则完成的测试将非常有效。

12.测试类型覆盖率 -这是指测试人员可以在更多区域运行应用程序。 某种产品经过全面测试后可能有0个功能错误,但是从未进行过性能测试,因此当100个用户遇到请求时,服务器出现错误,错误可能开始浮出水面,或者其可用性可能很差,用户无法找到什么。他们正在寻找。

13.项目概述 (具有总体情况)能够在分析阶段发现风险,遗漏要求,依赖项,现有功能与新功能之间的冲突,这是一大优势,可以赢得团队的赞赏。

14.测试工作量(时间)的估计-对当前正在使用的功能/修复程序/错误进行测试工作量的正确估计非常重要。 这意味着您应该拥有有关被测功能的足够信息以及足够的专业知识,以便能够与过去的事件相关并做出相对准确的估计。 如果在测试过程中出现变化,则可能需要重新估算,并应尽快宣布可能的延迟。 如果不这样做,则可能会产生延迟,这也将导致客户端失去信任。

使用上述指标的优势

  • 更好的跟踪
  • 增加测试工作的可见性(透明度)
  • 可以根据指标重新评估和改进流程
  • 适合自我评估(根据指标跟踪我们自己的发展)
  • 通过知识(“测量和记录的目的是通过知识” –有关更多详细信息,请参阅本文)
  • 它还可以提高员工的工作效率
  • 如果要求测试团队提供效率,请提供快速反馈
  • 设置指标还附带设置明确的目标(避免猜测状态)

可能的缺点

  • 特定于企业环境,那里有许多精心设置的流程并且所有内容都经过测量
  • 可能会妨碍绩效(当我们认为我们的工作不断进行衡量时,我们倾向于遵循某些模式并以满足那些具体衡量标准的方式进行操作,从而限制了我们的创造力或探索新事物的意愿)
  • 产生不信任感(某些人可能会认为:“如果我的经理想衡量我的一举一动,那么他显然不信任我”)
  • 创造进步的幻觉-当指标不断实现但项目未必一定朝着正确的方向发展时,可能会发生这种情况,与这些指标相比,这是很好的
  • 大多数企业所需的一些关键特征,例如情商,同理心和领导力,无法准确衡量
  • 速度下降–您将精力集中在创建文档上,而不是将精力放在测试上,因此效率较低(敏捷价值:我们认为工作软件胜于全面的文档)。
  • 成本-时间和金钱
  • 产生压力(不断交付指标)并激励人们

那么,我们真的要有非常特定的指标来衡量测试效率吗?

尽管在某些情况下它可能是有用的,但这样做可能也不会带来积极的结果。 在敏捷的情况下,将开发人员,测试人员,BA等称为开发团队,对测试效率进行衡量可以将“测试团队”与整个团队区分开。 我的意思是,质量的大部分责任落在测试团队的肩上。 在敏捷环境中的质量和持续交付归功于整个团队,而不是单个人。

这意味着,最终,客户满意度是衡量整个团队而不只是“测试团队”效率的最佳指标。 如果我们能看到差异和改进,那么即使没有定义系统,也可以使用一个测量系统。

相反,当测试人员想要评估其总体测试工作效率以及希望改进其实践时,可以使用其中一些指标。

最终意味着……

我们不应该仅仅因为我们听说它对项目有利或趋势发展就对您的团队进行某些实践或分析,而应该坚持那些能带来价值并提高项目质量的东西。

如果我们认为强制执行某些度量标准可以在这方面有所帮助,但是这样做对于每个项目都是不同的,因此没有“最佳实践”指南。