敏捷开发的评价指标_如何在敏捷环境中使用测试指标

敏捷开发的评价指标

敏捷方法用于项目管理的思想是鼓励协作，透明性和对集成团队之间反馈的响应能力。 敏捷软件开发是指使用敏捷宣言中概述的一组原则来频繁开发高质量的工作软件。

敏捷方法论着重于快节奏的软件开发，这意味着软件测试还必须在保持足够透彻以确保高质量的同时快速进行。

对于敏捷团队来说 ，找到一种评估和改进测试工作的方法至关重要。 测试指标对于提供敏捷团队中任何软件测试工作的有效性的基本度量非常有用。

这篇文章通过将测试与旧的瀑布式软件开发框架中的传统测试进行比较，概述了敏捷开发中的确切测试。 您还将找到有关敏捷测试计划的信息，并对一些有用的敏捷测试指标进行了深入了解。

我们关注与敏捷团队中的测试相关的六个关键指标。 请参阅SeaLights的测试指标学习部分 ，以获取建议指标的更广泛列表。

阅读本文后，您将更好地了解如何衡量软件开发团队的测试工作并对其进行改进，从而带来更高质量的软件和更高效的开发。 换句话说，您将更容易实现敏捷开发的目标。

什么是敏捷测试和敏捷测试计划？

在敏捷框架流行之前， 质量检查是由独立的测试团队执行的单独活动 。 如今，敏捷测试意味着像敏捷开发团队一样对软件进行缺陷测试。

借助敏捷测试，开发人员可以在工作中自行改进测试，并借助增强的自动化和快速反馈，敏捷团队可以交付更高质量的软件，并更快地将产品交付生产。

测试计划是正式概述软件测试范围和活动的重要文档。 敏捷测试计划不同于旧瀑布方法中使用的传统测试计划。

Waterfall是一种非迭代的顺序软件开发方法，该方法将开发分为预定的阶段。 由于在软件设计阶段之前已定义了详细的要求，所以瀑布式测试计划是静态的。 这样的计划在项目的整个生命周期中不需要太多修改。

与瀑布式方法相反，敏捷方法需要动态测试计划，该计划具有适应不断变化的需求的适应性。 测试策略至关重要，因为它可以帮助团队：

• 了解在冲刺中哪些点需要测试功能；
• 主动创建测试数据以测试仍在开发中的组件之间的依赖关系； 和
• 了解谁负责单元测试，何时开始自动化测试以及使用哪些工具进行测试。

因此，动态测试计划可以通过确保为软件测试做充分准备并由于测试策略和过程的透明性而提高效率来提高敏捷团队​​的生产力。 这种测试计划可以帮助敏捷团队提前计划，同时允许团队适应不断变化的需求。

敏捷测试指标

在创建测试计划并开始软件测试之后，通过查看相关指标形式的数据来评估软件测试的有效性非常重要。 以下度量标准是可以帮助敏捷团队更好地实现其目标的度量类型的示例。

燃尽图

精简表非常有用，因为它作为度量标准很简单。 燃尽图根据时间绘制出色的工作。 时间单位可以是天，迭代或冲刺。 您可以衡量故事点，功能和功能方面的出色工作。

理想线是从迭代或项目的开始绘制的，并以直线连接到项目的终点。 您可以使用Microsoft Excel或几个项目管理工具（例如Team Foundation Server）中的任何一个来创建燃尽图。

资源

实际生产线应尽可能紧密地跟踪估计。 燃尽图中实际与理想之间的差异可以快速衡量团队的生产力。 假设团队根据理想的线准确地估计了其生产率，燃尽图提供了简单的可视化帮助，可以在实际剩余工作远远超出估计任务时Swift解决任何问题。

在敏捷中，当开发和测试都完成时，任务被视为完成。 用来定义完成的一个通用术语是“完成”，表示燃尽图上显示的已完成任务已经过测试，没有其他相关活动。

运行经过测试的功能

运行测试功能（RTF）是一种敏捷度量标准，用于衡量经过软件测试验证可以正常运行的客户定义软件功能的数量。 该指标很有用，因为它可以通过以下方式使团队更加敏捷：

• 关注功能而不是设计或基础架构，以及
• 验证每个功能是否正常运行，并在每次迭代时生成随时可用的软件。

资源

通过测量给定项目的RTF增长，团队可以轻松分析软件编码或用于验证功能是否正常的测试是否存在问题。 数据以运行测试功能的数量为基础，以折线图的形式直观地表示，从而轻松验证运行测试功能的数量是否随每次迭代（预期）增长。

累积流量

累积流程图映射了整个项目的工作流程，包括团队仍需要完成的任务和已经完成的任务。 由于测试是团队工作流程的一部分，因此通常包含在累积流程图中。

资源

通过绘制整个项目工作流，敏捷团队可以对最终成为瓶颈的区域进行有价值的度量，而非生产性工作则显示为在项目过程中不断扩大的垂直带。 例如，在上图中，以红色区域表示的在制品在项目过程中不断扩大，表示该项目中存在瓶颈。 可以使用此度量标准来识别和解决此类关注的领域。 您可以在Excel中创建CFD。

缺陷循环时间

敏捷团队应努力尽快修复错误。 实际上，协作敏捷方法的主要目标之一是更快地修复错误，以便更快地发布软件。 仅当编写好的测试并且测试人员与开发人员就缺陷进行有效沟通时，才会出现这种快速解决方案。 周期时间衡量从完成一项任务开始完成一项任务所花费的总时间。 因此，缺陷循环时间是一个有用的敏捷度量标准，因为它传达了敏捷团队作为一个团队修复缺陷的能力。

