What is Shift Left Testing?
The global movement in testing has become centered around shift left models as more and more companies adopt agile and DevOps practices, which further support microservices architecture. One of the main focuses of shift left strategy is proper utilization of automation, but before we get into that, what is a shift left model? Shift left testing is basically testing ‘early and often’, using tools that can be adopted by developers of the team and provide validation ‘as needed.’ It becomes the focal point in adopting Continuous Integration and Continuous Deployment models. The testing is moved left on the project timeline to reduce project costs of finding and resolving bugs. You start testing early in SDLC so that:
- Defects are found and fixed earlier
- You will have better test coverage
- You’ll have quicker releases with increased confidence
- Quality is the responsibility of the whole team
How does Automation fit into Shift Left?
Now that you know what shift left testing is, how do we get the biggest bang for our buck?? Automation! Traditional automation was mainly focused on GUI and End-to-End tests. The problem with that approach is that it takes way too long to complete execution (opposite goal of fast feedback to dev), and you can’t start automating until you have a “finished” product. The old way is very costly due to the effort it takes to create automated UI scripts, maintenances of flaky tests, and limited test coverage.
With companies adopting agile and DevOps, you cannot wait until the UI is built to automate GUI tests. When you start testing early, you more than likely will not have fully functional UI, but you will have components (unit tests) and an API layer to support integration points with other systems/areas of the enterprise solution. If you focus your automation on those layers first, you will have the majority of critical test coverage automated. In addition, unit and API tests run the quickest, with faster feedback on quality. Reducing UI tests will definitely increase velocity in your sprint, and guess what happens when your velocity is increased? You release more often, with better confidence in product quality. That is the main objective of shift left testing!
Now you’re probably wondering, “I am a QA resource. I can’t write or automate unit tests.” In the shift left model, everyone on the team, including dev and QA, is responsible for testing. The developer can write automated unit tests and leverage tests/criteria from the testers as part of the CI process. The tester can include their automated tests into the test suite and add additional value by applying context-driven manual tests. This alone already shows better test coverage. You also don’t have to wait for a stable UI to automate. It can start left of the project timeline! By executing a combination of automated and manual tests earlier, you will more than likely find defects early on. Uncovering and fixing major bugs early in the cycle is a lot cheaper than finding the bug towards the release date.
Better quality is proven with shift left testing.
Below are some better practices that will help you get started with your shift left strategy:
- Testers define testing scenarios/coverage expectations with checkpoints
- Testers/Developers write unit test, automation test based on test scenarios
- Team Reviews code quality and quality of tests created
- Code is written with testability in mind