Shift Left — An approach towards Continuous Quality Improvement

A majority of the software development teams across the world are adopting Agile methodologies to manage changing requirements. As the stats suggest, Agile projects are 28% more successful than those following traditional methods. Although being agile is the right way to go, the innumerable pressures on the software development and delivery teams make it incredibly hard for them to deliver products on time and according to the defined specifications. Agile helps us to prioritize and focus on the right things at the right time, but projects are still late and prone to bugs. Testing continues to plague modern development methods irrespective of how agile the teams are. The solution is simple.

The key to delivering high-quality agile products to the market, on time every time is to test early, test often, and test continuously. If testing is done at the fag end of the software development cycle, the risk of a critical bug occurrence is very high, the cost/effort and time required to fix this bug is very high, the chances that you fail to deliver your product on time with the desired quality is also very high. To avoid these and to cater to our clients in the best possible manner, we need to involve the QA right from the design phase of the software life cycle, which is literally shifting the QA practice to the left.

Shifting Testing to the Left isn’t new!

Shift left is not a new practice. In the 1950s programmers realized it was better to test earlier. In those days there was no separate testing team and the developers had to raise questions themselves in order to build a relatively fault-free code. Questioning and coding happened simultaneously and all throughout the project. So the idea of having to test early was forgotten over the years due to the increasing timeline pressure and demands of the clients. The Shift left phrase has given life and relevance to an old and proven strategy.

Why has the Shift Left strategy gained momentum?

The realization of the impact of keeping the ‘Testing Phase’ at the extreme right of the Software Development Life-cycle happened because the cost/effort of identifying and fixing bugs identified towards the later stages is very high. There were many cases where, after investing a huge amount of effort on building software, because of certain crucial bugs identified at the end of the cycle, the software couldn’t be released. In other cases, the software was even decided to be scrapped without even considering a delayed-release as the bugs found were too much trouble to fix resulting in a total loss of all efforts and money put in since inception.

How does the Shift Left Approach work?

Shift-left is an approach where testers are involved almost in all the stages right from the requirement gathering till delivery. It is a technique of continuous testing of not just the software but the requirements and design before the program is built. In this methodology, the testers interact with different stakeholders, which include developers, project managers, business analysts, API developers, database engineers, UX designers, and obviously the clients too. When involved early, the testers get time to understand the requirements, proposed design, architecture, coding, and eventually its functionality rather than going from the requirements to directly test the functionality. The testers in this mode are engaged in every meeting and are expected to raise questions and ideas keeping the eventual product and the end-user in mind. The testers add testerly value by analyzing and possibly querying every move made and thereby laying the path leading to much better software before the software even exists.

Why should we opt for Shift Left?

• Cost-effective

The sooner you detect the bugs in your code, the lesser it costs to rectify them. The ideology of the Shift Left Strategy is to test small parts of the software as early as possible. This process aims to prevent a defect from occurring rather than detecting a bug and fixing it. By implementing this, the number of functional issues in the build delivered to QA would be far fewer, hence saving a lot of costs. Testers would be carrying out static testing well in advance to be in a position to deliver a report on the project documents that would help eradicate defects from being ingrained in the software and later widening their impact on the software as more code gets built-in.

• Optimization of time and efforts

The Shift Left approach demands more from the testers and that’s great. Usually, testers wait a lot. Once the requirement analysis is done and the test cases are built, the tester in a traditional model has nothing more to do until the developers deliver a build. Whereas in the shift left approach, a tester’s responsibility increases multifold. QA gets involved in the design review meetings, suggests design flaws from the QA standpoint, provides alternate suggestions, and create test scenarios to break the design when the application is built, leading to better designs. If there is an API and if the tester has some technical leaning, he can write some basic checks and test them very early in the development cycle. In this way, any API issues that are found would be fixed and the service, when deployed, would be up and running right from the get-go. In the same way, we can also do data testing by observing the code, wherein we can check the data length and format, validation, mandatory field checks, and character types allowed. This leaves us with just testing the workflows and the UI when the final product is delivered to QA hence reducing the QA cycle time.

In the Shift Left approach, QA should be adept enough to deliver a robust list of test scenarios while the code is still in development. This helps the developer to address all the real-time scenarios noted by QA and provide better quality software. It can be observed how the shift left strategy slowly brings in BDD and TDD practices inadvertently.

• Developer and Tester collaboration

