Shift-left is a software testing approach. The term shift-left first appeared in 2001. This because the traditional waterfall model for developing and delivering IT projects was no longer adequate. The emphasis on quality during the software development life cycle has shifted from ‘late stage‘ testing activities to ‘as early and frequently as possible’. So, testing was shifted left on the project’s timeline. As a result, the quality of IT projects is now the responsibility of all team members and not just testers. Because of this shift, there is a greater need for automated testing, more focused and thorough manual testing, and higher overall quality.
Applying a shift-left testing strategy has some obvious advantages:
Choosing the right approach to implement a shift-left strategy that works for your development life cycle is of the upmost importance. Brightest has a lot of experience in checking if you are ready to implement it. Besides that, we identify the key ingredients to make it stick long-term. We use our BrightScan (QA assessment and maturity scan) to analyse your whole IT process and influencing factors in your environment in a holistic way. Read more about this here.
In a traditional V-model development approach, testing happens at the end of the development phase, when all development is finished. While in Agile and DevOps environments we need to build and deliver high-quality applications and features, rapidly and consistently. This means testing needs to increase in speed and happens within the development iterations.
So, do we skip certain testing phases of the V-model approach within Agile? No, all these testing phases are still (or should still be) done within an Agile development approach. But on a much smaller scale, within each and every iteration.
Both the dynamic and static testing phases are important in any testing approach. Static testing means that testers manually review the requirements (user stories/documentation). Developers automatically analyse the development code with specialized tooling. Dynamic testing is any form of testing phase done while executing the system under test, e.g. functional system testing or E2E regression testing.
Shift-left can be realized by involving the right stakeholders (e.g. key users) as early as possible during both these static and dynamic testing phases. And by implementing all testing layers of the testing trophy. Which includes an increased focus on automated testing, such as e.g. unit, unit integration and system integration (API) testing.
A big step for shift-left is when developers implement the right testing strategies for unit testing. E.g. by applying Test-Driven Development; or even a more advanced Behaviour-Driven Development.
Within TDD, the developers first write the automated (unit) test script(s) before writing the code. They keep adjusting and running the code against these test script(s) until the script(s) get a status ‘passed or green’. This results in cleaner (and only the most necessary) code, increased stability and less issues in next testing phases. The focus with TDD is on how functionality is implemented.
Within BDD, the behaviour of a system is defined by the end user in plain English within the requirements. This gets converted into automated BDD test scripts. Developers write their code, which runs against these automated BDD test scripts. They will keep adjusting and running the code against these test script(s) until the script(s) get a status ‘passed or green’. The focus with BDD is on the behaviour of an application for the end-user.
Call it ‘kicking in an open door’ but fixing bugs late in the software development lifecycle often costs a lot more to fix. This compared to fixing them during the requirements or design phase. Obviously the four why’s of implementing this approach is the answer to how to tackle this recession. Costs will be reduced because of increased efficiency and the superior software quality assures you a competitive advantage.
Implementing a shift-left approach/strategy was always a good idea but in the current economic ‘though waters’ it could make a difference between keeping course or sinking the boat.