From Theory to Impact: Implementing Shift-Left from Scratch

Shift-left, do you know what it is? After help my team implement this methodology from scratch, I've decided to write about what is the methodology, the benefits and practices that were essential for this methodology to work and improve not only the product we were working on, but our daily lives as QA and developers.

Introduction to Shift-left testing

Shift-left testing is an approach in software development that emphasizes moving testing activities earlier in the development process for improved software quality, better test coverage, continuous feedback and a faster time to market.

This practice have a lot of benefits, like:

• Cost Savings: Early detection of defects through automated unit tests is cheaper than fixing issues that reach customer environments.
• Increased Efficiency: Continuous testing leads to quicker issue resolution and a smoother development cycle.
• Early Bug Detection: Finding bugs early in development minimizes costs and effort.
• Faster Development: Testing alongside development reduces delays from last-minute fixes.
• Developer Wellbeing: Effective automated testing and Continuous Integration (CI) give developers confidence to deploy frequently, reducing stress and making error resolution faster.
• Resilient Architecture: Prioritizing testability leads to better software design and easier maintenance.
• Greater Overall Quality: Enhances customer experience by reducing incidents and improving software health through continuous feedback.
• Better Collaboration: Encourages communication between developers and testers from the start.

But as not everything is perfect, this methodology has some limitations:

• Increased Initial Investment: Requires significant upfront costs for tools and training, which may be a barrier for some organizations.
• Quality of Automated Tests: Over-reliance on automation can lead to issues if tests are not well-designed, resulting in false positives or negatives.
• Limited Scope: Focuses on early detection but may overlook aspects like usability and accessibility, which need different testing methods.
• Resource Intensive: Continuous testing can demand significant resources, including skilled personnel and infrastructure, which may not be feasible for all teams.
• Code Audits: Code auditing is essential before implementing shift-left processes. Regular code audits during software development help ensure quality; if done poorly, they can hinder the smooth execution of code testing and ultimately impact overall software quality.
• Difficulty in Managing Test Data: Creating and maintaining relevant test data can be challenging, impacting test effectiveness.

Context

For security reasons, I won't give details of how the process was before or after this methodology in the company I work for, but I will use the traditional software development model as an example.

If we look at the traditional software development model, we can see that the testing starts in the very end or the the extreme right of the pipeline:

As we can see, at this moment, the QA will only be validating what was developed, in the end of the process. And there's some problems with this practice:

• Excessive regressions - How is needed to make sure the stability of the system, each deploy in the test environment, demands one regression, even with automated tests, it will take time.
• If there's one critical bug, all the work will be blocked to be deployed => impact directly final users
• Difficult debug bugs and issues - How we deployed a complete feature, if a bug appears, debug it will cost more time for the developers, because it could be added in any one of the features of the package.

As you can see, a process without shift-left testing have a lot a problems in a long term for projects that pass through a lot of changes.

Is important to mention, sometimes, have only the test phase on the end of the complete development, can be enough for projects with close scope or with few changes

How start to implement shift-left

The main goal of shift-left testing is have the test phase starts early in the development and there's some actions that can me made to help it. Probably you already know the test pyramid:

The Test Pyramid is a software engineering concept that proposes a balanced distribution of the different types of automated tests in a system. The idea is to maximize test efficiency, minimizing maintenance costs and execution time.

Understanding the test pyramid, in the shift-left we abuse this concept.
How we want earlier results, unit, integration and E2E testing will be a big ally on it.

In addition, I wanted to talk about other points that I think are extremely important when we implement this methodology and they made the difference for my team.

INVEST method

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story Basically, it says that one user story should be:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable (or vertical)
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

Use this acronym when writing or breaking us, it is essential for shift-left. With it, we can visualize and deliver value easily and quickly, and the main thing in my opinion: reduce retesting.

If we look to the criteria without INVEST, we can see that this statement:

• May depend on security, authentication, validation, etc.
• Is very vague. ‘secure password resets’ can mean many things.
• Don't have enough details to estimate.
• May involve multiple components (token, backend, UI).
• No clear criteria: how do you know if it's ‘secure’?

Use invest help to understand more about the feature and define the possible tests that will be needed, avoiding redundancies, guesswork during development and frustrated expectations.

CI/CD - Continuos integration and Continuos deploy

CI/CD helps organizations avoid bugs and code failures while maintaining a continuous cycle of software development and updates. As apps grow larger, features of CI/CD can help decrease complexity, increase efficiency, and streamline workflows.

You can read more about CI/CD here.

Clear communication

For me, this is the BIG and most important change to have this methodology working correctly.
This process brings the ones that are responsible to the testing close to the ones responsible to the development, is a good opportunity to discuss improvements, future implementations and prioritization.
In my context, I think this was the most important feature in making this methodology work. Being closer to the developers during development helped me understand more about the product and foresee possible risks depending on the modifications that would be included. As well as helping them to understand what is expected of QAs, how what they do affects the quality of the product as a whole, not just what they are involved in.

Conclusion

As we can see, shift-left is a good practice, but having automated tests alone is not enough to make it work. I confess that during the time I spent with the team implementing this, I realized that the way we write what we're going to do, the infrastructure we have and, most importantly, our communication as a team are essential if we're to deliver things continuously and with quality, without our lives as developers being overburdened by too many bugs or excessive retesting. 

That's it for now. If you've made it to the end of this article/report, let me know if you already use or have used this methodology and the challenges you've had with it.

Sources used

• Shift Left Testing: What it Means and Why it Matters
• What is INVEST?
• What is CI/CD?