Shift left is so much more than writing unit tests

Lots of companies are still struggling with the shift-left principle. For most of them, it is all about testing a bit earlier in the process by forcing their developers to write unit tests... but is it?

Shifting left is the process of moving quality activities earlier in the software delivery process. That way you catch defects and issues earlier and reduce the risk of problems later on. Many organizations focus their shift-left efforts on testing earlier in the lifecycle. However, I believe that shifting left is not just the responsibility of testers. Contrary, it concerns everyone involved in the software delivery process.

Traditionally, quality and testing activities came down to testing at the end of, or even after, the development activities. Statistics show that the later defects are found, the more expensive they are to fix. Shifting left can lead to a more efficient and effective software delivery process, getting higher quality products to customers at a higher pace.

So why is it not just the tester's responsibility to shift left?

By focusing solely on executing tests earlier, we are missing a number of opportunities to find issues earlier.

For example, a business analyst can challenge requirements and propose solutions before any code is written.

When a process has been designed, you can dry-run this with actual end users: Just use Post-Its to pass information or actions from one department to another and play the process as if you would be using applications. All this without writing one line of code. If you can find an issue in your process at that moment, you might have saved weeks of development/test/bug fixing time. (as an added bonus, the involved end-users already have an idea of the changes coming to them)

Similarly, techniques like Behavior Driven Development (BDD), example mapping and design critiques might support business users, analysts and developers to make sure that the code that will be written actually fulfills customers’ needs.

Obviously, developers help shifting left by writing unit tests during (preferably before) development and performing Test Driven Development (TDD). But don’t get overly excited about code coverage percentages, they only say so much. By the way, did you know that you can actually verify the quality of your unit tests by means of mutation testing?

Other shift left opportunities that are easily overlooked include user experience (user research, design thinking, usability testing, prototyping), shift left on security (Static Application Security Testing (SAST), OWASP Dependency-Check, threat modeling, etc.), early identification of non-functional requirements. (Quality attribute scenarios, ISO 25010).
Going into depth on all those topics would lead us too far, but I hope to have awakened your curiosity on those topics.

Reflecting on this, you might discover that there is so much more to shift left than just test automation:

• user research

• requirements gathering (don’t forget the non-functionals)

• specification (BDD, example mapping, design critiques)

• end-user involvement in early dry-runs

• Test Driven Development

• Code scanning (security, but also coding standards)

In conclusion?

In conclusion, shifting left is not just the responsibility of testers and quality engineers. By working together and contributing to shifting left, we can create a more efficient and effective development process. This, in turn, helps us to bring higher quality products to our customers.

Whether you are an architect, analyst, developer, tester, or any other member of the team, you should challenge yourself in finding some activities to “shift left” and help to ensure the success of the project.

Do you agree & feel inspired to get better as an analyst? If you’re an ambitious analyst and are looking to broaden your skillset even more, then maybe our Boost Your Analysis Skills learning track is right up your alley. Registrations are open today and new groups are starting their journey in October 2023.