Software Testing Lifecycle: A Complete and Simple Guide

In modern software development, especially in agile methodologies, testing isn’t an isolated stage but rather a continuous activity. Still, that doesn’t mean that testing occurs the same way, all of the time. 

Instead, the software testing activities change and evolve to fulfill any given project's current needs. In this post, we’ll offer a guide on how software testing adapts in the context of an agile project.

Let’s get started.

The software testing lifecycle is a sequence of cyclic software testing activities. You can think of the cycle as a framework that helps you understand the changes and evolutions a testing approach goes through over a software project’s lifetime.

It’s not uncommon to see the software testing lifecycle being described as a series of steps with fairly rigid handoffs. That might have been accurate back in the waterfall days—but for 21st-century software development, this approach just doesn’t cut it. In modern, agile-based software projects, testing isn’t a phase, at least in the traditional sense. It is a continuous activity performed throughout the software development lifecycle (SDLC).

That doesn’t mean, however, that all testing is homogenous. During the life of your project, and even inside a single iteration, you’ll see different types of testing being performed according to the application’s current needs. Those changes are what the software testing lifecycle describes.

Software testing—and automated testing in particular—is essential for software organizations. There’s simply no way to deliver high-quality software at the speed the modern market demands by relying solely on manual testing.

Testing isn’t free, though. And like any other investment, you must take care to ensure the testing process is as efficient as possible and brings valuable results.

Understanding the different testing needs along the lifetime of a project helps leaders make the right decision when allocating resources.

With the “what” and “why” out of our way, let’s proceed to the “how” of what I dub the modern software testing lifecycle. We’ll walk you through the different stages, explaining the category of testing you’d usually do at that stage, who performs it, and why it’s important.

Keep in mind that these aren’t discrete steps, but iterative, cyclic events.

In agile software development, work happens in short, incremental cycles. The details, such as naming (e.g., sprint) or duration (one week, two weeks, one month) vary according to each agile flavor. 

It’s common to start such cycles by writing automated acceptance or specification tests for the pieces of functionality that the team committed to delivering by the end of the cycle. This approach is similar to techniques such as BDD (behavior-driven development) or ATDD (acceptance test-driven development), in which the development starts with the creation of specifications written in plain language that are then turned into executable tests.

The customers themselves—or their representatives—may be asked to write these tests because they’re the ones interested in the value those features will generate. In practice, though, it’s common for testers, QA analysts, or even developers to write such tests.

During development, developers write unit tests as a sanity check against the code they write. They might write the tests before the actual production code—a technique known as TDD, or test-driven development. TDD—also known by other names, such as test-first programming—is a core practice of extreme programming, for instance. It’s also possible for the developers to write the unit tests after the production code is finished, though many would argue that’s not as effective as starting with the tests.

Integration tests might also be written during development time. Though developers might write integration tests, it’s more common for specialized QA staff to write them since they’re more involved than unit tests—for instance, they might require a more involved initial setup to run, such as the creation of a temporary database.

Code reviews—which can be considered a type of static testing—are usually carried out during development, especially in organizations that use some workflow based on pull requests.

After the engineers have merged their code, there are further forms of testing that might be carried out by QA personnel.

This includes, for instance, the authoring of automated end-to-end, UI, or functional tests, with the help of specialized tooling. While some of those tools might require coding skills, not all do. 

Additionally, even though automated testing should be pursued aggressively, manual testing is far from dead. It still has a role in many modern projects, and it’s usually performed by specialized testers during this stage. Manual tests can include usability testing and session-based exploratory testing.

Yes, you’ve read that right: testing in production. Back in the day, these three words used to be anathema in the software industry. Today, things look quite different. How did that happen?

Long story short: nowadays, we have the means to test in production while ensuring security and reliability. With the right safeguards in place, we can now reap the benefits of testing in production with far less risk.

For instance, with the help of the mechanism called feature flagging, it’s possible to keep features hidden in production, allowing only selected people to access them.

Feature flags also enable production experiments, such as A/B testing. A/B testing consists of splitting the user base into two segments and sending different versions of some functionality to each group. That way, you can test how the functionality affects each group’s behavior and experience.

Canary releases are yet another technique that feature flags make easier (although it is possible to do a canary release without feature flags). In this technique, you send a new version of the application to a portion (let’s say, 10%) of the users, and then closely monitor the release. At the sign of a problem, you just roll back the new version. If everything works out fine, you can gradually release the new version to more users.

Another activity that can be considered a form of testing in production is monitoring. As soon as your application goes live, anything could happen, despite your best efforts. Real-time monitoring, along with notifications and alerts, is an invaluable help to detect and fix issues as soon as they happen.

Monitoring can range from simple availability checks—essentially, a ping—to sophisticated synthetic monitoring solutions that simulate complex workflows by interacting with the application the way a real user would.

Thanks to agile methodologies, software development today no longer relies on strict phases and handoffs like it used to do. Instead, development occurs iteratively, in short cycles.

The same thing has happened to software testing. Recent cultural shifts, along with technological breakthroughs, have allowed testing to become a continuous activity that occurs at all stages of the SDLC. However, a software project still has different testing needs in each of its lifecycle phases, and that’s why it’s so important to understand the software testing lifecycle.

In today’s post, you’ve learned about the software testing lifecycle. You’ve seen the different testing activities that are carried out before, during, and after development. As you’ve seen, modern software testing is a rich and diverse activity, in which tests of different types—automated and manual—are carried out by different people, with different skill sets, catering to different needs. 

But what matters, in the end, is that (just like a puzzle) all those pieces fit together to form a unified testing strategy capable of ensuring the quality that modern software projects need.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.