Agile Testing as if People Mattered

[article]

Exploratory Testing
Many testers (agile or otherwise) describe their job as similar to piecing together a puzzle. They see testing as a process of examining a coded application and finding out how it reacts to this tweak or that. Well, let's take the puzzle metaphor a little further. Let's say you are at your kitchen table with the puzzle pieces scatter around and you're ready to start. What is your first step? Will you pick up a few pieces and try fitting them together? Or will you take a step back, look at the puzzle as a whole, and write a detailed plan of how you see the pieces coming together?

I'm going to go out on a limb and say you picked the first option. Who would build a detailed plan for a jigsaw puzzle? Yes, puzzles are a pasttime and not a living. But let me ask one more question: Is a detailed plan even possible? I can't imagine that it would be for any but the simplest puzzle.

But is this comparison relevant? It becomes more relevant on an agile implementation, where you may not have the option of detailed test plans based on requirements, because the requirements simply don't exist yet. You must start fitting puzzle pieces together one or two at a time. In agile, you don't even know what the final picture of the puzzle will be. Is it a sailboat or a landscape or a child's face? Those requirements might not be there yet.

This is not to say that you will need to test without requirements, but that the requirements will often be created shortly before you begin testing, not giving you enough time to do a detailed written plan beforehand. Relating all this to testing, this is the mindset of exploratory testing.

Exploratory testing (ET) was originally coined in the early 1990s by Cem Kaner and James Bach to describe how testing is often more effective with less planning. They were doing their research on projects that weren't necessarily agile, but did have tight timelines and changing environments that thwarted detailed planning efforts. Although Kaner and Bach were not focused on agile, everything they describe with ET fits agile very well.

Bach describes ET as simultaneous learning, test design, and test execution. The tester receives the code and has possession of the requirements and begins to explore the application.

But to back up a bit, ET starts with a charter. You could call a charter a type of test plan, but it isn't detailed. It is usually a set of general statements on what to test, things like "Test the shopping cart functionality," and "Test the interface to the G/L." That's the extent of it. The test manager might provide this charter to a tester. Then the tester begins ET.

The Process of ET 
ET involves thinking of a test, designing it, usually in your mind, and executing it. It's a good idea to informally keep track of what you do as you test. There's a good chance that you'll learn something as you test that will influence what you decide to test next. It is truly an exploration. How those first few puzzle pieces fit (or don't) has a big impact on what you decide to do next.

Now, I can feel all my detailed test planning friends blood start to boil. "What you're describing," they are saying, "Isn't testing at all! It's just ad hoc fooling around!"

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!