Rapid Software Testing - Heuristics

As I mentioned before, Rapid Software Testing is a testing methodology defined by James Bach, Michael Bolton, and Paul Holland. This methodology focuses on the skillset and experience of the tester alongside with some rules and techniques to achieve a cost efficient quality assessment of a product.

This post will only focus on the Heuristics proposed by the methodology as a guideline for Exploratory Testing sessions although I’ve been using them as a source of inspiration for testing purposes. You can find the original document among other RST appendices. Let’s start the show!

I agree with RST approach that Testing is a context-driven activity, so you shouldn’t expect a cookbook explaining you step by step what you have to test. These represent “general techniques” which are generic enough to be relevant for a wide spectrum of contexts. Personally, these examples have helped me defining specific heuristics for a given product. These are the groups of test heuristics with some examples:

Functional testing. Determine the things the product can do, or this feature can offer. See that each function does what it’s supposed to do, and no what isn’t.

Claims testing. Challenge every claim you find about the product (either explicit and implicit). Test the veracity and clarity of the claims.

Domain testing. Segment the data the product can process into tiers (invalid values, boundary values, best representatives, etc.). Consider combinations of data.

User testing. Learn about user roles and categories, determining what are the differences in their needs and permissions.  Get real user data and involve the users (from different categories) in the test (or learn how to simulate one).

Stress testing. Look for part of the product vulnerable to being overloaded, and generate challenging data to test its limits.

Risk testing. Imagine a problem, then look for it. Focus on the kind of problems matters most. How would you detect problems? Your experience and knowledge about the product and the team will shine here!

Flow testing. Perform multiple activities connected, don’t reset the system between user paths and vary timing and sequencing.

Scenario testing. Tell a compelling story. Design tests that involve meaningful and complex interactions with the product.

Automatic checking. Check a million different facts, hopefully getting coverage in the process and using oracles. Tools that empower the tester are always welcomed!

In my experience, this is an amazing starting point when you face a new product. These heuristic rapidly evolve into context-customized during your first exploratory testing session, serving as a baseline for the next ones.

I have to admit that the main reason to write this post is serving as documentation to me, as well as helping me interiorise it. But I hope you find it useful as well!