This website uses cookies. By using our website, you agree to the use of cookies.

banner blog



Agile Testing

"Okay, so we are doing Agile now, that probably won't change a lot in our testing." Well, sorry, it actually does. But before we have a look at what really changes, let's first have a look at different definitions of agile testing. If you look around there are a lot of interpretations and ideas to this, but generally it boils down to two approaches:

1. Testing is organized in an agile way
2. Testing in agile development

The first refers to settings where testing is organized with backlogs, done in short(er) cycles and there is a daily stand-up. Testers are organized in a team all by themselves and maybe even locally distinct from the development team. If these teams are lucky there even is something like a retrospective. It is not unlikely that testers are even there to sign off the work and give green lights for release. All of this is nice (the last part about signing off certainly isn't) and probably still an improvement, but testing is still a phase of its own.

The latter is referring to all kind of testing activities that are conducted throughout all kind of activities during a short iteration. Testers are part of the development team and not really separated. The common goal is to deliver working software at the end of the iteration. To me, the latter definition fits the term agile testing a lot better than the first one. With regard to testing techniques and methods there isn't much change. But organizing testing and the goal of testing differs vastly. The mindset of agile testing is whole lot different than more classic approaches. Well, this is something that is true for agile development, but especially for agile testing. Sam Laing and Karen Greaves have splendidly summed up the changed mindset in the testing manifesto for agile testing, which I would like to comment on shortly:


“Testing throughout over testing at the end“

Traditional approaches have testing at the end. There needs something that has been built to test it. An important part of testing is providing information about the software, so you should go and get information as early as possible to adjust your development efforts as early as possible. It's a bit like cooking. If you start tasting after everything is finished you can certainly decide that the meal is good or not. But it's very hard to change things if it's not good. That's why most people taste while cooking and add things here and there. Early information lets you adjust early and before things go out to a customer. For software development that means that you start your testing as early as possible and that testing does include questioning requirements, decisions and assumptions well before the first line of code is written.


“Preventing bugs over finding bugs”

This is closely related to the first point. It is not about finding bugs at a certain point of time, i.e. the testing phase. It is about making sure that bugs don't even come into existing. If you fire up your search engine of choice and let it look for the costs of fixing bugs you will find a lot of different studies and publications about that. While the factor differs a bit, almost all of them agree that bugs early found in development are way cheaper to fix than the ones found later. And while we are at it, finding many bugs doesn't make you necessarily a good tester, it probably just means that there hasn't been enough testing earlier to prevent those bugs.


“Testing understanding over checking functionality”

Agile development is (among other things) about delivering software quickly. Which means that there is no time for prolonged testing phases. Heck, most iterations are even shorter than some system tests I have been on. The holy grail of the agile world is automation. Well, as we all remember from Indiana Jones, the shiny holy grail is not what it seems! Use your automation wisely for what it is good for: checking that (obvious) things are as expected and freeing up valuable times of the testers (unless you are having just clicking monkeys, but then you are having problems anyway).


“Building the best system over breaking the system”

In one of my first projects we had a high score list for bugs found. It was a race for the top and about breaking the system. It was us testers against them developers. Like it or not, but you are on the same team now and hopefully have a common goal of delivering high quality software (without going into the "what is quality" debate here). And oh, sorry to say so, but you don't break the software unless you put some buggy parts into the source code. You just show how it really is or to quote James Bach: "We don't break the software. We break illusions about the software."


“Team responsibility for quality over tester responsibility”

A former boss of mine repeatedly said that nurses don't heal a patient by simply taking his temperature. By doing so, they are providing information for themselves or others to improve the condition of the patient. As for software testing, just testing doesn't get you more quality. It is one part of doing so. Just as writing good code, providing realistic requirements and writing a good instruction manual is. So it's everything and everyone that influences quality. Especially on agile teams, activities are more and more separated from persons and roles within a team. Activities are a team skill. Some people are better at certain things than others, but that doesn't mean that it is only the task of the specialist to do so. As testers we are responsible to share our expertise with the other team members. Of course it might take longer for others, but taking longer is still way better than not doing it at all or being the bottleneck.

If you take your testing knowledge from other testing environments and embrace the changed mindset for agile testing, you are already following the "inspect and adapt" part that is so prevalent in agile development and will certainly be able to build on that. Of course there are certain methods, heuristics and techniques that have proven helpful, but that topic certainly warrants a post of its own.


Christian Kram for TestBench