An introduction to agile test management

Testing is a critical part of every software development lifecycle, regardless of the process you decide on as a team. But certain choices seem more complicated than others. This is especially true for agile software development, which focuses on releasing software quickly and rapid iteration. Those rapid cycle times sometimes make agile test management feel like an interruption in your development flow. That’s why effectively defining a testing strategy is critical for your team. In this post, we’re going to talk about how to think about agile testing, what factors you want to take into account to define your strategy, and how to implement it.

What is an agile test management strategy?

Agile test management is the process of defining and implementing a testing strategy that fits the way your agile software team develops and deploys your code. Agile software development values things like “people over process” and “responding to change over following a plan.” Statements like that lead to the feeling that something like a testing strategy is unnecessary. but it is. Just because you’re focusing on shipping code quickly doesn’t mean that you should abandon all processes or planning. It just means that you need to be flexible about your approach.

How should i define an agile test management strategy?

There is no one-size-fits-all approach to agile test management. How you test your software, when, and how often will depend on what kind of software you’re building. That said, when you’re thinking about how you approach your agile testing strategy, there are a few rules you should follow. Let’s walk through them.

The goal of agile software development practices is flexibility and finding the plan that works best for your team and your situation

Be flexible

This might seem obvious, but in my experience, it’s one of the hardest things for agile teams to remember. The goal of agile software development practices is flexibility and finding the plan that works best for your team and your situation. As your software changes and matures, you may find that you need to change your approach to testing. That’s OK! The test management approach that you use for a greenfield project with one customer will be different than the approach you use for a mature platform with a hundred million.

Ship often

This isn’t technically a question of testing, but testing has a huge impact on how you think about shipping. A core part of the agile part of agile software development is being able to ship quickly so that you can respond to customer feedback. So while shipping often isn’t actually a part of how you approach testing, you want it to be a pillar of your testing strategy. However else you think about test management, you want to support your goal of shipping quickly.

Leverage automated testing tools

It might be that when your application is first starting out, you’ll be able to test every part of the application by hand every time. That won’t stay true for very long. And a key part of retaining confidence in your frequent releases is confidence that the changes you’ve made aren’t breaking any legacy functionality. That’s why you need to enlist automated agile test management tools like Tricentis qTest. By building a quality suite of automated tests that you run before you deploy, you can ship with confidence that things continue to work the way they should.

Be prepared to change tests

Again, remember rule #1: be flexible. That means there’s a good chance you’ll ship some software and find out that it isn’t working the way you hoped. That might be because what you wrote isn’t performant. Maybe it’s because you got feedback from your customers and they don’t like what you made. Whatever the reason, you need to be ready to look at the software you wrote and decide that it needs to change.

When the software you wrote changes, you need to be able to change the tests that surround that software quickly as well. That might be deleting those tests, or it might mean modifying them. Whatever your needs, you want to make sure to adopt a strategy and testing tools that make modifying your tests quick and painless.

You don’t need to run every test every time

This is another common mistake that agile software teams make. They view tests as a nonnegotiable part of every single release. This is a great attitude when you have a newer application, but it comes with a big downside: over time, that test suite grows. When you run your tests as a part of every deployment process, you might go from a five-minute test run to an hour-long test run over the course of a couple years. Sometimes that run time will get even longer than that.

A lot of teams simply live with this pain as their tests grow slower and slower. But there are other options. One approach that teams might take is to have different automated testing approaches, where they run some tests on every deployment and run a different suite of tests independently from the deployment cycle. Instead, it runs on a timed rhythm against the deployed production system. This kind of strategy means that you can more easily stick to rule #2: ship often.

Don’t abandon the human element

This is another place where agile teams sometimes lose the plot. They think that rapid releases mean getting their code out as quickly as possible without ever thinking about having a human test it. Sometimes that works for your software or for a particular set of changes. But when you’re putting together an agile test management strategy, you don’t want to abandon human interaction. It may be that you need a critical customer to approve something before it goes live or that you want to hear from the product owner for a feature before releasing it to the world.

That doesn’t mean that you need to abandon a continuous integration approach. You might consider adopting feature flags as a way to deploy something, then approach it with manual testing before you enable it for everyone.

Plan your tests as part of your feature

The last rule is ensuring that your tests actually exist. When you’re working on a deadline in a sprint, it’s easy for tests to slip to the bottom of the priority pile. Do this a couple of times, and before you know it, your test coverage is severely lacking.

So build time for testing into each of your features. That means creating automated tests for the features where that’s required and time for manual feature approval for code where you need it. If you do not plan time for testing into your sprint plan, you will miss tests, and over time that will cost you stability for your software. Testing can’t be optional, or you’ll never do it.

When you’re adopting an agile software team approach, it’s common to grow hyper-focused on shipping at all costs

Agile test management doesn’t have to be a chore

When you’re adopting an agile software team approach, it’s common to grow hyper-focused on shipping at all costs. It’s far too easy to feel like the only feedback you need is customer feedback and that you should ship as often and as quickly as possible. When that’s your mentality, testing feels like it interrupts more important work. However good testing is an important guarantee of long-term software quality. By developing a high-quality test management strategy, you can avoid feeling like testing gets in the way. Instead, you’ll view it as an important part of your feature development plan and grow to appreciate the benefits that quality testing strategies provide.

There’s no silver bullet for agile test management. But if you develop a high-quality agile test management strategy and adopt a high-quality tool like Tricentis qTest, you’ll quickly find that testing is part of your team’s blueprint for success.

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.