To start testing in these situations, I often use a mnemonic I developed called “MUTII”. (A composer named Nicolo Mutii helps me remember it.) This mnemonic helps me maintain consistency in the way I think about testing. Expanding the mnemonic:
* Market—The targeted constituency of users this software is intended for. For example, “the finance department”, or “medium sized accounting firms”.
* Users—The actual users who will use the software. Who are the users? What do they do? What are their motivations for using our software?
* Tasks—What are the tasks that the users will use this software for? What are some typical tasks in their work?
* Information—What does the product tell me about the tasks it automates, and how I can perform them?
* Implementation—Is the software easy to use as a first time user? Is it reliable? Can I easily implement the tasks given the information and design of the product?
Before I start testing the application, I gather information about the market and the users from the business. This helps frame the kinds of tests I will develop when I use the software for the first time. If I’m not familiar with the market and users, I will also ask for typical tasks engaged in by the users.
When I start testing, I open my notebook to take notes of my observations and thoughts, and any bugs I find. (See Figure 1.) I begin designing a test in my mind, execute it with the software, and observe the results. I keep repeating this process, changing tests, and referring back to my MUTII mnemonic. Not only does each letter of the mnemonic help me frame my testing, but the acronym helps me quickly design and execute many tests under each section as I go. I may also use other heuristics and mnemonics as I test, if I find areas to explore differently or more deeply.
As I work through the application, I may find mismatches between the application and the market it is intended for, and the information supplied to users. If I have trouble figuring out the software’s purpose and how to use it, so will end users. This is important usability information that I write down in my notes. If the software isn’t usable, it isn’t going to sell. I invariably find bugs in this first testing session. I explore them, take notes so I can report them later, and design new tests around those bugs. After the session is over, I will have bugs to report and usability questions to ask. I will now have a model developed in my mind for testing this software. My brain will work on this model constantly, even when I’m not testing, and other testing activities will help build this and other models of the software.
Using heuristics and mnemonics helps me be consistent when testing, but I don’t let them rule my testing actions. If I observe something suspicious, I explore it. If something feels wrong, I investigate, and confirm or deny that feeling with defensible facts. It’s common to switch from heuristics and mnemonics to pure free-form improvisation and back again, or to improvise around highly structured tests. Exploratory testing—like improvising—helps me adapt my thinking and my actions based on what the software is telling me. This is a powerful concept. You can seize upon opportunities as soon as you observe them. Furthermore, you can adapt quickly to project risks, and discover and explore new ones. By developing skills to manage your thinking about testing, you no longer have to wait for spontaneous discoveries to appear out of thin air, and not be able to explain why you found a particular problem, or repeat it.