Nerd For Tech
Published in

Nerd For Tech

How to implement a “Shift Left” test strategy

In recent years, we have all heard much about ‘Left shift testing.’ But is it a thing or simply an exquisite terminology of consulting? Some believe it works exclusively for smaller teams. Can this technique be implemented by huge organizations where individual teams do several projects? Well, in this post we will discover out.

Shift Left Testing

When you see the typical delivery paradigm of software, it is left to right. Testing is done after building the functionality, which is more costly to fix and delayed feedback. Well, what’s new about this, you could ask me? We all know that our apps must be tested early to minimize issues in later phases that might be costly to resolve. But is the test-taking place reasonably early in typical QA teams? Most of the answer is no. Let me clarify the reasons behind this and how we are going to approach it.

Why Shift left?

We should thus begin to identify some of our QA teams’ key problems.

  1. There is not enough time for testing — the features are provided late and generally after the sprint for the development teams and this does not offer a lot of time to test QA. They have to sign the tales since they are considered to be bottlenecks that delay their implementation once DEV is finished.
  2. Quality is only the issue of QA! — When the terms ‘test’ and ‘quality’ are heard, people glance at the QA teams immediately. As if quality assurance is the only duty of test testers, and everyone in the team is permitted to do anything they please.
  3. Automated testing needs a lot of effort and upkeep — UI automated testing (much of which uses selenium) takes a long time to build. Not to forget the irritating failures we have all seen since the page load times are somewhat delayed and certain expected activities take place late outside the defined limits.

We understood thus that we needed a simple technique, Shift Left Testing, to solve these problems with a perfect solution. Here’s how each of these difficulties will be solved.

  1. There is not enough time for testing — We should ask the development team to construct the UI prototypes using dummy data for new functionalities in this scenario. This offers an early glimpse of the functionality without needing to be completely integrated and created for the Product Owner and BA. This was great since if Product Owners change mind or if the feature was created improperly, it would decrease the wastage. Instead of waiting for the completely constructed application, we may ask the QA team to start automating the user testing with this prototype environment. The QA team was able to fine-tune the paths depending on the acceptance criteria, even though the backend was entirely mocked. At this point, there was no dependence on the connection of APIs or databases. Similarly, we may ask another tester to cooperate closely with the API developer and give the request and answer templates for the feature API built. According to the acceptance criteria, the tester would construct automated tests using these templates, even if the API has not yet been completed. With little adjustments, test scripts may be completely run against the application in the CI pipeline when the API and the UI are developed and delivered to the testing environment. Even before the stories are sent to the QA team, automatic regression test packs are generated! This decreased the turnaround time of the QA team substantially to test the features early and sufficiently.
  2. There is not enough time for testing — I really feel that everybody’s concern is quality. Don’t we want to accomplish the best, whatever we do? Why would we let it be confirmed by the tester that what we have developed is good just for software? I want to include the culture of developers who have also acquired quality for their own work. If The QA team were using a different language for automation than developers using. However, all our developers are full-stack JavaScript developers. There was hesitancy within the DEV team to adapt to any other language other than what they are comfortable with. It’s a good move to change our code base language.

Can we succeed in the “Shift left testing” dream?

Yes, With some of the following guidelines we should implement the Test Strategy.

  1. Developers should do automated regression testing on the features of their local machines. The testing on the ground is fairly straightforward since the normal “npm test” has to be done and the tests have to be boomed. Only after the tests pass, you may examine the repo code. If the tests fail, they can examine and, if needed, take measures to update them.
  2. For each repo code check-in, CI/CD pipeline was built up to conduct E2E unit, integration, and health testing. The build will be deployed only after all the tests are done in the main Integration test environment. If tests fail, the team will receive automatic notifications for action.
  3. In the integration test environment, the UI and API tests defined by the testers for the newly implemented functions are automatically performed during scheduled test runs.
  4. Different test environments including the pre-production environment are utilized for the same automated testing.

With that method, our apps should be tested extremely early and in greater depth and the number of deficiencies leaking at later times should be reduced. There have been significantly low production faults while developing and delivering speeds have been improved. Certainly, we do need to improve in certain areas but the ‘Left Shift’ strategy has brought us a significant stride ahead.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store