> For the complete documentation index, see [llms.txt](https://practical-testing.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://practical-testing.gitbook.io/home/testing-practices/applying-heuristics.md).

# Applying Heuristics

### Definition & an example

According to Rapid Software Testing Approach<sup>1</sup>, 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 passenger<mark style="color:$warning;">s</mark>".

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](/home/techniques/ep-and-bva.md) or [Decision Table](/home/techniques/decision-tables-and-trees.md).&#x20;

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.

{% hint style="info" %}
There is no fixed set of "official heuristics". Only those that others previously thought of, and those that you can think of yourself.
{% endhint %}

Common & Popular Software Testing Heuristics

#### Zero, One, Many

See the dedicated [ZOMBIES](/home/test-automation/test-with-zombies.md) page.

#### Beginning, Middle, End

A position/sequence heuristic for errors
&#x20;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&#xD;

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

#### New or changed code is risky

Recently modified areas deserve extra attention. See [RCRCRC](/home/testing-practices/do-regression-testing-rcrcrc.md).

#### 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&#xD;

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

#### Assume misuse&#xD;

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](https://practical-testing.gitbook.io/home/techniques/state-based-testing#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](https://www.satisfice.com/blog/archives/462)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://practical-testing.gitbook.io/home/testing-practices/applying-heuristics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.