Shift Left Testing: Stop 3x More Bugs From Reaching Production

According to research done by IBM, a bug found in production will cost your team 6 times more to fix now than if you'd caught it during design.

But it gets worse.

Teams typically burn 20-40% of their time fixing features in production. That’s time you could spend building new features. And if you're thinking, "That's just how software development works," then you probably don’t practice shift left testing.

Shifting left testing involves moving testing from post-development to pre-development, with the goal of preventing bugs before they occur. This means spending less time fixing bugs and more time building new features.

Here’s what we’ll cover:

1. Understanding Shift Left Testing
2. Shift Left Testing vs TDD - Why they're not the same thing
3. Benefits of Shift Left Testing
4. Start with Small Automation - How to begin even with little experience

Understanding Shift Left Testing

Traditional testing is what keeps your team up at night, fixing bugs in production.

The team builds a feature, sends it to QA for testing, and releases it to production. Doesn’t sound so bad. Problem is the QA team can’t sniff out every bug, it’s humanly impossible. The solution is to start testing as the feature is being developed.

Let’s see what that could look like in an actual project. Let’s assume we want to build an authentication system for an e-commerce application. Rather than build it and then send it to QA, the QA team gets involved starting from the requirement phase. In the requirements meeting, they could ask questions like:

• How will we handle email deliverability for getting OTPs?
• What validation rules do we need for registration?
• Who would we prevent brute force attacks?

This way, developers start coding with validating input sanitization or running security scans on auth endpoints as they build the feature. Issues are caught earlier in development, and bugs that slip into production are drastically reduced!

This is shift left testing. It’s about taking testing initiatives from the moment requirements are created.

Difference Between Shift Left Testing & TDD

If you’re familiar with test-driven development, you might wonder, “Isn’t shift-left testing the same as TDD?” They both encourage testing before development.

TDD and Shift-Left Testing are similar, the difference is in their scope. While TDD is driven by developers and focused on unit testing, Shift-Left Testing has a broader scope that spans the entire development lifecycle, from requirement to release. In essence, TDD is a subset of shift-left testing.

With Shift left testing, you're catching potential issues in design documents, reviewing requirements, or integration complications, all before they become expensive fixes. You don't even need coding skills to practice shift left testing.

So, while TDD is to developers, shift left testing is to the entire team. And while TDD is to unit testing, shift left testing is to the entire project scope.

Let the developers handle TDD as part of your broader shift left strategy.

Benefits of Shift Left Testing

Using shift left testing to prevent bugs from ever happening means less time fixing them, saving time and resources. Catching bugs earlier also has other positive side effects. Some of them include:

Fast Development Velocity: Since testers don’t have to wait for developers to finish building a feature to begin working, software release becomes much faster. Developers, testers, and DevOps can work in parallel, which means fewer last-minute deployment blocks and faster product growth.

Improved Code Quality: When testing starts with requirements, developers write more testable code. They're not rushing to patch security holes or fix validation issues at the last minute. Quality gets built in.

Stable Releases: By catching issues much earlier in development, there’ll be fewer bugs in production, which means fewer forced emergency deployments on a Friday afternoon.

Shift-left testing has many benefits, and it can be tempting to implement it everywhere, testing every nitty-gritty, especially with powerful automation tools at your disposal. However, this can be dangerous, as you might spend time automating tests that could break easily.

S,o when implementing shift test testing, you’re better off starting small.

Start with Small Automation

Attempting to implement shift-left testing by automating everything at once will cost you time and create more problems than it solves. Instead, start small.

If you're comfortable with code, start with basic functional tests. A simple login test using Selenium or an API health check with Postman will give you more value than complex end-to-end scenarios. Add these to your CI pipeline using Jenkins or GitLab CI - both have extensive documentation to get you started.

If you’re not a coder, that’s fine, too. You can use no-code automation tools like MagicPod, which enable you to record interactions with UI interfaces, create a test script, and self-heal when you make changes. This way, you spend less time on test maintenance.

Remember, automation isn't the goal, catching issues early in your SDLC is. Start small, focus on critical paths, and expand your automation gradually.

References

1. IBM System Science Institute Relative Cost of Fixing Defects
2. DevOps Shift Left Testing: A Detailed Guide
3. Shift Left Testing Approach and its Benefits | Ultimate Guide
4. Best Practices For QA Testing