Have you ever experienced a software project that ran out of budget or time? You probably did. Believe it or not, incorrect planning often isn’t the root cause of a project running out of time. The real problem lies in the way the project validates the code.
In other words, it all boils down to software testing. Or, more specifically, to software testing that is done too late in the project’s lifetime, and not frequently enough. Shift left testing is a proposed solution to this problem.
The “shift left” testing movement is about pushing testing toward the early stages of software development. By testing early and often, a project can reduce the number of bugs and increase the quality of the code. The goal is to not find any critical bugs during the deployment phase that require code patching.
This article explains the concepts of shift left testing and how you can adopt the approach in your organization.
Did I get your attention? Let’s explore how we can achieve zero bugs during the deployment phase.
Expand Your Test Coverage
What Is the Idea of Shifting Left?
The shift left movement is about moving the testing phase earlier in the software development life cycle—shifting left. We want to avoid approaches where testing is only carried out at the end of the software development life cycle. With shifting left, we introduce testing in the early stages of software development.
Up until the late 1990s, a typical software development process is sequential. Here, stakeholders spend attention to detail and favor quality only at the latest phases of the software development lifecycle. More specifically, the testing and deployment phases. Within this sequential model, testing happens towards the end of the project’s lifetime.
However, software developers or product owners often found problems that weren’t covered by tests. It’s very costly and time-consuming to fix such bugs at a late stage. Worst case, developers have to redesign the application.
Here, the idea of shift left testing originated to involve the testing team as early as possible in the software development process.
Why Is It Called A Shift To The Left?
We’re about to explore the relationship between the shift left testing movement and agile software development. However, before going there, let’s talk some etymology. As you’ve seen, shift left testing essentially means “test often, and start as early as possible.” But why is it called “left”, though?
Well, that’s probably a side-effect of the fact that, in English, and most western languages, we read from left to right. So, if we are to represent sequential phases of any kind, the earliest phase will be at the extreme left, and we’ll progress from that. For instance, the phases in the waterfall methodology can be represented as follows:
Requirements →
Design →
Implementation →
Verification →
Maintenance
As you can see, the Verification phase—which would typically contain the testing activities—is the second-to-last one.Shifting Left and Agile
Often, we find the term “shift left testing” in agile is all about small code increments.
The agile methodology includes testing as an integral part of the shorter development cycle. Therefore, shift left testing fits nicely into the agile idea. The testing engineer has to perform testing after each code increment—often referred to as a two-week sprint.
Some organizations like to push shift left testing even further toward the coding phase. A good approach to adopt is test-driven development (TDD). Test-driven development requires you to first write the tests for the piece of code you want to develop. Therefore, you can immediately verify the validity of your code.
Another way of pushing testing further left includes the use of static analysis tools. A static analysis tool helps to identify problems with parameter types or incorrect usage of interfaces.
For example, ESLint is a very well known static code checker—or linter—within the Node.js community that shows your mistakes while coding.
Furthermore, testing experts believe that behavior-driven development (BDD) can accelerate the shift left movement. BDD defines a common design language that can be understood by all stakeholders, such as product owners, testing engineers, and developers. Therefore, it enables all involved stakeholders to simultaneously work on the same product feature, accelerating the team’s agility.
In other words, BDD stimulates cross-team collaboration while improving feature-delivery time.
Next, let me show you why it’s so important to test early and frequently.
Importance of Early Testing
We often underestimate the effects of testing early on in the software development life cycle as the agile methodology describes. Regularly testing code with each code increment helps to guarantee the quality of the project but also saves you a lot of time and money.
It’s important to first understand when bugs enter the code.
When Are Most Bugs Introduced in the Code?
It’s hard to pinpoint exactly, but roughly 85% of the code defects are introduced during the coding phase. In case your organization believes testing comes after the coding phase, many defects will be found during the testing phase.
Therefore, this means a lot of bugs have to be fixed. With “fixed,” I’m referring to patching, as it’s almost impossible to properly solve all these bugs at once. With this statement, I want to show you the importance of introducing testing as early as possible in the software development cycle.
When an organization believes testing should only happen after the development phase, a lot of time—and money—will have to be invested in stabilizing the product. It’s a frustrating experience that often leaves your product full of patches. This isn’t an ideal boilerplate for future code expansions or service additions.
Added to that, the cost of finding a bug also varies at which stage of the software development cycle the bug pops up. Numbers may vary, but on average, the cost is five to 10 times higher when finding a bug during system testing or even higher during the actual release of a product. Besides the higher cost, you’ll likely find unhappy customers.
Let’s summarize the above points in the benefits section.
Benefits of Shift Left Testing
So, what are the benefits of shift left testing?
- Find bugs early on in the software development life cycle
- Reduce the cost of solving bugs by detecting them early on
- Gain a higher-quality product as the code contains fewer patches and code fixes
- Have fewer chances that the product overshoots the estimated timeline
- Provide higher customer satisfaction as the code is stable and delivered within the budget
- Maintain higher-quality codebase
Another great benefit of shift left testing is the ability to use test automation tools. As we want to test early and often, test automation helps you accomplish this goal. We don’t want to overload our testing team with manually testing every new feature the development team introduces.
Therefore, a test automation tool can give quicker feedback regarding the stability of the new code. Furthermore, a test automation tool helps your team shift left. Your team can write tests faster and it becomes easier to maintain them using a test automation tool.
For example, Testim offers a solution to codelessly record tests via UI interactions.
As you can see, these are some strong benefits related to shift left testing. It’s safe to say these benefits apply as well to the agile methodology.
How to Get Started With Shift Left Testing
Let’s find out what your organization can do to get started with shift left testing.
Step #1: Coding Standards
First of all, your development team needs to agree on the same coding standards. All developers must be on the same page. It helps them to review code quicker but also guarantees a higher quality of code.
In short, coding standards should decrease the number of bugs as the standards avoid bad or insecure code.
Step #2: Implement Testing in Early Stages of Development
As a team, find out which tools might be relevant for your codebase. I definitely recommend using a static code analyzer like ESLint, which helps to detect bad coding practices and bugs while you’re developing.
Besides that, the team should think about how they want to integrate testing in the early stages of the software development life cycle. A possible strategy is to adopt the agile methodology, which works with small code increments also called sprints.
Next, each sprint includes a development and testing phase. This makes sure that every small feature gets covered with relevant tests.
For some organizations, it’s not possible to make a drastic switch toward the agile methodology. Therefore, the development team can agree on writing unit tests for each feature they develop. This allows them to have confidence in the business logic they write.
In later stages, the development team should write integration tests to make sure that all these units of code nicely integrate.
Step #3: Embrace Test Automation
As shift left testing involves frequent testing, the development team should embrace test automation tools. Besides automating the deployment of new builds, running tests for each code increment should be automated as well.
This will reduce the pressure on the testing team and provides quicker feedback about the stability of the code.
In general, test automation will speed up the development life cycle and allows you to reduce the time to market. Besides that, it ensures fewer bugs will be found later on in the software development life cycle.
If you’re still unsure about why you should invest in test automation, read this great guide created by Testim.
What Changes After You Shift To The Left?
In practice, what does life look like after your organization adopts shift left testing? What are some changes you’re likely to see? That’s what we’ll cover in this section.
Less Waiting In Testing Activities
As a rule, after shifting to the left, you’re expected to have less waiting related to testing activities. It makes sense, right? In traditional, non-agile settings, testers have to wait until developers are finished implementing their features to be able to commence the testing activities.
When you shift left, testing becomes an early and frequent activity. Testing happens before, during, and after development. In general, that means less time waiting for testers.
Additionally, resources are more likely to be used to their fullest, with less idle time for testing environments, for instance. In a nutshell, shift-left results in less waste and more efficiency.
More Customer Involvement
Many agile approaches state that customer involvement is essential for the success of a software project.
As you’ve seen, BDD is one of those approaches, and so is extreme programming (XP). They both require customer participation, particularly when it comes to writing test cases or specifications.
Even though you can shift left without explicitly adopting BDD and/or XP, it is beneficial to include customer involvement in your testing process.
Adherence To The Testing Pyramid
The test automation pyramid is a useful concept in test automation. It helps teams and organizations decide how to prioritize between the many different types of automated software tests.
In a nutshell, the pyramid states you should have more unit tests than any other kind of test since they’re faster to run, and typically cheaper to set up, and easier to write. Then, you should have a smaller number of integration tests and an even smaller number of UI/end-to-end tests.
If your organization practices shift-left testing, that means your developers are likely to write unit tests, either before or after writing the production code. So, you’re likely to end up with more unit tests than any other type of test, meaning you’ll be following the testing pyramid.
A More Diverse Set of Team Members Performing Software Testing
We’re not in the 90s anymore. We’re in the 21st century and it’s now increasingly common for everyone at a software organization to perform testing. This is not only good but essential to true shift-left testing.
There’s no way to make testing a pervasive, constant activity without using all the help you need. Luckily, nowadays there are tools that even professionals with no coding skills can leverage to author robust tests in a way that just wasn’t possible in the past.
Coverage Goes Up
A not-that-surprising consequence of shift-left testing is that it drives test coverage up. It makes sense: if you have more people writing tests more frequently and starting earlier, it stands to reason you’ll have a larger portion of your application covered by tests.
A less guaranteed—but sill likely—consequence of shift letting is the increase in code coverage. I say it’s less guaranteed because shift left doesn’t necessarily imply more unit tests being written, but that’s likely to be the case.
Preventing Painful Test Maintenance Becomes More Important
Painful test maintenance is one of the more serious challenges in test automation. When your test suit is riddled with fragile tests, each seemingly small change to the codebase can result in test failure. The result is that maintaining the tests becomes a heavy burden, undermining the whole test automation effort.
When you adopt shift-left testing, it’s essential to give the test maintenance problem the care it deserves, since you’ll naturally have a larger number of tests of many different types.
Is Shift Left Testing the Way Forward?
This entirely depends on your organization. In theory, every organization can move toward shift left testing. You can start small by introducing coding standards or embracing a static analysis tool.
However, the benefits of shift left testing are clear. By detecting and reducing the number of bugs early on in the software development life cycle, we can ensure a higher quality of code. Besides that, your development team will save time and money by embracing testing in the early stages of software development.
This post was written by Michiel Mulders. Michiel is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he’s not writing, he’s probably enjoying a Belgian beer!
