向左转移测试需要整个团队的努力

原链接

https://www.stickyminds.com/article/shifting-testing-left-team-effort

Shift-left is an approach to software development where testing is performed earlier in the lifecycle—in effect, moved left on the project timeline. Shifting left does not refer only to dynamic testing, or actually running the system; it also can refer to static testing, so it means conducting reviews and inspections too, as well as more unit and integration testing instead of GUI-based testing.

Shift-left是一种软件开发方法，在生命周期的早期执行测试，在项目时间轴上向左移动。向左移动并不仅仅指动态测试或实际运行系统; 它也可以指静态测试，因此它也意味着进行评审和检查，以及更多的单元和集成测试，而不是基于GUI的测试。

In an agile or DevOps environment, it often means testing small parts of the software as early as possible instead of testing at the end of the sprint. In that sense, shift-left and continuous testing relate partly to the same goals and practices, although continuous testing focuses more on automation. Test-driven development (TDD) and behavior-driven development (BDD) also can be an implementation of shifting left.

在敏捷或DevOps环境中，它通常意味着尽早测试软件的一小部分，而不是在sprint结束时进行测试。从这个意义上讲，左移和连续测试部分地涉及相同的目标和实践，尽管连续测试更侧重于自动化。测试驱动开发（TDD）和行为驱动开发（BDD）也可以是左移的实现。

There are many reasons to shift left, including to prevent project delay, reduce lead time, uncover implicit requirements, and find bugs as early as possible. This article will look at one case study of a large organization that shifted its testing left, along with the practical testing techniques its team members employed, the challenges they encountered, and how they found success.

向左移动的原因有很多，包括防止项目延迟，缩短交付周期，发现隐含需求以及尽早发现bug。本文将介绍一个大型组织的案例研究，该组织将其测试结果转移，其团队成员采用的实际测试技术，遇到的挑战以及他们如何取得成功。

Context for the Case Study 案例研究的背景

The implementation of shift-left on which this article is based took place in a large financial organization. This organization has to implement laws and regulations in their software, and these implementations have fixed deadlines for production. The organization was transitioning from a waterfall development approach to agile/SaFE software development. Development took place in a multifunctional team with four analysts, two developers, and one tester, who were working on a component that calculates payments to individuals.

本文所基于的左移的实现是在一个大型金融机构中进行的。该组织必须在其软件中实施法律和法规，并且这些实施具有固定的生产期限。该组织正在从瀑布式开发方法过渡到敏捷/ SaFE软件开发。开发工作由一个多功能团队组成，有四名分析师，两名开发人员和一名测试人员，他们正在研究计算个人付款的组件。

One of the issues the team often ran into was the availability of shared testing environments between teams. The team was not the only user of the test environment, and the functionality to be tested was often in a different software branch or version than what was installed on the testing environment. As it was a shared environment, you cannot just install the version you need for your tests, because the other users of the test environment might be running tests they need to finish first. This means idle time for the team while it waited for the other team.

团队经常遇到的一个问题是团队之间共享测试环境的可用性。该团队不是测试环境的唯一用户，并且要测试的功能通常与测试环境中安装的软件分支或版本不同。由于它是一个共享环境，您不能只安装测试所需的版本，因为测试环境的其他用户可能正在运行他们首先需要完成的测试。这意味着团队在等待其他团队时的空闲时间。

In order to meet the deadlines, the team had to be creative and see if they could speed up testing, or at least minimize idle time before the testing environment would be available.

为了满足最后期限，团队必须具有创造性，看看他们是否可以加速测试，或者至少在测试环境可用之前最大限度地减少空闲时间。

Shifting Left in Practice 在实践中向左移动

The team took its first steps in shifting left during regular sprints for a software release. The test design was made parallel to development, and both were based on requirements and specifications made by the analysts. (This is also done in a traditional waterfall project environment, and shift-left can also be used there without issues.) The test design was elaborated on in test scenarios, which were documented in the test management tool.

在常规冲刺期间，该团队迈出了向左移动的第一步，用于软件发布。测试设计与开发平行，并且都基于分析师提出的要求和规范。（这也是在传统的瀑布项目环境中完成的，左移也可以毫无问题地使用。）测试设计在测试场景中详细阐述，测试场景中记录了测试管理工具。

After this point, the team usually had to wait for the developer to commit his changes to the repository and for the software to be deployed in the testing environment. However, the team was confronted with a longer than expected waiting period due to the time the test environment was available for our team and the changes another team had deployed in the testing environment.

在此之后，团队通常不得不等待开发人员将他的更改提交到存储库以及在测试环境中部署软件。但是，由于测试环境可用于我们团队的时间以及另一个团队在测试环境中部署的更改，团队面临着比预期更长的等待时间。

But the testing environment was not the main cause of these issues. The main cause was the fact that multiple teams were working in the same codebase without distributed version control, which made it challenging to specifically test the change you are working on instead of the combined changes of all the developers that are in that software build.

但测试环境不是这些问题的主要原因。主要原因是多个团队在没有分布式版本控制的同一代码库中工作，这使得专门测试您正在进行的更改而不是该软件构建中的所有开发人员的组合更改具有挑战性。

