What is Shift Left Testing?
AlWagner 120000DGH6 Visits (23668)
The goal is to increase quality, shorten long test cycles, and reduce the possibility of unpleasant surprises at the end of the development cycle—or still worse, in production. In many organizations, automated testing of today’s composite applications is being executed via the user interface, once the complete application has been developed and deployed. Waiting for all the pieces to become available before testing commences, however, often causes delays, adds risk to the project or results in discovery of late stage defects—when they are more expensive to fix.
Shift Left practices help to avoid rework, delays and churn that can occur when major defects are discovered late in the testing cycle—after all integrations and product components are finally brought together as a composite application and made available for the team to test. It aims to avoid these issues by performing integration tests as code is being delivered and deployed in a realistic production-like test lab. If any of the dependent application components are not available to test, virtual services can mimic the real components behavior until they are ready.
In recent years, agile development teams have been able to minimize the risk associated with defect isolation by delivering working code in small batches, making it easier when problems occur to trace their cause to the offending code. But agile teams might not start with the most technically challenging and potentially disruptive parts of the code, which in complex products resides in the integrations. By contrast, teams that continuously test their code against integrated components can have better outcomes in reducing risk, as they are better able to find and fix potentially disruptive defects earlier in the lifecycle.
Simply put, this is what Shift Left means—shifting integration testing to the left of its usual position in the delivery pipeline so that it occurs as close as possible to the build process. By proactively testing high-risk integrations early and frequently, delivery teams can isolate the most disruptive, significant defects sooner for faster remediation. This smarter approach to continuous testing results in “quality at speed”—the concept that quality and speed are not only not mutually exclusive, but that with processes in place for concurrent testing and development, they can be achieved together for faster, more accurate results with fewer problems.
Avoiding unpleasant surprises late in the development lifecycle is an important benefit of shifting integration tests to the left, but there is another important benefit. Continuously delivering, building and testing in a tightly operationalized fashion allows the delivery team to receive feedback on code quality non-stop. This means that delivery teams can speed quality products to the market and validate new products or features with the customer. By shifting integration testing and feedback left—that is, closer to the beginning of the delivery pipeline—technical risk and the possibility of market failure are reduced. These are sound offensive and defensive tactics.