The words "Shift left" testing strategy gets tossed up from time to time in conversations. So, what is it all about. Let me put things in perspective straight away. Lets assume your Boss comes to you and asks you to demonstrate how you would save costs on a multi-million dollar software project. Would you then, adopt shift left testing strategy?
Would like to review some key aspects of Shift left testing strategy and see if it is indeed cost effective in our Agile world. In this little blog, I am not focusing much on the "How to" fragment, rather am illustrating the "What to" and "When to" part.
We will start by looking at the major phases in the software development life cycle (SDLC) or the product life cycle. Please note this is pertinent to both Agile and Waterfall models.
Below are the key phases in the SDLC:
Let us review how we can shift left during each of the above phases. The first one is the documentation of the requirements. We should be able to ensure that requirements have been comprehensively documented and are aligned to the business needs. Typically the 3 amigos (product owners, development & testing teams) should review the requirements and sign-off ensuring the quality of the requirements is top-notch. Documentation of the Requirements is complete in terms of functional and non-functional aspects. If done right we are doing this First Time Right and are potentially preventing a garbage in and garbage out (GIGO) situation.
Now let us assume that we were not doing this first time right and a significantly high percentage of requirements (epics, features, user stories) were ambiguous in nature. Lets say 50% of the total # of test cases failed and defects were reported in the testing phase. 2 points to be noted pertinent to when in the product life cycle these defects would be unearthed and their cost impact.
1) Defects would be typically discovered late in the product life cycle during or towards the end of testing phase
2) Additional Development effort would have to be accounted for in the budget to fix these new defects, meaning adding to the costs and we have witnessed in most cases dampening the morale of the teams involved. Fixing defects late in the product life cycle in a tightly coupled monolith application would be a bit more challenging and expensive as opposed to fixing defects in an application built using microservices architecture. Nevertheless, a costly affair.
Inference: We should be able to prevent defects, realizing a significantly high number of cost savings by shifting left and testing the requirements upfront for their quality and thereby potentially avoiding a GIGO situation.
The second phase is the technical design phase. One option of shifting left in the design phase is to test all the design artifacts for testability. The testing teams should be reviewing all design artifacts and providing an early feedback to the architects or the design team. Reviewing the design documents religiously as a practice should potentially help avoid ambiguity in the requirements and the chaos that follows later.
Another option is to apply the 5 steps of the design thinking approach as illustrated below:
Using the design thinking approach is a great way to test our designs and get an early feedback preventing potential rework later in the product life cycle.
Inference: So, we looked at no less than 2 options of shift left approach in the design phase. Implementing either of them would save us potential rework and effectively save costs for the org.
Moving on to the Development phase of the product life cycle.
What percentage of API tests vs GUI tests can be conducted during the development phase? I would presume a significantly high percentage of API tests should be targeted to be tested as early as possible, well before the GUI is even made available.
If there are no dependencies configured in the testing environment how would we test and automate? The use of Service virtualization (SV) is one of the approaches and one of the answers to the above question.
Using service virtualization, API tests based on rest end points or any other protocols can be created. A restful virtual service can be created and in due course we should be able to run the API tests against the virtual service and verify that the responses from the virtual service are as expected. API tests can also be automated using the SV.
While developers are building their application code leveraging the service virtualization, unit automated tests can be written parallelly to ensure 100% code coverage is achieved. A Test driven development (TDD) approach can be used to write unit automated tests as and when the code for the features is being added into the codebase. The TDD approach ensures we have proactively tested all our code via unit automated tests since TDD focusses on creating tests for each functionality right from the beginning. Unit automated tests can be incorporated as a Quality Gate within the Continuous Integration (CI) pipeline.
Security testing can be established as one of the Quality Gates within the Continuous Integration (CI) pipeline to run the Static Application Security Testing (SAST). This is a great way to find vulnerabilities earlier in the product life cycle and therefore fixing these will be less expensive.
Service virtualization (SV) also enables the performance testing teams to conduct load tests earlier in the cycle without having to depend on the availability of the 3rd party components all the time. Most 3rd party components come with a cost for their usage. Once we have configured the 3rd party component or the API via the SV and recorded the requests/responses, the components can be decoupled and testing can still be continued.
Parallelly as the GUI is being built early, leveraging the service virtualization software, functional automated tests can also be written by the testing teams a little earlier in the development cycle. Eventually we would want to have functional automated testing established as one of the Quality Gates within the Continuous Delivery (CD) pipeline.
Inference: All the above approaches should act as strong enablers to accelerate the Shift left testing strategy and effectively result in faster releases to the market and enhanced customer satisfaction.
Moving on to the Testing phase of the product life cycle.
Now that all the activities have been executed as part of shift left approach in the requirements/design/development phases, in the testing phase the testing teams should be able to focus on just polishing their functional automated tests . Most of the functional automated tests would have been built in the development phase giving them a headway and time to focus on executing the test scripts, debugging, fixing their scripts or logging defects as the case may be during the testing phase.
Adopting shift left testing practices along with Pair programming or extreme programming would be a great approach but as we all know it requires an organization to adopt these as part of their culture to reap the benefits.
Inference: Shift left testing strategy does ensure testing teams have enough time on their hand during the testing phase to be more focused than before on creating innovative solutions. The morale of the teams is maintained high 😃adding to the productivity gains.
Final Verdict: Finding defects is good, however finding them as early as possible in the SDLC is what testing teams should focus on. Shift left is an approach that is an enabler and potentially creates opportunities to find defects earlier. It is less complex and less expensive to fix defects when discovered early.
Author
Prashant Gopawar is an IT industry leader who offers more than 20 years of experience in software testing and development space. He has garnered experience working with some of the Fortune 500 technology companies across the globe and loves to contribute and share knowledge in the testing space.
Feel free to connect: http://www.linkedin.com/in/prashanthkgopawar
