I teach a rapid software testing class.

When I say “Rapid Testing” I mean the fastest test process that is still good enough for a given project. It’s testing with a sense of urgency. Many testing classes don’t focus on rapidity. Does that mean they advocate “slow testing?” No, my competitors generally teach what they consider to be techniques of thorough testing. Often this takes the form of a list of techniques, taught one after another, leaving it to the student to figure out how to fit all those techniques into the project. But those techniques take a long time to follow if each one is followed to its natural conclusion, so “thorough” becomes extremely non-rapid.

Rapid testing is not a technique, but an overarching process of understanding the context of a test project and maximizing the value of our time. One part of that process is to cut out anything that isn’t necessary. Another part is to reconceive testing as a process of heuristic inquiry, rather than a clerical task.

Rapid testing is a complete testing process. By definition, any test project can be rapid and also successful, because rapid testing is as thorough as it needs to be. In other words, when I say rapid, I do *not* mean reckless. Another term for rapid testing might be “good testing”, but that term doesn’t highlight the very real difference between my approach and others (such as the fact that my approach is faster), so I’ll keep saying rapid for now.

A tactic used in rapid testing is a family of test heuristics that I call hyper-rapid testing. Hyper-rapid testing consists of those test ideas that can be employed for low cost, with no preparation, and no deep knowledge of the technology or problem domain. Unlike rapid testing, hyper-rapid testing is not a complete test process. But with hyper-rapid testing, I can walk up to any product and find problems in it immediately. I like to demonstrate hyper-rapid test techniques when I give testing talks just because they are the sort of things that can be demonstrated in only a few minutes.

James Whittaker and Alan Jorgensen were the first I know to publish a cohesive model of hyper-rapid test ideas. However, they didn’t distinguish between hyper-rapid testing and the rest of the testing picture. Instead they presented their ideas as if that as all there is to testing. I think that’s caused unnecessary resistance to them. Partly inspired by Whittaker and Jorgensen, here are some examples of hyper-rapid test heuristics I use, each sketched in brief:

• Input Constraint Attacks: Discover sources of input and attempt to violate constraints on that input. For instance, use a geometrically expanding string in a field. Keep doubling its length until the product crashes. Use special characters. Inject noise of any kind into a system and see what happens. I found an ugly error in the British Museum’s main computer system by search for a string that had alternating asterisks and quotation marks.
• Variability Tour: Tour a product looking for anything that is variable and vary it. Vary it as far as possible, in every dimension possible. Exploring variations is part of the basic structure of my testing when I first encounter a product.
• Sample Data Tour: Employ any sample data you can, and all that you can. The more complex the better.
• Continuous Use: While testing, do not reset the system. Leave windows and files open. Let disk and memory usage mount. You’re hoping that the system ties itself in knots.
• Interruptions: Start activities and stop them in the middle. Stop them at awkward times. Perform stoppages using cancel buttons, O/S level interrupts (ctrl-alt-delete or task manager), arrange for other programs to interrupt (such as screensavers or virus checkers). Maybe the system will not properly reset itself. Also try suspending an activity and returning later.
• Undermining: Start using a function when the system is in an appropriate state, then change the state part way through (for instance, delete a file while it is being edited, eject a disk, pull net cables or power cords) to an innappropriate state. This is similar to interruption, except you are expecting the function to interrupt itself by detecting that it no longer can proceed safely.
• Shoe Test: This is any test consistent with placing a shoe on the keyboard. Basically, it means using auto-repeat on the keyboard for a very cheap stress test. Look for dialog boxes so constructed that pressing a key leads to, say, another dialog box (perhaps an error message) that also has a button connected to the same key that returns to the first dialog box. That way you can place a shoe (or Coke can, as I often do, but sweeping off a cowboy boot has a certain drama to it) on the keyboard and walk away. Let the test run for an hour.
• Error Message Hangover: Make error messages happen and test hard after they are dismissed. Often develop handle errors poorly. I once broke into a public kiosk by right clicking rapidly after an error occurred. It turned out that the security code left a 1/5 second window of opportunity for me to access a special menu and take over the system.
• Click Like Crazy: Testing is more than “banging on the keyboard”, but that phrase wasn’t coined for nothing. Try banging on the keyboard. Try clicking everywhere. I broke into a touchscreen system once by poking every square centimeter of every screen until I found a secret button.
• Multiple Instances: Run a lot of instances of the app at the same time. Open the same files.
• Feature Interactions: Discover where individual functions interact or share data. Look for any interdependencies. Tour them. Stress them. I once crashed an app by loading up all the fields in a form to their maximums and then traversing to the report generator.
• Cheap Tools Activate! Learn how to use InCtrl5, Filemon, Regmon, AppVerifier, Perfmon, Task Manager (all of which are free). Have these tools on a thumb drive and carry it around. Also, carry a digital camera. I now carry a tiny 3 megapixel camera and a tiny video camera. Both fit into my coat pockets. I use them to record screen shots and product behaviors.
• Resource Starvation: Progressively lower memory and other resources until the product collapses, or gracefully (we hope) degrades.
• Play “Writer Sez”: Look in the online help or user manual and find some instructions about how to perform some interesting activity. Do those actions. Then improvise from them. Often writers are hurried as they write down steps, or the software changes after they write the manual.

There are other aspects to hyper-rapid testing that belong more to the realm of skill, and are hard to summarize as a nice self-contained heuristic. More on that later.

I like to demonstrate hyper-rapid testing in classes and talks because it’s dramatic and convenient. They’re pretty much the only kind of test activities that I can demonstrate in brief. Just don’t confuse that with the full breadth and depth of the rapid testing process.

This entry was posted on Saturday, December 6th, 2003 at 10:32 pm and is filed under Software Testing and Quality. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.