Enable DevOps Success, Improve QA with Shift Left Testing – Automation Testing as the Secret Ingredient

Shift left testing = a practice of testing frequently, as early as possible. That’s shift left testing in a nutshell!

The QA Team has an important role to play in executing DevOps. Shifting left requires two key DevOps practices to be considered which are continuous testing and continuous deployment. As you read through this article, you will understand how shifting left truly empowers DevOps.

This article also discusses the cultural shift this move encompasses, and the advantages that are inferred from it. Test automation has been the secret ingredient in making shift left testing work successfully, and with that, some tools have been listed to help you explore this further as well.

The topics discussed in this article are:

• Shift left testing – Why shift left, and not right?
  • Shift right testing – A brief overview
  • Shift left testing– A culture shift from the traditional waterfall model towards agile methods.
• 7 steps we took to implement shift left testing: My story.
• The choice of the right automation testing tool.
• Advantages with shift left testing
• How shift left testing synced with DevOps
• Wrap up

Shift Left Testing – Why shift left, and not right?

Shift right testing – A brief overview

In the traditional way of working in a project, in a waterfall method, the team would test much later in the project. The result was obvious as there was a high number of errors reaching the customer. A defect discovered late in the project is much more expensive to correct, both in finances and in terms of effort. A defect found late may even cause significant design changes and may involve a lot of effort in addressing the issue. All this signifies the shift right way of testing.

Shift left testing– A culture shift from the traditional waterfall model towards agile methods.

Shift left testing is about –

• Testing frequently – In a project that works this way, they keep testing, while the project runs. They do not wait for a project to end to take action on testing.
• Test as early as possible –as soon as small increments of code blocks are developed; these code deliverables are handed over for testing.

With the incorporation of this methodology, the lines are blurred between the testers and developers, as they are always working with each other, and not as two separate entities. This becomes a significant cultural shift and has proven to result in robust products being built. After all, quality is the key in business outcomes, and The QA team holds the power behind customer satisfaction.

7 steps we took to implement shift left testing: My story

When did I first start believing in the power of shift left testing? Here is my story:

We, in the QA team, were running functional and integration tests. We ran them only at the end of every development cycle. However, we noticed that many defects were reaching the customer. Delays in the project and correction of defects reaching the customer were proving costly.

With this issue, we quickly got together and decided to revamp our test strategy – to shift left in testing. We decided to test all parts of the project.

• Step 1 – The testers and the development teams started working side by side with developers in creating the deployment and testing process.
• Step 2 – We started relying on building small-sized tests. We set benchmarks on how small they ought to be. We started building and running small chunks, or unit tests. These tests were different from the functional and integration tests, in that they were:
  • Significantly smaller in size
  • Ran faster
• Step 3 – We decided to run these tests frequently and as early as possible. With this change, we saw that we were able to figure out the level of quality of the project much earlier. And as per the current running quality that we saw, we started making quick decisions on fixing the issues if any, much earlier. This resulted in:
  • Finding the defects much earlier
  • A drastically reduced number of defects reached the customers
• Step 4 – We worked in a TDD fashion –test-driven development. TDD requires you to first write tests for the piece of code that you want to develop. We started incorporating this strategy concerning any new feature requests that came in. Therefore, once the code was ready, we could immediately verify the validity of the piece of code being tested.
• Step 5– We relied on automation development and testing. We built a lot of unit tests. We kept adding in more. We ensured a broad test coverage. However, we could not get them manually designed in less time. For this, we used automation testing tools to quicken up this process. The shifts we incorporated are:
  • We built small unit API tests using API test automation tools.
  • We started using a scriptless automation tool – zero code platforms – which helps you build code with record playback and with no manual coding at all. Quick coding can be performed with these tools.
  • We used tools that used Self-Healing AI – These automation tools heal the code when an error occurs, automatically, with the power of artificial intelligence. We need to catch up with the Industrial revolution 4.0, and tools with such cutting edge technologies will help you move towards it.
  • We used BDD –It helped people from all over the project collaborate with each other with ease.
• Step 6 – Provisioning resources from the cloud. Rather than provisioning resources from the “on-premises” lab, and waiting for resources as they become available, we started provisioning resources from the cloud. Cloud-available resources were available 24/7, and we didn’t need to wait for resources. For example, BrowserStack is a tool that I can recommend for cloud-based provisioning of resources.
• Step 7 – We started relying on the test analysis reports more often. After all, there were more frequent tests being run. We started analyzing trends and deriving insights out of test results. We started becoming mindful of the test results and started making quick decisions based on them.

The choice of the right automation testing tool; Some examples of tools:

The tool that you choose for automation should observe an open automation methodology – which lets you integrate your existing toolset/development setup easily. The wider range allowed for integration with different frameworks, tools, and software, which turns out beneficial for the project. For example, TestProject, Tricentis Tosca, etc., lets you integrate with several tools like Jenkins, JIRA, Selenium, and many more. PostMan, SOAPUI tools can be used for API test automation. Some BDD tools I recommend are Cucumber, JDave, etc.

Your QA team cannot always handle the burden of manually creating the tests in less time. With the help of an automation tool, this can be done automatically and quickly as well.

Advantages with shift left testing

• Bugs were found much earlier – Result: reduced costs by detecting and solving bugs earlier.
• Higher code quality; therefore, higher quality product – Once the product was rolled out to the customer, there were fewer instances of code patches, and code fixes required.
• There were fewer chances that the product overshot the planned timeline.
• Increased quality
• Shortened the otherwise long test cycles – the customer was able to get info regarding the health of the project much earlier as they also started getting involved more frequently in feedback.
• Mitigated the surprises at the end of the development cycle or in production. Everyone was aware of the project status.
• The test team became knowledgeable about tooling and technology much earlier.
• Last, but not least, customer satisfaction was much higher as the product was delivered with the utmost quality.

How shift left testing is associated with DevOps

DevOps builds on the base of continuous feedback. With frequent testing, this is exactly what we got. Because of the fact that testers and developers, as well as the rest of the team, were in constant collaboration to make it work, the traditional silos setup was broken. There was an eventual removal of silos between the development and operations. Everyone started collaborating.

Also, it syncs well with the CICD practices, wherein there is continuous testing. We automated the tests and ran them as early as possible, and as often as possible. Apart from that, we also embedded service virtualization to mimic unavailable systems. It also syncs with the continuous deployment concept of CICD. Continuous deployment involves the automation of provisioning and deployment of new builds and hence enabling continuous testing to occur quickly, and in an efficient manner.

Wrap up

Shift left testing holds true to its definition in that it is a practice in SDLC in which the teams focus on the quality, and work on problem prevention rather than focus entirely on detection. The idea of testing earlier almost always gives benefit to the project. Let us keep the test strategy and the culture of the organization healthy and positive. Shift left testing has been amplified to get them both right, leading to a happy client and a happy team.

• « Why Should You Outsource Your WordPress Maintenance Services?
• 5 Essential Features of a Top-Notch Mobile App »