目录
What Is Agile Testing and an Agile Test Plan? 什么是敏捷测试和敏捷测试计划？
Running Tested Features 运行经过测试的功能
Common Agile Testing Issues 常见的敏捷测试问题
Agile Testing: How to Shift Left to Get It Right 敏捷测试：如何向左移动
Overcome Agile Challenges With a Testing Plan 通过测试计划克服敏捷挑战
翻译内容
The idea behind the Agile approach to project management is to encourage collaboration, transparency, and responsiveness to feedback among an integrated team. Agile software development means using the set of principles outlined in the Agile manifesto to develop high-quality working software, frequently.
敏捷的项目管理方法背后的想法是鼓励整个团队之间的协作，透明度和反馈响应。 敏捷软件开发意味着使用敏捷宣言中概述的一套原则来频繁地开发出高质量的工作软件。
The Agile methodology emphasizes fast-paced software development, meaning software testing must also be performed at speed while remaining thorough enough to ensure high quality.
敏捷方法强调快节奏的软件开发，这意味着软件测试也必须快速执行，同时保持足够全面以确保高质量。
It is vital for Agile teams to find a way to evaluate and improve their testing efforts. Test metrics are useful for providing basic measurements of the effectiveness of any software testing effort in Agile teams.
敏捷团队必须找到评估和改进测试工作的方法。 测试指标，对于提供敏捷团队中任何软件测试工作有效性的基本测量，非常有用。
This post outlines what exactly testing is in Agile development by comparing it to traditional testing in the old waterfall framework for software development. You'll also find out about Agile test plans and get the low-down on some useful Agile test metrics.
本文通过将其与旧瀑布框架中的传统测试进行比较，概述了敏捷开发中真正测试的内容。 您还将了解敏捷测试计划，并了解一些有用的敏捷测试指标。
We focus on six key metrics that are relevant to testing in an Agile team. See SeaLights' agile testing metrics learning section for a wider list of recommended metrics.
我们专注于与敏捷团队中的测试相关的六个关键指标。 更广泛的推荐指标，请参阅SeaLights的敏捷测试指标学习部分。
After reading this post, you will better understand how to measure the testing efforts of your software development teams and improve on them, leading to higher-quality software and more productive development. In other words, you’ll be better placed to achieve the goals of Agile development.
阅读本文后，您将更好地了解如何衡量软件开发团队的测试工作并改进它们，从而实现更高质量的软件和更高效的开发。 换句话说，您将更好地实现敏捷开发的目标。
What Is Agile Testing and an Agile Test Plan? 什么是敏捷测试和敏捷测试计划？
Before the Agile framework became popular, QA was a separate activity performed by independent testing teams. Today, Agile testing means testing your software for defects as done in an Agile development team.
在敏捷框架开始流行之前，QA是由独立测试团队执行的单独活动。 今天，敏捷测试意味着在敏捷开发团队中测试您的软件是否存在缺陷。
With Agile testing, developers take part in improving the tests themselves as they work, and with the help of increased automation and rapid feedback, Agile teams can deliver higher-quality software and ship to production faster.
通过敏捷测试，开发人员可以在工作时参与改进测试，并且借助增强的自动化和快速反馈，敏捷团队可以提供更高质量的软件，并更快地投入生产。
The test plan is an important document formally outlining software testing scope and activities. An Agile test plan differs from a traditional test plan used in the old waterfall approach.
测试计划是一份正式概述软件测试范围和活动的重要文件。 敏捷测试计划与旧瀑布方法中使用的传统测试计划不同。
Waterfall is a non-iterative, sequential software development approach in which development is divided into pre-defined phases. Test plans in waterfall are static because detailed requirements are defined before the software design phase. Such plans don't need much modification over the life of a project.
瀑布是一种非迭代的顺序软件开发方法，其中开发被划分为预定义的阶段。 瀑布中的测试计划是静态的，因为在软件设计阶段之前定义了详细的需求。 这些计划在项目的生命周期中不需要进行太多修改。
In contrast to the waterfall approach, an Agile approach calls for a dynamic test plan, which has the adaptability to meet changing requirements. A test strategy is vital because it helps teams to:
与瀑布式方法相比，敏捷方法需要动态测试计划，该计划具有满足不断变化的需求的适应性。 测试策略至关重要，因为它可以帮助团队：
- Understand at which points in a sprint they'll need to test features; 了解他们需要测试功能sprint中的哪些点;
- Proactively create test data to test dependencies between components that are still under development; 主动创建测试数据，以测试仍在开发中的组件之间的依赖;
- Know who is responsible for unit tests, when to begin automated testing, and which tools to use for testing. 了解谁负责单元测试，何时开始自动化测试以及使用哪些工具进行测试。
A dynamic test plan can, therefore, improve the productivity of Agile teams by ensuring thorough preparation for software testing and improved efficiency due to transparency in the testing strategy and processes. This type of test plan helps Agile teams to plan ahead while allowing the team to accommodate changing requirements.
因此，动态测试计划可以提高敏捷团队的生产力，这是通过确保软件测试的全面准备，以及由于测试策略和流程的透明性而提高效率来实现的。 此类测试计划可帮助敏捷团队提前计划，同时允许团队适应不断变化的需求。
Agile Testing Metrics 敏捷测试指标
After creating a test plan and beginning software testing, it’s important to assess how effective the software tests are by looking at data in the form of relevant metrics. The following metrics are examples of the types of measurements that can help an Agile team better achieve its goals.
在创建测试计划并开始软件测试之后，通过以相关指标的形式查看数据，来评估软件测试的有效性非常重要。 以下指标是度量的示例，可以帮助敏捷团队更好地实现其目标。
Burn-Down Chart 燃尽图
A burn-down chart is useful because of its simplicity as a metric. A burn-down chart plots outstanding work against time. Units of time can be days, iterations, or sprints. You can measure outstanding work in story points, features, and functions.
由于其作为度量标准的简单性，因此燃尽图非常有用。 燃尽图表显示了与时间相关的里程碑式的工作。 时间单位可以是天，迭代或冲刺。 您可以衡量故事点，功能和功能方面的里程碑工作。
The ideal line is plotted from the beginning of the iteration or project, and it connects in a straight line to the end point of the project. You can create a burn-down chart using Microsoft Excel or any one of several project management tools, such as Team Foundation Server.
从迭代或项目的开始绘制期望线，并且它以直线连接到项目的终点。 您可以使用Microsoft Excel或多个项目管理工具（如Team Foundation Server）中的任何一个创建燃尽图。
The actual line should track the estimates as closely as possible. The disparity between actual versus ideal in a burn-down chart gives a quick measure of a team's productivity. Assuming the team accurately estimates its productivity in terms of the ideal line, the burn-down chart provides a simple visual aid to quickly address any concerns when the actual work remaining far exceeds the estimated tasks.
实际线应尽可能地跟踪估计值。 在燃尽图表中实际与期望之间的差异可以快速衡量团队的生产力。 假设团队根据期望的生产线准确估算其生产率，那么当实际工作量远远超过估计的任务时，燃尽图提供了一个简单的视觉辅助工具，可以快速解决任何问题。
In Agile, a task is considered complete when both the development and the tests are complete. A common term used to define completion is “Done is Done,” meaning the completed tasks that appear on the burn-down chart have been tested and there are no additional related activities.
在Agile中，当开发和测试都完成时，任务被认为完成了。 用于定义完成的常用术语是“已完成”，这意味着已在燃尽图表上显示的已完成任务已经过测试，并且没有其他相关活动。
Running Tested Features 运行经过测试的功能
Running tested features (RTF) is an Agile metric that measures the amount of customer-defined software features verified as functioning by software tests. This metric is helpful because it essentially makes teams more agile by:
运行测试功能（RTF）是一种敏捷度量标准，用于衡量通过软件测试验证的客户定义软件功能的数量。 此指标很有用，因为它实际上使团队更灵活：
- focusing on features instead of design or infrastructure 专注于功能而不是设计或基础设施
- verifying each feature as working, producing ready-to-go software at each iteration. 验证每个功能是否正常工作，在每次迭代时生成随时可用的软件。
By measuring the RTF growth for a given project, teams can easily analyze whether there are issues with the software coding or the tests used to verify features as functional. The data is visually represented as a line graph based on a count of running tested features, providing easy verification on whether the quantity of running tested features grows with each iteration (as expected).
通过测量给定项目的RTF增长，团队可以轻松分析软件编码是否存在问题，或者用于验证功能的测试是否正常。 数据在视觉上表示为基于运行测试特征计数的折线图，可以轻松验证运行测试特征的数量是否随着每次迭代而增长（如预期的那样）。
Cumulative Flow 累积流量
A cumulative flow diagram maps an entire project's workflow, including tasks the team still needs to complete and tasks already completed. Since testing is part of the team's workflow, it is typically included on a cumulative flow diagram.
累积流程图映射整个项目的工作流程，包括团队仍需完成的任务和已完成的任务。 由于测试是团队工作流程的一部分，因此通常将其包含在累积流程图中。
By mapping the entire project workflow, Agile teams get valuable measurements of areas that end up being bottlenecks, with unproductive work in progress showing up as vertical bands that widen over the course of the project. For example, in the above diagram, work-in-progress, represented by the red area, widens over the course of the project, signifying bottlenecks in the project. Such areas of concern can be identified and addressed using this metric. You can create a CFD in Excel.
通过映射整个项目工作流程，敏捷团队可以获得最终成为瓶颈的有价值的测量结果，正在进行的非生产性工作显示为在项目过程中扩展的垂直带。 例如，在上图中，由红色区域表示的在制品在项目过程中变宽，表明项目存在瓶颈。 可以使用此指标识别和解决此类关注领域。 您可以在Excel中创建CFD。
Defect Cycle Time 缺陷周期时间
Agile teams should strive to fix bugs as quickly as possible. In fact, one of the main aims of the collaborative Agile approach is to fix bugs quicker so that software is released sooner. Such quick fixing can only arise when good tests are written and when testers effectively communicate with developers about defects. Cycle time measures the total time it takes to complete a task from the moment work begins on that task. Therefore, defect cycle time is a useful Agile metric because it conveys how well the Agile team works as a unit in fixing defects.
敏捷团队应该尽快修复缺陷。 事实上，协作敏捷方法的主要目标之一是更快地修复缺陷，以便更快地发布软件。 这种快速修复只有在编写好的测试和测试人员有效地与开发人员沟通缺陷时才会出现。 周期时间衡量从该任务开始工作的那一刻起完成任务所需的总时间。 因此，缺陷周期时间是一个有用的敏捷度量标准，因为它传达了敏捷团队在修复缺陷方面作为一个单元的工作情况。
Defect cycle time can be plotted as a graph using Office applications, showing the time it takes to fix defects on the y-axis versus iteration (or other interval) on the x-axis. The ultimate aim is a short defect cycle time as a result of well-designed tests, quick and thorough feedback from testing teams, and prompt fixing by developers. Iterations 6, 7, and 8 in the above chart have short defect cycle times versus the threshold.
可以使用Office应用程序将缺陷循环时间绘制为图形，显示修复y轴上的缺陷与x轴上的迭代（或其他间隔）所花费的时间。 最终目标是通过精心设计的测试，测试团队的快速和全面反馈以及开发人员的快速修复，缩短周期时间。 上图中的迭代6,7和8具有较短的缺陷循环时间与阈值的关系。
Defect Spill-Over 缺陷溢出
Agile teams aim to produce working software with each iteration. Defect spillover measures the defects that don't get fixed during a given iteration or sprint by simply counting the defects remaining at the start of each sprint or iteration.
敏捷团队的目标是在每次迭代时生成工作软件。 缺陷溢出衡量了每个冲刺或迭代中未被修复的缺陷量，即简单地统计每个冲刺或迭代开始遗留的缺陷量。
Such defects can accumulate over time when a team ignores them, leading to technical debt, which decreases productivity. Measuring this metric gives the Agile team an idea of how efficiently they are dealing with issues that arise. A simple bar graph provides a visual aid showing remaining defects per sprint or iteration. Ideally, few if any defects should spill over between intervals.
当团队忽视这些缺陷时，这些缺陷会随着时间的推移而累积，从而导致技术债务，从而降低生产率。 通过衡量这一指标，敏捷团队可以了解他们如何有效地处理出现的问题。 简单的条形图提供了一个视觉辅助，显示每个sprint或迭代的剩余缺陷。 理想情况下，如果有任何缺陷在间隔之间溢出，则很少。
Velocity 速度
Velocity is a useful metric within the context of an individual team. This metric simply compares the units of work completed during a sprint of a given length against the estimated work units it would take to deliver that sprint.
Velocity是单个团队环境中的有用指标。 该指标简单地将给定长度的冲刺期间完成的工作单元，与该冲刺所需的估计工作单位进行比较。
Velocity is a good way of measuring how well an Agile team matures over time. Ideally, velocity should improve with each sprint and then level off at a peak as the team reaches optimum productivity. You can view velocity charts in project management software, such as Atlassian.
Velocity是衡量敏捷团队随着时间的推移成熟程度的好方法。 理想情况下，每次冲刺时速度应该会提高，然后在团队达到最佳生产率时达到峰值。 您可以在项目管理软件中查看速度图表，例如Atlassian。
Common Agile Testing Issues 常见的敏捷测试问题
Even with the many different metrics to measure, testing is, in itself, a problem for Agile teams. It is clearly essential to test software thoroughly before releasing it, but testing tends to slow down the time to market for software. Therefore, the main Agile testing issues revolve around implementing solutions for improved efficiency and productivity. Some of the main Agile testing challenges are:
即使要测量许多不同的指标，测试本身也是敏捷团队的一个问题。 在发布之前彻底测试软件显然是必不可少的，但测试往往会减慢软件的上市时间。 因此，主要的敏捷测试问题围绕提高效率和生产力的解决方案。 一些主要的敏捷测试挑战是：
- Lack of test coverage. The pressure to get software out quickly can cause teams to write too few tests for user stories. It's important to have visibility on all code changes to write enough tests to cover the code in a given user story. 缺乏测试覆盖率。 快速推出软件的压力可能导致团队为用户故事编写的测试太少。 了解所有代码更改以编写足够的测试以覆盖给定用户故事中的代码非常重要。
- Broken Code. The more frequently a team delivers builds, the higher the chances of breaking existing code. Daily regression testing is impractical with manual test runs. In addition, as the use of microservices becomes more common, where each microservice runs in its own pipeline to production, it is essential to verify that all the moving parts are functioning and are properly integrated. 破碎的代码。 团队提供构建的频率越高，破坏现有代码的可能性就越高。 手动测试运行每日回归测试是不切实际的。 此外，随着微服务的使用变得越来越普遍，每个微服务在其自己的管道中运行到生产中，必须验证所有运动部件是否正常运行并且是否正确集成。
- Catching Defects Too Late. Defects found late in the development cycle cost much more to fix than those found earlier. This rule applies regardless of your project's framework. The challenge is to figure out the best way of identifying defects as early as possible in an Agile framework. There is a need to shift left, meaning conducting software tests as early as possible in the development cycle. 捕捉缺陷太晚了。 在开发周期后期发现的缺陷比以前发现的缺陷要花费更多。 无论您的项目框架如何，此规则都适用。 挑战在于找出在敏捷框架中尽早识别缺陷的最佳方法。 需要向左移动，这意味着在开发周期中尽早进行软件测试。
- Performance Bottlenecks. Agile teams need to understand how best to monitor software performance so that additional features do not cause significant system slowdowns. 性能瓶颈。 敏捷团队需要了解如何最好地监控软件性能，以便其他功能不会导致系统显着减速。
There are also a number of problems associated with tracking certain test metrics. Such metrics create problems because they can either cause confusion, go against Agile principles, or otherwise provide little value. For example:
跟踪某些测试指标还存在许多问题。 这些指标会产生问题，因为它们可能导致混淆，违背敏捷原则，或者提供很少的价值。 例如：
- Tracking individual metrics. This goes against the Agile ethos because it encourages excessive competition among members of the same team. For example, measuring productivity by counting the number of tests written. Too much competition compromises teamwork and creates quality testing issues. 跟踪个别指标。 这违背了敏捷的精神，因为它鼓励了同一团队成员之间的过度竞争。 例如，通过计算写入的测试数量来衡量生产率。 太多的竞争会影响团队合作并产生质量测试问题。
- Tracking meaningless metrics. Meaningless metrics are those that don't tell you anything about testing productivity. For example, comparing two Agile Scrum teams on their respective velocities is a poor metric, because velocity is unique to each team, as it depends on estimations unique to each team. Comparing velocities between teams encourages teams to fudge their estimates, leading to poor planning for sprints. 跟踪无意义的指标。 毫无意义的指标是那些没有告诉你测试生产力的指标。 例如，比较两个敏捷Scrum团队各自的速度是一个糟糕的指标，因为速度是每个团队独有的，因为它取决于每个团队独有的估计。 比较团队之间的速度会鼓励团队捏造他们的估计，从而导致对冲刺的计划不佳。
The only way to overcome the potential for using problematic test metrics or using test metrics incorrectly is to promote increased awareness of what constitutes a useful test metric in an Agile team among both team members and project managers.
克服使用有问题的测试指标或错误地使用测试指标的可能性的唯一方法，是在团队成员和项目经理之间提高对敏捷团队中有用测试指标构成的认识。
Agile Testing: How to Shift Left to Get It Right 敏捷测试：如何向左移动
Shifting left means moving towards testing software at the development stage instead of afterward. Testing conducted at the development stage is preventative rather than diagnostic; by proactively dealing with issues before the build moves forward, less time is wasted trying to find these issues later on.
向左移动意味着在开发阶段而不是之后转向测试软件。 在开发阶段进行的测试是预防性的而不是诊断性的; 通过在构建之前主动处理问题，可以减少时间浪费，避免在以后找到这些问题。
Shifting left can solve some of the main challenges in Agile, including catching defects as early as possible and improving code coverage.
向左移动可以解决敏捷中的一些主要挑战，包括尽早发现缺陷并改善代码覆盖率。
Some ways to get started with shift left testing are(开始左移测试的一些方法是):
- Using test automation to improve continuous delivery and minimize problems associated with broken code—for example, by using automated regression tools; 使用测试自动化来改善持续交付，并最大限度地减少与代码损坏相关的问题 - 例如，通过使用自动回归工具;
- Encouraging developers to code with testability in mind, which improves the reliability of the testing framework and speeds up the testing cycle; 鼓励开发人员在编码时考虑可测试性，从而提高测试框架的可靠性并加快测试周期;
- Defining quality controls at all stages of the software development life cycle. Such controls lead to corrective actions at the relevant stage instead of later on, ultimately improving the project's health. 在软件开发生命周期的所有阶段定义质量控制。 这种控制导致在相关阶段而不是在以后采取纠正措施，最终改善项目的健康状况。
It’s important to remember that metrics are still very relevant in the shift-left testing approach. You still need to evaluate tests to improve them, and test metrics provide the evidence required to make intelligent decisions about future software tests. Always gather data from the moment the testing effort begins.
重要的是要记住，在左移测试方法中，指标仍然非常相关。 您仍然需要评估测试以改进它们，测试指标提供了对未来软件测试做出明智决策所需的证据。 始终从测试工作开始的那一刻开始收集数据。
Overcome Agile Challenges With a Testing Plan 通过测试计划克服敏捷挑战
Agile teams require an approach to testing that reflects the cross-functional environment that Agile encourages.
敏捷团队需要一种反映敏捷鼓励的跨功能环境的测试方法。
Before any testing begins, it's important to outline a test plan. An Agile test plan is dynamic, incorporating emerging and changing requirements over time.
在任何测试开始之前，概述测试计划很重要。 敏捷测试计划是动态的，随着时间的推移包含新兴和不断变化的需求。
Test metrics in an Agile context are very relevant, but it's important to understand and use the appropriate metrics. Agile managers should be dissuaded from tracking metrics that are individually oriented.
敏捷上下文中的测试指标非常相关，但了解和使用适当的指标非常重要。 应该阻止敏捷管理员跟踪单独定向的指标。
The “shift left” concept aims to overcome the challenges associated with testing in Agile teams.
“左移”概念旨在克服与敏捷团队测试相关的挑战。
关于作者
Gilad Maayan
Gilad is the CEO and Founder of Agile SEO, a digital marketing agency focused on SaaS and technology clients. He has done strategic consulting, content marketing, and SEO/SEM for over 150 technology companies including Zend, Oracle, Electric Cloud, JFrog and Check Point. Together with his team, he's helped numerous tech startups move from zero to tens of thousands of users, and driven double to triple digit growth in conversion and revenue for established software businesses.
Gilad是Agile SEO的首席执行官和创始人，Agile SEO是一家专注于SaaS和技术客户的数字营销机构。 他为包括Zend，Oracle，Electric Cloud，JFrog和Check Point在内的150多家技术公司提供战略咨询，内容营销和SEO / SEM。 与他的团队一起，他帮助众多科技创业公司从零到数万用户，并推动已建立的软件业务的转换和收入增长了两位到三位数。
原链接
https://simpleprogrammer.com/testing-metrics-agile-environment/