资源

可以使用Office应用程序将缺陷循环时间绘制成图形，以图表形式显示在y轴上修复缺陷所需的时间与在x轴上进行迭代（或其他间隔）的时间。 最终目的是通过精心设计的测试，较短的缺陷周期时间，良好的测试团队反馈以及开发人员Swift修复的结果。 上图中的迭代6、7和8具有相对于阈值而言较短的缺陷循环时间。

缺陷溢出

敏捷团队的目标是在每次迭代中生产可运行的软件。 缺陷溢出可以通过简单地计算每次冲刺或迭代开始时剩余的缺陷来衡量在给定的迭代或冲刺中无法修复的缺陷。

当团队忽略这些缺陷时，这些缺陷会随着时间累积，从而导致技术欠债，从而降低生产率。 衡量此指标可使敏捷团队了解他们处理出现问题的效率。 一个简单的条形图提供了直观的帮助，可显示每个sprint或迭代的剩余缺陷。 理想情况下，很少有缺陷会在两次间隔之间溢出。

资源

速度

速度是单个团队的有用指标。 该指标仅将给定长度的冲刺期间完成的工作单位与交付该冲刺所需的估计工作单位进行比较。

资源

速度是衡量敏捷团队随着时间推移成熟程度的好方法。 理想情况下，每次冲刺都应提高速度，然后在团队达到最佳生产率时达到一个峰值。 您可以在项目管理软件（例如Atlassian）中查看速度图表。

常见的敏捷测试问题

即使要衡量许多不同的指标，测试本身对于敏捷团队也是一个问题。 在发布软件之前，对软件进行彻底的测试显然很重要，但是测试会减慢软件的上市时间。 因此，主要的敏捷测试问题围绕着实施解决方案以提高效率和生产率。 敏捷测试的一些主要挑战是：

• 缺乏测试覆盖率。 快速推出软件的压力可能导致团队为用户案例编写的测试太少。 拥有对所有代码更改的可见性以编写足够的测试以覆盖给定用户案例中的代码，这一点很重要。
• 密码破损。 团队交付构建的频率越高，破坏现有代码的机会就越大。 每日回归测试与手动测试运行不切实际。 此外，随着微服务的使用变得越来越普遍，每个微服务都在其自己的生产管道中运行，因此必须验证所有活动部件是否正常工作并正确集成。
• 赶上缺陷太迟了。 在开发周期后期发现的缺陷修复成本要高于早期发现的缺陷。 无论您的项目框架如何，都适用此规则。 面临的挑战是在敏捷框架中尽早找出最好的识别缺陷的方法。 需要左移，这意味着在开发周期中尽早进行软件测试。
• 性能瓶颈。 敏捷团队需要了解如何最好地监视软件性能，以使其他功能不会导致系统严重下降。

跟踪某些测试指标还存在许多问题。 这样的度量标准会产生问题，因为它们可能引起混乱，违反敏捷原则或提供很少的价值。 例如：

• 跟踪个人指标 。 这违反了敏捷精神，因为它鼓励同一团队成员之间的过度竞争。 例如，通过计算编写的测试数量来衡量生产率。 太多的竞争会损害团队合作精神并产生质量测试问题。
• 跟踪无意义的指标。 毫无意义的指标是那些没有告诉您测试生产力的指标。 例如，比较两个敏捷Scrum团队在各自速度上的指标很差，因为速度对于每个团队都是唯一的，因为速度取决于每个团队唯一的估计。 比较团队之间的速度会鼓励团队弄乱他们的估计，从而导致对冲刺的规划不佳。

克服潜在使用有问题的测试指标或不正确使用测试指标的唯一方法是在团队成员和项目经理之间提高对敏捷团队中有用的测试指标构成的认识。

敏捷测试：如何向左移动以使其正确

左移意味着在开发阶段而不是随后转向测试软件。 在开发阶段进行的测试是预防性的，而不是诊断性的； 通过在构建前进之前主动处理问题，可以减少浪费的时间来以后再查找这些问题。

左移可以解决敏捷中的一些主要挑战，包括尽早发现缺陷和提高代码覆盖率。 开始进行左移测试的一些方法是：

• 使用测试自动化来改善连续交付，并最大程度地减少与破坏代码相关的问题，例如，使用自动化回归工具；
• 鼓励开发人员考虑可测试性进行编码，从而提高测试框架的可靠性并加快测试周期；
• 在软件开发生命周期的所有阶段定义质量控制。 这些控制措施导致在相关阶段采取纠正措施，而不是随后采取措施，最终改善了项目的运行状况。

重要的是要记住，指标在左移测试方法中仍然非常相关。 您仍然需要评估测试以改进它们，并且测试指标提供了做出有关未来软件测试的明智决策所需的证据。 始终从测试工作开始的那一刻开始收集数据。

通过测试计划克服敏捷挑战

敏捷团队需要一种能够反映敏捷鼓励的跨功能环境的测试方法。

在开始任何测试之前，概述测试计划很重要。 敏捷的测试计划是动态的，随着时间的推移不断纳入新的和不断变化的需求。

敏捷上下文中的测试指标非常相关，但是了解和使用适当的指标很重要。 应劝阻敏捷管理者不要跟踪面向个人的指标。

“左移”概念旨在克服与敏捷团队中的测试相关的挑战。

翻译自: https://www.javacodegeeks.com/2017/10/use-testing-metrics-agile-environment.html

敏捷开发的评价指标