What is agile testing?

I've had this conversation many times, as have others. On almost every occasion where I have met so-called agile testers (e.g. Agile Testing Days, GATE,…) the question came up “What is agile testing?” For quite some time I have been fiddling around with it on my own and have always come back to a thought I had a year ago. So this is my view of agile testing so far.

My first contact with agile testing was a video of a Google Tech Talk by Elisabeth Hendrickson. That was long before I worked with it-agile and even longer before I decided to evolve to a tester. If you listen closely you will find that Elisabeth doesn’t describe a single technique that could not be applied to a classical project.

In fact Elisabeth is talking very little about actual testing in the video and more about organizing the parts of a project that are at some point or another connected to testing. People say the same about the book Agile Testing by Lisa Crispin and Janet Gregory, and both can lead to certain confusion.

In my opinion this confusion is closely related to the term “agile testing”.

My understanding came from two situations I encountered:

The first is that, while working for it-agile, I have given several trainings together with my colleague Markus Gärtner about agile testing. For marketing reasons we called the most important training, translated to English, “testing in scrum”. But it should prepare testers for the work in agile projects of any color. What happened was that most of our participants told us afterwards: “I knew most of the techniques we used in the last days. I am not yet sure what was new”.

The second was at a peer-conference called PotsLightning, which I attended just before Agile Testing Days Germany. While discussing agile testing with some smart brains I remember a thought crossing my mind out of the blue. I mentioned it and was astounded that my peers began writing it down (which never had happened to me before). What I said was: 

“Isn’t agile testing something like coping with agile projects as a tester?”

And that’s basically what I still think. Agile testing is not a special testing technique. It is not unique to agile projects but can be used elsewhere. It is not a fixed set of things you apply to make your testing agile. Instead I see agile testing as necessities you will have in agile projects. If you don’t use agile testing in agile projects, chances are high that in no time you have a pretty high pile of testing debts. Agile testing is a way to prevent that kind of technical debt.

So I see agile testing as a sensible combination of organizing and testing approaches rather than as single techniques. Let’s get a bit more specific. And keep in mind these are just heuristics. Some of it might not apply to every project. You will still have to use your brain.

Some of the approaches (this list is not at all complete – it can’t be – but contains the first few thoughts I have) I find useful in most projects I encounter are:

1. It’s not too early to test. If there is not yet a tiny piece of software you can test, then you can still test requirements.
2. The piece of software isn’t too small to test. Even a very simple and small program that doesn’t do much can be tested.
3. It’s not too early to think about regression testing. What are the things of your software, which have to absolutely work every time? Think about how you will test them because your software will grow fast and with every new piece of software you will have to test more.
4. Testing is not about you but about the product. Yes, you will test some things a couple of times and this is inefficient. But it’s not about you as a tester. It’s often about fast feedback on the product, which makes testing more often necessary.
5. Work closely together with programmers. Don’t be afraid. Mostly they don’t bite your head off. They might not be used to working with a tester though. You don’t have to program to read code. It’s useful knowledge though. Ask questions. While programmers program. Not only in the after. Work in pairs with programmers.

There are lots and lots of things like these (some of which are to be found for example in the book Explore it!). I think I could invest some time in another blog post, we will see. But it’s not about a comprehensive list, but about noticing: All these approaches can be used in other environments than agile ones. Your company’s ways might not enable you to do so, but there is no rule against them in waterfall or other project types.

They are most probably not new to you. And they all point to the fact that you have to test fast and often in agile projects. You can’t have a testing sprint in scrum. There is no code-freeze at the end of an agile project. Testing has do be done all the time.

Agile testing is a way to cope with agile projects as a tester.

You’ll have to do whatever is necessary to prevent falling behind development and still find the most important information to create high quality products with your team.