Posted by Quardev, Inc. on August 20, 2009
Isn’t exploration unscripted, unrehearsed, extemporaneous, ad hoc, make-it-up-as-you go, random, thoughtless testing? And isn’t that the point? To let Serendipity help you find bugs by having you bump into them by accident?
You’d think that, but it’s not. Think about great historical explorers. Did they just set sail with no reason and any random direction? Were they maritime pinballs that bounced into islands randomly, never to return to home port except by chance?
No. They had a charter, a mission — something written for them by a sponsor.
Sounds like a user story, doesn’t it?
Sounds like a test case, too.
Sounds like any test at all, provided that you think and adapt while you test. If you don’t (or are not allowed to), it’s not exploration.
Testing is discovery, and though you may start out in one direction, you may have to change course — to achive better coverage, to investigate a bug, to follow-up on a hunch.
But there are structures in exploration other than the mission statement.
Notes — You can document what you saw, what you theorized, what you were confused about. You can capture your system details, your test ideas, stack traces, build number, date, time, operating system.
Bugs — You can report problems by following a template.
Issues — You can record a list of questions you have about your findings or concerns about the quality of the product that aren’t bugs — yet.
Time — You can record how much time you spend on a mission. 30, 60, 90 minutes, all day.
Effort — You can track how much time you spent on three activities during your testing: Setting up for Testing, Documenting Your Tesitng, Test Design, Test Execution, Bug Investigation, Bug Reporting.
Areas — You can document what primary or contributing features you touched during the course of your exploration.
Opportunities or distractions — You can estimate a percentage of time spent on your mission vs. time spent on test ideas that you decided to ran because something got your attention.
A report — You can document all of this in a file to be reviewed. That in itself is structure.
So think about this the next time someone says exploratory testing is unstructured. It actually requires a lot of discipline to use these structures while you explore, but that may be the very thing you’re looking for in your next Agile-style project.