To spend the idle time as well as possible, the developer and the tester decided to run the tests locally in the development environment before the software was committed to the software repository. Normally, this is not in line with the principles of independent testing; besides, the local development environment differs from the testing environment. However, the risk due to running on a different configuration was deemed minimal because integration tests are also run after each software delivery on a test environment.

为了尽可能地花费空闲时间，开发人员和测试人员决定在软件提交到软件存储库之前在开发环境中本地运行测试。通常，这不符合独立测试的原则; 此外，本地开发环境与测试环境不同。但是，由于在不同配置上运行而导致的风险被认为是最小的，因为在测试环境中的每个软件交付之后也会运行集成测试。

A testing environment should be as close to the production configuration as possible in order to make sure those factors do not influence functionality or behavior of the application. But the team decided to do the initial test on the development environment and run regression tests on the test environment after it became available.

测试环境应尽可能接近生产配置，以确保这些因素不会影响应用程序的功能或行为。但是团队决定对开发环境进行初始测试，并在测试环境可用后对测试环境进行回归测试。

This way of working had some consequences. First, it meant that we needed to ensure that the development environment was capable of running tests. The tests were executed by the test tool used in this project, an in-house developed propriety test tool developed by the tester himself. The test tool needed to be run locally on the developer's computer so the tester could upload and run the test cases.

这种工作方式产生了一些后果。首先，它意味着我们需要确保开发环境能够运行测试。测试由该项目中使用的测试工具执行，该测试工具是由测试人员自己开发的内部开发的专有测试工具。测试工具需要在开发人员的计算机上本地运行，以便测试人员可以上载并运行测试用例。

Second, it meant the team needed to minimize potential double work. Running on a developer's laptop means running on a different configuration compared to the test server (i.e., locally versus an integral test environment), meaning you would have to test twice to make sure configuration issues would not lead to different test results. To cope with this, we automated the tests directly after running them and made sure they would be included in the regression test set that was running in the continuous integration build after each commit. This meant we only needed to execute tests twice: once manually and once automated.

其次，这意味着团队需要尽量减少潜在的重复工作。在开发人员的笔记本电脑上运行意味着与测试服务器（即本地与整体测试环境）相比，运行在不同的配置上，这意味着您必须进行两次测试以确保配置问题不会导致不同的测试结果。为了解决这个问题，我们在运行测试后直接自动化测试，并确保它们将包含在每次提交后在持续集成构建中运行的回归测试集中。这意味着我们只需要执行两次测试：一次手动，一次自动化。

It also meant that the way issues were processed was different. Normally, if tests were run in the test environment and a bug was found, it was recorded in the bug tracking system. Because the tests were run in the development environment first, the developer could follow the path the test case took through the code. This meant that if something went wrong, the developer could see it happen in real time and make adjustments accordingly. It’s a bit like test-driven design—you have a test case and you make the software work before you move on to the next one. The only time we deviated from this was when the fix would take longer than thirty minutes, in which case we would record the issue in the bug tracking system.

这也意味着处理问题的方式不同。通常，如果测试在测试环境中运行并且发现了bug，则会将其记录在bug跟踪系统中。因为测试首先在开发环境中运行，所以开发人员可以遵循测试用例通过代码的路径。这意味着如果出现问题，开发人员可以实时看到它并进行相应的调整。这有点像测试驱动的设计 - 你有一个测试用例，你可以在进入下一个软件之前使软件正常工作。我们唯一的偏离时间是修复时间超过30分钟，在这种情况下我们会将问题记录在bug跟踪系统中。

But most importantly, it meant that the developer and the tester were working very closely together during test execution. This is logical if you are working in an agile team, but it is nice to experience it in practice.

但最重要的是，这意味着开发人员和测试人员在测试执行期间紧密合作。如果您在敏捷团队中工作，这是合乎逻辑的，但在实践中体验它是很好的。

Pros and Cons of Shifting Left 左移的利弊

We do not want to imply that shifting left is always perfect, or even always applicable; like every other method in software development, there are a number of advantages and disadvantages.

我们不想暗示左移一直是完美的，甚至总是适用的; 像软件开发中的其他方法一样，有许多优点和缺点。

The first advantage is that the testers and the team as a whole had less overhead and less paperwork. This is more of a precondition for shifting left. In some projects and test methodologies, the amount of documentation is overwhelming, and you end up with a lot of paperwork that is probably never looked at again. When working in a shift-left environment, we document only the necessary things, like bug reports for issues that cannot be resolved quickly.

第一个优点是测试人员和整个团队的开销更少，文书工作也更少。这更像是左移的先决条件。在一些项目和测试方法中，文档数量非常庞大，最终你会得到大量的文书工作，而这些文书工作可能永远都不会被重新审视。在左移环境中工作时，我们仅记录必要的内容，例如无法快速解决的问题的bug报告。

The second advantage we experienced was better collaboration between disciplines. Because the tester started earlier with test preparation, most test conditions were collected by discussions with the analysts who designed the functionality. By being involved in the design activities, you can familiarize yourself with the functionality and how the developer is planning to implement it. And by doing the testing together with the developer, you can discuss what you see and how the developer interprets the functionality to be built. The developer and tester can also discuss bugs, which is definitely more efficient compared to recording bugs in a tool.

