Is Agile Testing a Dirty Word?

I’ve been a part of a few conversations of late asking “why do we say agile tester?” Or saying that agile testing is a fantasy title used to impress people. So has agile testing (like manual testing) become a dirty word for people?

I reviewed the conversations on LinkedIn (and asked people directly in a post) to see how people think about the term agile testing.

What is Agile Testing?

Simply put, agile testing usually means the testing tools and techniques we would use in an agile development environment. It encompasses the same areas that we’d test for anything (functional, non functional, regression) but the ways we do this may differ.

Faster, we need to shorten feedback loops and be able to get information to teams as they’re building things. Our testing needs to be able to work earlier and return feedback in hours rather than days. With many releases happening a day we need automation that runs quickly and close to the code.

More pragmatic, to be faster we need to pick the most useful tests. We have to be able to test to “good enough” and base what we do around risks. We can’t aim to test everything and so testing needs to be able to speak about what issues are fine to ignore for now.

Self starting, you own the project and the testing that happens there. That means you have to set your own testing goals, advocate for testing and push information to people. If you don’t do that performance testing, who will? This means you have to be able to work well as a self starter, knowing what should be tested, rather than waiting to be told.

Less certainty, there’s less documentation and less of people telling you exactly how things should be. That means testing needs to be able to uncover information about risks and make it explicit, exploration is needed as well as confirmatory tests.

More ownership, this isn’t a project it’s a product and we own it. That means we own making it good and deciding what good looks like for the product. Testing needs to work to determine both correctness and goodness, which means a wider and deeper scope of testing.

I Wouldn’t do Anything Differently

An argument I see that the term agile testing is a dirty word is that it’s not describing anything different or new. That testing is testing and you don’t need to differentiate between types or environments of testing.

Yes, testing is testing but not all approaches will work well in all development environments. We need to be able to tailor our testing to the risks inherent in how we’re building and releasing.

• We’re releasing to production every sprint, we have to design / build / test / release 5-7 things in that two weeks.
• We need to cover functional, regression, design, accessibility, security, performance, scalability, deployability, observability and marketability for everything we’re building.
• There’s no specific requirements, only a general ask for something the customer might want. Nothing is telling me that it’s finished when X, Y and Z are exactly there.
• We’re building new things at the same time as maintaining things in production.
• We still have to provide traceability and evidence of testing.
• The team have decided to build all the back end first and the UI will come in on the last day of the sprint. We won’t have time to test / fix and release everything if we only start testing on that day.

As you can see from these examples show that we’ll need approaches that give us the time to do more. If we try to test from the UI and use all our time writing manual scripts then we won’t have time to do everything else, plus there won’t be time to fix things. We can’t just descope things because then we won’t know if it’s good, so we need to adapt how we might work.

Not changing how you’d work between waterfall and agile teams means you probably wouldn’t be able to pick up enough testing.

I Wouldn’t be Impressed by that Title

Some people see “agile tester” as a way of having a fancy title that aims to elevate them over others as a status symbol. Like with the term manual testers being seen as dirty for being a way to “put down” other testers, it’s seen as something that’s self aggrandising.

Instead of us using the term to mean someone who applies a specific testing approach and strategy for use in agile, it’s seen as “fancy”. It’s important to understand that different teams need different approaches and that marking yourself as being able to help them out is useful.

It’s not about being “fancy” or trying to impress people, it’s really about easily showcasing what problems you can help solve (or have had experience in). It’s the same reason we get back end, front end and data engineers; they all can build different things. Heck it’s the reason we have any testing title, to show that we can help people out with testing!

It’s Chaotic and Test Becomes a Bottleneck

This was a response on the LinkedIn post I made as king what agile testing meant to people. I get it and I sympathise… I’ve been there!

When we don’t change our approach to testing things start to leave us behind and there’s too much to do. I was in teams where the testing had to happen the sprint *after* development. Know what that’s called? Waterfall (but without the docs).

We get into this state when we don’t adapt our approach to suit what’s needed. Trying to test in the old ways of requirement review, writing scripts, testing business logic from a finished product and not pushing left or right (earlier to raise risks before bugs are found and later to learn from users in prod) means we’re going to fail.

Unless you look into the tools, techniques and approaches that work with an agile delivery method then we’ll end up in chaos.

• Automating regression.
• Testing earlier from designs and in Triforce to prevent bugs.
• Exploring to see if things are good and benchmarking.
• Testing closer to the code rather than closer to the business.
• Collaborating with the team and championing testing rather than doing it all yourself.
• Being more pragmatic and asking “what is good enough”.

These were the things that helped me make more time and be less chaotic when I moved to agile teams.

On the Other Side

Some people that I spoke to were advocates of agile testing. They talked about the flexibility and autonomy that they had as testers and how it’s big on collaboration and teamwork.

It was also mentioned that you had to review your approach, look at what you’re doing and use it as an opportunity to “make things better”.

Conclusions

Agile testing seems to be a dirty word for some people, but could this stem from not understanding how it needs to be different.

As with the manual testing title, we’ve seen that people’s titles in our profession can mean a lot for people. It can be a source of pride or a source of worry that you’re not marketable. The emotions wrapped up in your career can understandably make you resistant to terms that make you feel that you’re not achieving (or implicitly saying you’re bad).

There also appears to be a lack of understanding oh how agile testing needs are different from other projects. Some of this comes from most organisations not doing agile properly (not delivering fast and often) and not collaborating well.