The shift left testing strategy amplifies the responsibility of the developers too. Since the test scenarios are delivered upfront and different parts of testing were done during the coding phase, it is on the developer to make sure that the build when delivered to QA is free of the basic issues that might occur if Shift Left hadn’t been followed. Shift Left also improves the camaraderie between the developer and the tester as they help each to make sure there are fewer bugs later on. This subsequently reduces the friction between the two factions.

• Improve Delivery Performance and never compromise on Quality

Since there are fewer bugs to fix and retest, the delivery can be done on time or even sooner than promised. Quality is improved without compromises on the delivery timelines. Testers become more adept and involved than in any other process and in fact, this silently encourages them to perform even better. Properly encouraged testers mean a better quality product. Shift left is a win-win for everybody involved even to the customer. It saves a lot of time in the later phases. The time cushion can be productively used in implementing features that otherwise would not have been implemented, or to improve the customer experience, especially tweaking the UX/UI of the software.

• Helps to do all of your Testing through Automation

Since a good chunk of testing was performed before the software is delivered to QA, testers find so much more time to automate functionalities when they are delivered. Once the workflows are automated by the QA and the deployment process is automated by DevOps, think of the effort and time you will be saving.

Shift Left Approach — Graphical Analysis with Statistics:

When are most bugs introduced into the system?

It is obvious that most of the bugs in the software are introduced during the coding phase as illustrated in the below graph designed by Capers Jones, an American Software Engineer who was a visionary for his analysis of methodologies used in the software field.

These bugs could be logical issues with the code, misunderstanding of the requirements, or maybe the developer did not think of the consequence the code might have on another related piece of the program already written or is about to be written. Further issues are introduced when the pieces of programs are integrated with other systems, or with APIs.

When are those bugs found?

Notice that this graph is basically an inverse of the one above. It is expected because, in traditional approaches, the bug count rises when the testing is done and that is after the coding phase when the build is delivered to QA. So almost 90% of the bugs are introduced during the coding phase but none are identified.

The cost of fixing these bugs:

A bug found and fixed during the unit testing phase is 4x costlier when compared to when the same is done during the coding phase. The same bug when found and fixed in the functional testing phase becomes 10x costlier and during the system testing phase shows a nasty rise of 40x costlier when compared to the coding phase. In the post-production deployment phase, the cost rises to an unimaginable 640x.

There are specific and proven reasons to justify these exponential rises in costs:

• During the later stages, when the entire software is built, it takes so much more to narrow down as to which part of the program is the actual trouble maker. The more complex the failing test case is, the harder it is to find the root cause and fix it.
• Several dependent systems like databases and APIs are integrated with the code and it is difficult to reproduce issues. It could be weeks between defect detection and defect remediation at this stage.
• The impact of the change could be disastrous if the bug found is a critical issue. For eg: If you have built a code that isn’t scalable enough or crashes after reaching a particular load, whereas the client’s requirements are for the application to handle 10x more load than that, then you are doomed.

Test Early, Test Often, Test Continuously:

Observe the below graph which describes the impact of the shift left strategy on the percentage of defects found and when they are found. This subsequently reduces the cost of fixing and retesting the issue.

How to Achieve Shift Left Successfully?

Make sure you follow the industry recommended and proven testing pyramid where more focus is put on building unit tests, API tests as shown by the below figure. The other figure shows the ice cream cone concept which is the traditional manner in which testing proceeds, with minimal effort during the unit testing stages and maximum effort put in during the GUI testing. Emphasis should be on melting this ice cream cone and implementing the ideal testing pyramid for optimization of effort and cost.

• Use service virtualization to allow automated API tests to be implemented earlier in the cycle. Pushing API tests to the left is critical to understand the performance and architecture soundness of the system.
• Make the best use of change impact analysis to accurately decipher the changes and risks introduced with each new iteration. They provide the key in deciding where the testing should be in that specific iteration. Development and testing teams need to be focussing on a minimum set of tests for each iteration in order to truly bring back agile development methods.
• Minimize late in the cycle fragile UI based testing as much as possible and establish early in the cycle automated unit tests.

Shift left might be a dramatic and difficult change to implement. But once it is implemented, the results are there to be seen. It is a few small shifts to the left but one big leap of transformation for your organization and the products you deliver to the market.

Author: Aswathy R & Mohan Bharathi
Stream: QA