Need a quick and dirty explanation of what shift left testing is so you can keep up with the cool kids? This is the post for you. 

What is Shift Left Testing?

In an Agile world, software and IT teams are under constant pressure to move faster. Typically, this means decreasing the relative length of delivery time while continuing to improve quality on each successive release. At the same time, there's always pressure to minimize testing costs.

For many organizations, the adoption of Agile development initiatives requires that different testers with different skillsets become involved in testing. Since Agile work products are built in short sprints (iterations), it is also necessary that developers are involved in the testing as early as possible. To test properly, the testers need to work with product owners and developers so that they can prepare as early as possible to test effectively. This quality assurance movement has become known as “shifting left”. (The reason for this may become clearer as you read on)

The benefits of shift left testing

Shift-left does more than help your team find bugs earlier. It can also help a team collaborate better with all stakeholders, improve collective competency, and craft more realistic test cases.

Shift-left testing brings with it several cultural benefits since it places greater emphasis on:

• Customer collaboration is more important than contract negotiation.
• Responding quickly to change is more important than strict adherence to a plan.
• Interactions among individuals are more important than processes and tools.
• Working software is more important than comprehensive documentation.

In summary, shift-left testing enables:

• More intensive focus on customer requirements and better user experience.
• Early detection of problems and defects, which contributes to cost reductions.
• Early, progressive, continuous testing that reduces the number of actual defects.
• Shorter cycles and higher quality.

Conventional waterfall testing is inefficient and inflexible

In the past, most software teams employed a waterfall methodology. The workflow for these teams resembles a staircase.

In this conventional approach to development, only the product team works with customers. They eventually return with user requirements, a roadmap, and an aggressive schedule. Then, a short meeting occurs at which developers walkthrough the new feature proposals. Tasks are assigned and everyone goes off to their silos to work. If any testers get access to these early stages, it's typically limited to observing the developer planning session. With little involvement up to that point, QA is then asked to give effort/duration estimates on what it will take to test the new code.

On too many projects, and even with too many agile teams, testing is low-priority consideration. It’s much easier to get developers together with product staff well upstream in the delivery pipeline. It's much easier to focus on building the product. A succession of development sprints continues, but it’s difficult to convince product and development to weave testing into each iteration. Early testing is often a struggle.

The result is that testing gets squeezed into a short window prior to customer release.  As many teams will attest, this passive approach to testing creates quality problems and builds tension between developers and the testers. For managers that want to move faster, testing is seen as a bottleneck. It’s important to realize that testing only becomes a bottleneck when testing isn't approached as a whole-team effort. In many companies, this is lamentably the way things are done.

If you want a deeper read on what software delivery iterations look like in modern software teams, check out this blog: https://www.mabl.com/blog/shift-left-shift-right-shifting-and-why 

The basic concept of shift left testing

Only "rockstar" few teams are testing much more effectively by shifting left. In such teams, testing begins at the start of each and every cycle. Testers participate in design efforts, asking questions about customer requirements. Not only does this result in some design changes, but the testers learn first-hand about the ultimate standard for testing the release. Some testers may realize that it’s much more efficient to work closely with component and system developers. They can ask probing questions, begin forming testing approaches and formulate testing scenarios. Other testers might meet with the API developers and work to create test stubs for new services. As practicable, testers can progressively test new features as they are made available. As testers are actively participating more in these earlier phases, they are effectively "shifting left" in the waterfall sequence of events in the software delivery pipeline. 

Some testing will occur at the very end, but it should be residual. It should be relatively faster since most of the problems have already been found and mitigated. Shift-left doesn't move to test to the beginning of a development cycle, rather the testers get together with the product owner and analysts before anything is built, getting involved in each phase as appropriate. Shift-left injects testing into each sprint. For more details on how testing processes should change when you shift left, check out this blog by Lisa Crispin: https://www.mabl.com/blog/how-testing-processes-should-change-shift-left

Shift left testing reshapes product development

In conventional waterfall software delivery practices, there tends to be too much waiting. This is almost always the case at the start of a cycle when both testers and developers are waiting on requirements. Testers continue to wait for new builds, and also wait for developers to declare code-complete so that regression testing can move ahead. A lot of time is spent idling or trying to avoid being idle. It can be much better! Productivity can increase significantly when testing is done further upstream.

Generally, shifting left is an initiative that involves QA as far upstream as possible. The aim is to prevent some defects from ever materializing and also to identify any actual defects as early as possible. Shift-left is an effort to integrate the team more closely to perform testing early. As a member of such a team, testers can be much more productive.

Want to help your testing team keep up with the pace of modern software delivery? Use mabl to create robust automated functional UI tests quickly and run them at scale, hassle free.