- Modeling: Composing, describing and working with mental models of the things you are exploring. Identifying relevant dimensions, variables and dynamics.
- Resourcing: Obtaining tools and information to support your effort. Exploring sources of such tools and information. Getting people to help you.
- Questioning: Identifying missing information, conceiving of questions and asking questions in a way that elicits the information that you seek.
- Chartering: Making your own decisions about what you will work on and how you will work. Making the work relevant to your client.
- Observing: Gathering empirical data about the object of your study; collecting different kinds of data, or data about different aspects of the object; establishing procedures for rigorous observations.
- Manipulating: Making and managing contact with the object of your study, configuring and interacting with it, and establishing procedures for better control of experimental conditions.
- Collaboration: Working and thinking with another person on the same problem; group problem-solving.
- Generating/elaborating: Working quickly in a manner good enough for the circumstances. Revisiting the solution later to extend, refine, refactor or correct it.
- Overproduction/abandonment: Producing many different speculative ideas and making speculative experiments, more than you probably need, then abandoning what doesn't work. Examples are brainstorming, trial and error, "bracketing" in photography, genetic algorithms and free market dynamics.
- Abandonment/recovery: Abandoning ideas and materials in such a way as to facilitate their recovery, should they need to be revisited. Maintaining a "boneyard" of old ideas.
- Refocusing: Managing the scope and depth of your attention. Looking at different things, looking for different things, in different ways.
- Alternating: Switching among different activities or perspectives to create or relieve productive tension and make faster progress.
- Branching/backtracking: Allowing yourself to be productively distracted from one course of action in order to explore an unanticipated new idea. Identifying opportunities and pursuing them without losing track of the process.
- Conjecturing: Considering possibilities and probabilities. Considering multiple, incompatible explanations that account for the same facts.
- Recording: Preserving information about your process, progress and findings. Taking notes.
- Reporting: Making a credible, professional report of your work to your clients in oral and written form.
Experience isn't a requirement for exploratory testing, but certainly, as with anything, experience can help. An "experienced" Java programmer (whatever that means) will (in theory) write better code then a Java programmer out of college. That doesn't mean the Java programmer out of college can't write code -- he can. He just doesn't have the same experience to draw on.
The same is true with exploratory testing. Experience can be good, but it isn't required. Notice I said can be, because the wrong experience can be bad.
I recently witnessed my wife engage in an exploratory process. She got a new Apple Mac PowerBook from work and wanted to change the desktop picture, but she knows nothing about Mac computers. I offered her help, but she told me she wanted to learn how to do it on her own. I sat there and watched her process of exploration:
- She modified her model of how an operating system should behave. She had a model of Windows. She evolved it as she tested it against the Mac OS and found that they don't match.
- She manipulated the OS and observed her results -- trying different things, noticing what seemed to get her closer and what didn't.
- When I asked why she though a certain path through the operating system would get her to the desktop, she was able to form a reasonable conjecture for someone who hasn't worked with a Mac before but has only worked with Windows. Now here is where experience comes into play. Perhaps a more experienced explorer can make more informed conjectures.
- She asked me very focused questions from time to time.
- At one point she got sidetracked looking at desktop images online, recognized that she still hadn't even figured out how to change the desktop, and switched back to looking for how to complete that task.
- I noticed her moving between different polarities in her techniques.
She was exploring. Notice her use of the skills that professional explorers use. She is not a tester. She's not even someone who works in computers. She's a teacher. Think about what exploration is. It's a process of discovery, learning and testing ideas. Exploratory testing is a specific application of an exploratory process. My wife exhibited many of the same skills and tactics that I use when I explore while testing.
If I'm hiring exploratory testers, I'll look for all the Jon Bach's, Michael Bolton's, Jonathan Kohl's and Paul Carvalho's that I can find (all people I would call "expert" exploratory testers). That said, there are plenty of great testers out there who don't have the same past experience that Jonathan, Michael, Jon and Paul have who will still be excellent exploratory testers. A weak exploratory tester is one who relies only on apperception (the process of understanding by which newly observed qualities of an object are related to past experience) and intuition. Apperception and intuition are not what make Jonathan, Michael, Jon and Paul great testers. It's their knowledge of testing, their use of the various skills and tactics of the exploratory process, and their high level of cognition.
Find anyone with those attributes, and you'll find an expert exploratory tester -- regardless of past experience.
Dig Deeper on Topics Archive
Related Q&A from Mike Kelly
There are multiple ways performance testing can be handled on an Agile team. An expert describes the benefits of various approaches. Continue Reading
Every software tool is individually designed to meet various needs and requirements of projects, teams and project managers. Learn what tools experts... Continue Reading
Creating user acceptance tests out of basic software requirements documents can be a daunting task. Expert Mike Kelly points out logical approaches ... Continue Reading