Shift-Left Testing: What It Is and How to Achieve It

This is a guest post written by Dan Martin, editor at TestProject.

Shifting left means incorporating critical processes into a project early in the software development cycle. To adopt shift-left testing in the beginning stages, a team needs to change its mindset from the traditional ways of shift-right testing.

Shift-left testing is made possible with the help of unit testing and API testing, and then eventually integrates them through integration tools or end-to-end testing. Postman and TestProject are great examples of test automation tools that support QA automation engineers with this approach. In this blog post, we’ll walk through the shift-left testing methodology in detail, as well as how API testing can make it more of a reality.

How is shift-left testing different from shift-right testing?

In the shift-right testing model, we code, build the code, and then test. The feedback on the product is only received later in the cycle. That means the health of the product is revealed later, literally as a surprise. In shift-left testing, testers are introduced to the concept of validating the product much earlier in the development cycle.

In addition to testing earlier in the process, testing occurs more frequently and in smaller units. The team receives feedback about the product in smaller unit checks. As a result, the emphasis is on prevention rather than detection of any issues.

What can you shift left?

• Code merges: Continuous integration becomes the focus, and a team has daily code merges
• Security: Continuous affirmation that a code is secure all along the way, which a DevSecOps model encourages
• Testing: Continuous testing, early and often, so that bugs are discovered earlier, fixes happen sooner, and the cost of repairing that bug becomes lower

A real-world example

Here is a real-world example to help illustrate the benefits of shift-left testing. The test automation project team at TestProject had the responsibility of ensuring that a secure messaging application product worked efficiently to meet the business requirements of a banking domain client. The application had to be tested for various messaging functions, user groups combinations, security, publish-subscribe aspects, etc.

Initially, while the project was following the shift-right way of testing, we were building test suites that were packaged as long-running tests, including function, and the end-to-end tests. We usually ran them during the night. Yes, we were using the cloud and automation as well, but things still weren’t going well.

When these colossal-sized tests failed, we had to do all of the following:

• Retrace through many huge chunks of code to find the root cause of the error. Errors would crop up from deployment failures, to test failures, and even test report failures.
• Debug through massive functional end-to-end tests, which took a lot of time.
• When we did fix the issues, we had to deploy the long-running tests again, hoping that it would pass this time, or else it would mean spending additional time debugging, fixing, and then rerunning the tests.

And despite all these “busy” tasks that were performed during the test/QA stage, many high-priority defects were caught in the product when rolled out to the customer by the end-user, and not early by the QA team—proving it to be an unreliable method to test the product. Any defect caught by the customer is, after all, more cost to the organization.

So, we then made an important mindset change to resolve these issues. We wanted to move out of this unreliable way of testing. In order to do so, we turned back to the very beginning of the test portfolio, back to the start of the software development cycle—the shift-left testing way.

We started planning and writing small-sized tests, at the lowest level possible. This is where we relied on designing API tests. We also ensured that these tests could be executed anywhere, at any time, in any environment—including in the production environment.

Eventually, we aimed to have our product testable at any point in time.

Also, unlike in the case of the colossal tests we relied on earlier, we found that the small-sized API tests provided these advantages:

• It was much easier to find the root cause of the error.
• It was more manageable, and quicker to debug the issue.
• It was an easy task to fix the errors as well.

We ensured that we used a widely used tool so that the code was shareable across the team. The test product then became a shared service for the whole team. During the process, we set up the team dynamics so that the test ownership ran parallel with the product code ownership. The accountability was focused on the person who built the code.

Now, did we continue using the larger functional tests and integration tests? Yes. We only categorized to run them when required as a part of a release time. We ensured that these functional tests were run in isolation. However, we made API tests our focus, which we regularly ran at any time of the day; they were always running, irrespective of whether a release cycle was scheduled or not. We also came up with the API tests that were benchmarked to be quick-running tests.

As a result, we started treating the test automation code with the same respect and attention that we would with the development code, from debugging to reviews, and more.

Successes of shift-left testing

We eventually experienced the following successes:

• We started getting positive feedback about the quality of the product more often.
• We caught many defects in the product early in the QA stage before the product was rolled off to the customer. Eventually, fewer defects reached the customer.
• We fixed errors as soon as they were reported.

As a result, we had a stable, reliable, high-quality secure messaging application ready to be rolled out in production for our banking client. When the product was eventually used by the banking customers, they were delighted with the hassle-free user experience.

As far as the project planning, we were also able to quickly build traceability matrices based on test coverage with the move to the small-sized unit tests. Clear coverage reports were swiftly constructed and tracked to check how much we were testing each of the features. Since the goal was to increase the test coverage as time went by, we wrote more API tests.

With this new emphasis on testing early, continuously, and testing every feature of the product, we saw the evolution of what ended up being a robust product.

Shift-left testing enablers

The following are the most important shift-left testing enablers for any project:

Virtualization: moving towards cloud enablement

All your API tests are best deployed on the cloud. When the tests are cloud-deployed, you can easily and quickly schedule them to run across several platforms.

Visualizing test results

Tools that help visualize the test results will save time for the team as well, so make use of a tool that supports this feature. If they are customizable, even better.

Collaboration

Collaboration is a vital enabler for shift-left testing to be successful. Team collaboration is strengthened with the help of tools that allow team members to collaborate. It’s essential to factor in the following when considering features of API testing tools:

• Does the API automation tool have a feature wherein your API tests are quickly shared with other team members? Sharing and collaboration should be effortless. The tool should easily group the API tests that were shared with them, and by them.
• Does the tool allow integration with third-party collaboration tools like Slack, GitHub, etc.?
• Does the tool allow integration with DevOps tools? The tool should be extensible to integrate API tests into your existing CI/CD service.

Get started shifting left

Moving to shift-left testing involves a cultural change. A team should be trained to trust this switch in methodology, plan well, and execute it through completion. Since API testing is the secret to effective shift-left testing, relying on an efficient API test automation tool goes a long way. Tools like these allow integration with external tools, which is an added benefit to this methodology. So, equip yourself and start shifting left for a change!

Technical review by Arlemi Turpault.

Do you have your own experience or tips to share with the Postman community? We want to hear from you. Learn more about our guest blogger program and submit your idea here.