Exploratory testing compliments TDD and other test automation. Especially interested in the structured exploration to guide learning. book 
Uploaded image
In a letter dated June 20, 1803, Thomas Jefferson, the third president of the United States, gave the explorers Lewis and Clark a mission: discover a route across the continent from a starting point near St. Louis, Missouri, out to the Pacific Ocean.
Jefferson’s letter goes on for pages and in great detail. In it, he specified these points:
• Where they were to explore: the Missouri River and connecting waterways • The resources they would have: equipment such as boats, tents, surveying tools, weapons, and even presents for the natives they would encounter
• The information they were to seek: trading routes. Jefferson explicitly directed Lewis and Clark to seek “direct and practicable water communication across this continent for the purpose of commerce.” link He was not looking for nice picnic spots or locations for future national parks.
Three years and three months later, Lewis and Clark returned to St. Louis as national heroes. They had covered seven thousand miles and mapped the trail they followed through the interior of the North American continent toward the western sea.
Like Lewis and Clark, your ultimate goal in exploring is to discover information of interest and value to your stakeholders (the people on your team and any others who have a vested interest in the information you discover). The essential elements of the charter Jefferson gave his explorers suggests a simple template for charters, as discussed in the next section
Although Jefferson’s letter to Lewis and Clark went on for pages, the essential information it contained fell into the three broad categories above: where to explore, what resources were available, and what information to discover. This suggests a simple three-part template:
• Target: Where are you exploring? It could be a feature, a requirement, or a module.
• Resources: What resources will you bring with you? Resources can be anything: a tool, a data set, a technique, a configuration, or perhaps an interdependent feature.
• Information: What kind of information are you hoping to find? Are you characterizing the security, performance, reliability, capability, usability, or some other aspect of the system? Are you looking for consistency of design or violations of a standard?
.
I read this book a couple years ago when I found myself unexpectedly in the role of acting QA manager. Today I revisit it with particular interest in the chapter about charters.
I hope to persuade my colleagues to join me on professional development explorations with using charters to focus our learning objectives and constrain scope.