exploratory testing

Exploratory testing is both a craft and a science. It requires intuition and critical thinking. Traditional scripted test cases usually require much less practice and thinking, which is perhaps why, in comparison, exploratory testing is often seen as "sloppy," "random," and "unstructured." How, then, do so many software projects routinely rely on it as an approach for finding some of its most severe bugs? If one reason is because it lets testers use their intuition and skill, then we should not only study how that intuition and skill is executed, but also how it can be cultivated and taught to others as a martial art. Indeed, that's what has been happening for many years, but only recently have there been major discoveries about how an exploratory tester works and a new effort by exploratory testing practitioners and enthusiasts to create a vocabulary.

Exploratory testing is more than just thinking of clever test ideas and executing them on a whim. It's a craft, requiring practice of several classic scientific skills-one of those skills is careful documentation of observations and conjectures. But as much as testers are scientists, they are also explorers. They must document their actions and observations during testing in such a way that stakeholders can easily understand the important problems and issues that are being discovered. In this track talk, expert exploratory tester Jon Bach compares exploratory test notes from several software projects to the journals of historical adventurers, showing how a tester's
journey through unchartered software can reveal similar risks and riches. Jon will discuss three common note-taking styles, as well as good, bad, and ugly notes he has seen (and produced!) in his ten years of testing.

James Whittaker took a group of untrained (and untainted) college students, ran them through a rigorous testing boot camp, and then pointed them at an already tested, world-class software product. Their mission: test it, break it, prove it works, and then automate everything you did. The outcome: interesting bugs, cool test automation, compelling test patterns, and useful ways of testing that you might never have considered before.