Applying Heuristics

Definition & an example

According to Rapid Software Testing Approach¹, a heuristic is a fallible method of solving a problem or making a decision.

A heuristic example:

ZOM stands for Zero, One, Many, and it is a heuristic that may be applied in various situations, especially lists and collections of items or entities. Software should work correctly when there are zero items, just one item, and many items.

One might want to check that:

• Pagination appears only for many listed items, and doesn't appear for 0 or 1 item

• Text is adjusted correctly based on a number, e.g., "1 passenger" vs. "2 passengers".

Or that a search:

• Shows One / Many correct results

• Shows a dedicated message "Nothing was found" in case of Zero results - arguably a better user experience than a blank page.

In other words, a heuristic is a thinking aid or a rule of thumb that relies on the tester's judgement, not a test technique such as EP & BVA or Decision Table.

Key distinction:

• Heuristics → Where to look / how to think

• Techniques → How to design specific tests

Heuristics list

There is a plethora of general and domain-specific heuristics (such as just for Web, Mobile, or Security testing). You can and should also create your own.

There is no fixed set of "official heuristics". Only those that others previously thought of, and those that you can think of yourself.

Common & Popular Software Testing Heuristics

Zero, One, Many

See the dedicated ZOMBIES page.

Beginning, Middle, End

A position/sequence heuristic for errors that cluster at the start, middle transitions, and termination points.

Examples:

• Beginning: initialization, start up, warm up errors

• Middle: state transitions, accumulation errors

• End: cleanup, finalization, overflow, truncation

Worst-case first

Focus on extreme, risky, or failure-prone scenarios early. Useful for early product discovery, tight deadlines, and regressions.

New or changed code is risky

Recently modified areas deserve extra attention. See RCRCRC.

Never and Always

The things that the software should always do (such as ensure that accounts balance) or never do (such as destroy user data). To discover the Nevers and Alwayses for your system, talk with subject matter experts and business stakeholders.

(Source: "Explore It!" book by Elisabeth Hendrickson)

If it can go wrong, it will

Question assumptions, defaults, and "should never happen" logic. Partially overlaps with Never and Always.

Assume misuse

Users will use the system incorrectly, creatively, or maliciously.

• Protect URLs from tampering (IDs, query params, path manipulation)

• Disallow unrealistically long string inputs reaching the backend or logs

• Expect missing, duplicated, reordered, or replayed requests

• Assume users skip steps, refresh at the wrong time, or use the Back button

• Assume users open multiple tabs or sessions simultaneously

• Expect copy-paste of malformed, encoded, or binary data

• Assume users try to bypass UI validation and client-side checks

• etc.

Interrupt

Interrupt while the system is doing something (loading, generating, processing, exporting) and check that it is handled gracefully. You may find:

• Unhelpful error messages

• Inability to start the process again

• Data loss or corruption

See Advanced State Testing.

Reverse & Redo

Do things in reverse order. Undo everything. Skip to the end and work backward. Particularly useful in stateful systems (sessions, caches, workflows) as well as distributed ones.

Typical defects this heuristic reveals:

• Incomplete cleanup (orphaned data, leaked resources)

• State corruption due to missing preconditions

• Irreversible actions that should be reversible

• Order-dependent bugs ("works only if you do A before B")

• Incorrect assumptions about "this can’t happen anymore"

• Inconsistent UI vs backend state

References

1. Satisfice: The Essence of Heuristics