Rapid Testing

Rapid Testing

Rapid Software Testing - The style of rapid testing is tester-centric (as opposed to technique-centric) and is a blend of heuristic testing, risk-based testing, and exploratory testing.

How is Rapid Software Testing different from normal software testing?

Software Testing practice differs from industry to industry, company to company, tester to tester and person to person. But there are some elements that most test projects have in common. Let's call those common elements "normal testing". In our experience, normal testing involves writing test cases against some kind of specification. These test cases are fragmentary
plans or procedures that loosely specify what a tester will do to test the product. The tester is then expected to perform these test cases on the product, repeatedly, throughout the course of the project.

Rapid testing differs from traditional testing in several major ways:

• Don’t Waste Time. The most rapid action is no action at all. So, in rapid testing we eliminate any activity that isn't necessary. Traditional testing, by comparison, is a bloated
  mess. It takes some training and experience to know what to eliminate, of course. In general, streamline documentation and devote testing to primarily to risk areas. Don't repeat tests just because someone told you that repetition is good. Make sure that you get good information value from every test. Consider the opportunity cost of each testing activitiy.

• Mission. In Rapid Testing we don't start with a task ("write test cases"), we start with a
  mission. Our mission may be "find important problems fast". If so, then writing test cases may not be the best approach to the test process. If, on the other hand, our mission is "please the FDA auditors", then we not only will have to write test cases, we'll have to write certain kinds of test cases and present them in a specifically approved format. Proceeding from an understanding of our mission, we take stock of our situation and look for the most efficient and effective actions we can take right now to move towards fulfilling that mission.

• Skills. To do any testing well requires skill. Normal testing downplays the importance of skill by focusing on the format of test documentation rather than the robustness of
  tests. Rapid Testing, as we describe it, highlights skill. It isn't a mechanical technique like making microwave popcorn, or filling out forms at the DMV. Robust tests are very important, so we practice critical thinking and experimental design skills. A novice tester will not do RT very well unless supervised and coached by a senior tester who is trained (or self-trained) in the art. We hope the articles and presentations on this site will help you work on those skills.

• Risk. Normal testing is focused on functional and structural product coverage. In other words, if the product can do X, then try X. Rapid Testing focuses on important problems. We gain an understanding of the product we're testing to the point where we can imagine what kinds of problems are more likely to happen and what problems would have more impact if they happened.Then we put most of our effort into testing for those problems. Rapid Testing is concerned with uncovering the most important information as soon as possible.

• Heuristics. We must beware of overthinking the testing problem, so we use heuristics (loose translation: rules of thumb) to help us get out of analysis paralysis and test
  more quickly. Heuristics are essentially reflexes-- biases to respond in a certain way-- that generally help us test the right things at the right time. Rapid Testers collect, memorize and practice using helpful heuristics. In normal testing, heuristics are also used, but testers are often not aware of them and do not fully control them.

• Exploration. Rapid Testing is also rapid learning, so we use exploratory testing. We avoid pre-scripting test cases unless there is a clear and compelling need. We prefer
  to let the next test we do be influenced by the last test we did. This is a good thing, because we're not imprisoned by pre-conceived notions about what we should test, but let ourselves develop better ideas as we go. Other approaches to doing testing quickly, such as extensive test automation, run the risk that you'll end up with a lot of very fast tests that don't help you find the important problems in the product.

• Teaming. Rapid Testers cheat. That is, they do things that our former elementary school teachers would consider cheating: we figure things out in advance where possible, we borrow other people's work, we use every resource and tool we can find. For example,
  one important technique of Rapid Testing is pair testing: two heads, one computer. This idea has proven valuable in the practice of Extreme Programming, and it works for testing just as well. In our experience of normal testing, testers usually work quietly and alone, rather than hunting for bugs like a pack of rapid wolves.