| testing.com > Testing Craft > Techniques (Exploratory Testing) > A Survey > Exploratory Modeling |
Harry
Robinson
Microsoft
The object of your mission is to explore the Missouri river, & such principal streams of it, as, by its course and communication with the waters of the Pacific ocean...may offer the most direct & practicable water communication across this continent for the purposes of commerce.
- Thomas Jefferson's letter to Meriwether Lewis, June 1803
The mission of the Lewis and Clark expedition was to explore and map the territory of the Pacific Northwest. William Clark was the chief mapmaker for the expedition. He spent months perfecting his mapmaking skills before the expedition left St. Louis. As it turned out, later explorers and settlers used Clark’s maps for the next thirty years until newer, more detailed maps were drawn up.
The mapmaking was an essential part of the trip. It would have made little sense for Lewis and Clark to return home with collections of trinkets and souvenirs of the trip but no map of the territory that would tell others about the land and how to best navigate through it.
On the other hand, it would have been equally foolish to send scores of settlers into that unexplored territory -- much better to send a handful of scouts to survey the territory and report back.
Think about exploratory and automated testing from this same perspective.
Exploratory testing is extremely useful when we are faced with software that is untested, unknown or unstable. But once the product is more stable and settled, we would like to have a way to ease into a less labor-intensive, hopefully automated, mode of testing.
The question comes down to this: what we are left with when the exploratory testing is finished? Have we merely spent our time sightseeing, poking around and collecting bugs? Having a list of bugs is good. Having some idea of the dangers is good. But these approaches really only tell us how the software failed.
We would also like to understand how the software works (or at least was supposed to work). And we would like to have that information in a form that others can use and improve on.
Exploratory testers are a wonderful source of this information. They are the scouts who venture into the product while it is still in great flux and not yet ready for automation. As they explore, these testers are constructing models in their heads of how the product works. The problem is that those mental maps and models leave the project when the tester leaves. How can we save some of the valuable information that exploratory testers have accumulated?
One way is to have the exploratory tester help construct a model of the software’s behavior as they test:
These are all modeling questions, and there are tools and techniques that can make it easy to record our understanding of how the software works.
Exploratory testing is useful and necessary, but not sufficient. Exploratory modeling urges that one of the outputs of the exploratory tester’s efforts be to help construct a model of the software’s behavior. Making this model enables the tester to do a more thorough job of exercising the software. And the model can then serve later testers (or test automation) that will follow in the steps of the exploratory tester.
Some people view exploratory testing as happening alongside more formal testing. Some see it as happening instead of more formal testing. Exploratory modeling suggests a more holistic view; it sees exploratory testers as the vanguard of the test effort.
[1] Reprinted by permission from an email distribution list.
Be the first person to add a comment in the
Wiki Forum at page ExploratoryModeling.
(The Forum is explained in its FrontPage.)