Understanding early testing in software development

“Early testing” might sound like an easy topic, maybe almost trivial. “What’s early testing? It’s testing, done early,” you might think. As you’ll see, there’s more to it than that. In this guide, we’ll cover:

• the definition of early testing
• the history of how this approach came to be
• motivation and benefits
• how to get started

What is early testing in software development?

Let’s open the post with some fundamentals.

Early testing is an approach to your testing, and you can use whatever types of testing makes sense to you and your team.

Definition

There’s another term people use to refer to early testing, one you might have heard or read about: shift-left testing. Regardless of the name you use, the concept is the same: conducting software testing as early as possible in your development life cycle. Preferentially, in an automated way.

It’s vital to understand that early testing isn’t a category or type of testing. For instance, it wouldn’t make sense to say something like this: “In our company, we use unit testing, integration testing, and early testing.” Early testing is an approach to your testing, and you can use whatever types of testing makes sense to you and your team.

Shift left is a process of taking a step that’s part of the value stream of software development and moving it up the timeline.

Paul Hammant, The Rise of Test Impact Analysis

Motivation

People often claim that the earlier you catch a defect, the cheaper it is to fix it. This isn’t a myth, since there are studies backing up this claim. The amount by which the cost increases is a factor of the type of application you’re building, the amount of damage that a production bug can cause, and so on.

But what remains true is this: Generally speaking, the earlier you identify and fix a bug, the better. If you’re a software engineer, the earliest possible moment you could catch a defect is when you’re writing the code. And that’s possible if writing automated tests—unit tests, integration tests, and so on—along with your production code is part of your regular workflow.

So, the appeal of early testing is that if testing becomes an activity you start as early as possible and do continuously, instead of a “phase” in the software development life cycle, you greatly increase the chances that you’ll catch serious defects before they make it to production.

Software bugs can occur at any stage of the SDLC. If a bug is introduced at an early stage of the SDLC and is not immediately addressed, then its costs will only increase as it progresses through the SDLC. For example, fixing a bug in the planning stage can cost $100 if found early, but that same bug can escalate to become a $10,000 problem if it is discovered later on in the production stage. That’s because a bug can have a domino effect that leads to additional costs and delays.

Margarita Simonova, Costly Code: The Price Of Software Errors

History of early testing

The history of early testing is intertwined with the history of agile software development. Historically, organizations employed software development methodologies that were more waterfall-like. Thus, software testing was a formal activity that happened at the end of the development cycle, after coding was complete. This led to issues since many defects, even major ones, were only discovered very late in the process.

Add to this the fact that feedback cycles were longer in the past. The time that passed between a developer writing some code and an application build being released with those changes could be weeks, or even months.

As time went on, advances in computing shortened these feedback cycles. Computers got progressively smaller and exponentially more capable. While these hardware revolutions were happening, a group of experienced programmers and software consultants were experimenting with the way they developed software, trying to come up with processes that were more lightweight, iterative, and relied less on big upfront design phases and more on constant collaboration, both between developers and between developers and users.

The experimentation led by this group culminated into the creation of the Manifesto for Agile Software Development in 2001. The manifesto established the core values and principles of what today we collectively call agile methodologies.

One of the values from the manifesto is working software over comprehensive documentation, which means that having working software from the early stages of a project is more important than having a lot of documentation. And a way to ensure you’ll have working software since early on is early testing.

Kent Beck was one of the manifesto’s signatories. He created extreme programming (XP), which is one of the agile methodologies. XP puts heavy emphasis on early testing, since it dictates that production code should be written by two programmers (pair-programming), using TDD (test-driven development). That is, they write a failed unit test before writing the code to make that test pass, and repeat the process iteratively.

How to adopt early testing

As we’ve said earlier, early testing is not a type of testing, per se, so there aren’t any specific tools you use to implement it. Instead, it’s an approach you can enable by encouraging specific behaviors within your team or organization. Here are some suggestions on how to start with early testing in practice.

Test plans and automation

To make things even better, use a test automation tool to record and save the execution of this test plan as part of the automated tests suite.

One way to enable early testing is that before development for a feature starts, have someone—the developer themselves or a QA professional—write a detailed test plan for manually testing that feature. The developer would then use those test cases as a guide when developing, making sure to manually test during development and certainly before submitting their commits.

To make things even better, use a test automation tool to record and save the execution of this test plan as part of the automated tests suite.

BDD and TDD

Also, consider adopting a methodology such as BDD (behavior-driven development). In-depth coverage of BDD would be out of scope for this post, but here goes a short version. In BDD, before development of a feature starts, you write specifications for that feature. Then, with the help of a tool such as Cucumber, you turn those specifications into executable tests.

Those tests will, obviously, fail, since the functionality doesn’t exist yet. Then, you start actually coding the feature you need. For that, you’d use a similar approach to BDD: TDD, or test-driven development. Let’s say you needed to create a new class. Using TDD, you’d start writing a failed unit test, and then making that test pass. If necessary, you would refactor the code and then repeat the process until the class is complete.

You’d use as many TDD cycles you need to complete your code, and by the end of it, your BDD test should be passing, because now the feature is complete.

When that is ready to go, you’d commit your code. Your CI/CD pipeline would then build and test your changes and, if everything is correct, it could deploy your code to a QA or stage environment. Here, a QA professional could use a codeless test automation tool to create functional, end-to-end testing for the entire changeset.

Test early, test often

Long gone are the days when testing was an activity relegated to the end of the development process, and done by an often undervalued and overworked QA team. In the 21st century, testing should be something you do constantly, as early as possible, and is the responsibility of your whole team.

This post was written by Carlos Schults. Carlos is a skilled software engineer and an accomplished technical writer for various clients. His passion is to get to the bottom (the original source) of things and captivate readers with approachable and informative technical content.