A recession seems inevitable because of ongoing energy crisis. The first reaction of many business leaders is to cut costs. A logical reaction but only impactful when considering future trends and innovations. Because of the ongoing digitization, the IT-sector is food for though. Surprisingly (or not?) a Gartner survey found that there will be an increase in IT spending in 2023, making it ‘recession proof’. As IT budgets are being allocated as we speak, you may be interested on how implementing a shift-left testing approach. It can help you tackle the recession and hopefully make your company recession proof.

What is Shift-left?

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.

Why shift-left testing?

Applying a shift-left testing strategy has some obvious advantages:

• For starters, there is the exponentially reduced cost of resolving issues during early life cycle testing. And who doesn’t like that?
• Secondly, the increased efficiency. By relying more on automated testing, you can run/execute more tests in less time.
• Shifting left will also result in higher software quality. If every team member, from the developer to the product owner, adopts a quality mindset, checks will be performed on every deliverable on a regular basis.
• And finally, by building the product right as well as building the right product a competitive advantage will be gained. This due to faster feedback with (constant) user involvement.

How to implement shift-left testing

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.

V-model vs. Agile and DevOps (or should we say, DevQAOps?)

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.

The role of development in a shift-left approach

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.

Test-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.

Behaviour-Driven Development

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.

Tackling the recession with this software testing approach

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.

Written by Catherine Ooms and Joke Gijsbrechts