我们经历的第二个优势是不同团队之间更好的合作。由于测试人员早期开始进行测试准备，因此大多数测试条件是通过与设计该功能的分析师讨论而收集的。通过参与设计活动，您可以熟悉功能以及开发人员计划如何实现它。通过与开发人员一起进行测试，您可以讨论您所看到的内容以及开发人员如何解释要构建的功能。与记录工具中的bug相比，开发人员和测试人员也可以讨论bug，这肯定更有效。

The third advantage is that everybody in the team was thinking and working outside their comfort zone. Usually testers just focus on the specs to make the test design. But in a shift-left situation, you work together with the developer, so you get the same information concerning the functionality. This saves a lot of time discussing what the system is meant to do, and you get a better idea of what the other development disciplines are doing. The developer can also help you when you make your test design and prepare your tests, which gives the developer and tester better insight into what the other discipline is doing.

第三个优势是团队中的每个人都在思考并在他们的舒适区之外工作。通常测试人员只关注规范来进行测试设计。但是在左移的情况下，您与开发人员一起工作，因此您可以获得有关功能的相同信息。这节省了大量时间来讨论系统的用途，并且您可以更好地了解其他开发规程正在做什么。在进行测试设计和准备测试时，开发人员还可以帮助您，这使开发人员和测试人员能够更好地了解其他人员正在做什么。

The last advantage we saw was that shifting left enabled early automation. By testing earlier, teams created the possibility to automate test cases earlier and reuse the automated test cases, even within the sprint. It is good practice to execute the test case before automating it in order to make sure the test case runs smoothly when automated. By executing it earlier, you can automate it earlier.

我们看到的最后一个优势是左移可以实现早期自动化。通过之前的测试，团队创建了提前自动化测试用例并重用自动测试用例的可能性，即使在sprint中也是如此。最好在自动化之前执行测试用例，以确保测试用例在自动化时顺利运行。通过先前执行它，您可以更早地自动执行它。

However, there also were some pitfalls and downsides to shifting left. The first disadvantage was that testing was less independent. When working closely with the developer during testing, you can be tempted to actually test the code the developer has implemented—but this is not always what you should be testing. What the tester should be testing in this situation is what the specifications say, not the developer’s interpretation of that. This issue can be mitigated by running integration tests, but it remains something a tester should be aware of.

然而，左移也存在一些陷阱和缺点。第一个缺点是测试不那么独立。在测试期间与开发人员密切合作时，您可能会尝试实际测试开发人员已实现的代码 - 但这并不总是您应该测试的内容。在这种情况下，测试人员应该测试的是规范所说的，而不是开发人员对此的解释。运行集成测试可以缓解这个问题，但它仍然是测试人员应该注意的事情。

The second disadvantage has to do with metrics. They don’t tell the whole story. This disadvantage is a bit subjective and mostly depends on what you do regarding issues. In this project, we decided to record only the issues the developer could not fix directly. However, one of the key performance indicators that was used in this organization was the number of bugs found during system tests and integration tests versus the bugs found during the acceptance tests and production. Because we recorded very few bugs, the number seemed pretty low. Management was curious about how this was possible because their metrics were not in line with the issues being found in acceptance testing. Due to this way of working, this metric no longer had value.

第二个缺点与指标有关。他们没有讲述整个故事。这个缺点有点主观，主要取决于你对问题的处理方式。在这个项目中，我们决定只记录开发人员无法直接修复的问题。但是，该组织中使用的关键性能指标之一是系统测试和集成测试中发现的bug数量与验证测试和生产期间发现的bug数量。因为我们记录的bug很少，所以数量似乎很低。管理层对如何实现这一点感到好奇，因为他们的指标与验收测试中发现的问题不符。由于这种工作方式，该指标不再具有价值。

Becoming Shift-Left Believers 成为左移信徒

The main goal in this project was to meet the deadline of the implementation of the new business rule engine. By starting the test earlier than planned in another environment, we managed to do so. But what contributed mostly to our success was that every member in the multidisciplinary team looked beyond their own responsibility. By the time the team was used to this way of working, they all preferred it. The collaboration between testing and the other disciplines greatly improved.

该项目的主要目标是满足新业务规则引擎实施的最后期限。通过在另一个环境中提前开始测试，我们设法做到了。但是，对我们成功的主要贡献在于，团队中的每个成员都超越了自己的责任。当团队习惯这种工作方式时，他们都喜欢它。测试与其他人员之间的合作大大改善。

One funny detail of this story is that nobody on the team had heard of shifting left before. We were just looking for practical solutions to problems they encountered, and this was the logical way of working. Now that we know this is a proven approach that is gaining traction, we can say that we are supporters of shifting left.

这个故事的一个有趣的细节是，之前团队中没有人听说过左移。我们只是在寻找他们遇到的问题的实用解决方案，这是合乎逻辑的工作方式。既然我们知道这是一种可靠的方法，我们可以说我们是左移的支持者。