API Testing Mnemonics: A Practical Guide

What is a heuristic?

A heuristic is a mental shortcut or a rule of thumb. It's a quick way to think through a problem or a gateway to get to deeper thinking.

What is a mnemonic?

A mnemonic is a memory-enhancing tool or technique that helps individuals retain and recall information by connecting new data to familiar patterns, images, or structures. A mnemonic is a very simple heuristic. The most common mnemonics you may remember from childhood are My Very Educated Mother Just Served Us Nachos as a way to remember the order of the planets from the sun. A mnemonic could also be a jingle or a chunk of information used to remember a phone number.

How can mnemonics be used to test?

Mnemonics can be thought of as shortcuts to get to deeper testing. They are easy to remember and nudge you towards areas of the API you may know less about. Testing is about gathering information about the state of something, and these heuristics will hopefully lead you to better information than randomly clicking or following a strict set of rules.

Don't think that testing should be limited to these mnemonics — it's the complete opposite. As someone with agency, you are encouraged to come up with your own mnemonics and testing strategy that works for you and helps improve your mental model.

A word of warning. Heuristics are great, but they are a double edged sword. The more you approach a problem in the same way, the more you are at risk of missing areas of the system that could also have bugs. Testers should always be looking at new ways to test and improve their skills, but remember that a heuristic is also a bias. These are very by definition NOT "best practices".

That being said, let's dive into the mnemonics.

CRUD

Create, Read, Update, Delete

This mnemonic is very helpful when testing something like an API or a web app. It doesn't encourage much deep thinking, but it gives us a direction of where to look. From there we can ask deeper questions such as:

• What happens if I try to access the same resource twice?
• What happens if I try and delete a resource?
• Should I be allowed to update X resource?

And so on.

BINMEN

Boundary, Invalid, Null, Method, Empty, Negative

BINMEN is more specific for APIs and can be applied to payloads, parameters, headers and URIs. Even just starting at the first letter, there are lots of questions that should be in the front of your mind. What boundaries are there? Are they explicitly documented anywhere or just assumptions? What happens if I breach the perimeter of the boundary? BINMEN can also be used through a UI as well, as it should get you into interesting areas of the software.

Read more on BINMEN

VADER

Verbs, Auth, Data, Error, Response

VADER is also an API-specific mnemonic (that can be applied elsewhere) that covers a bit more ground than CRUD. When it comes to verbs we can look at the most common, but we can also check lesser known verbs such as HEAD (shows only the headers) and OPTIONS (shows the available verbs).

Verbs

• What verbs should anyone be able to access? What verbs should no one be able to access? Are there pre-flight requests involved when talking to the API?

Auth

• What authentication method are we using? What happens if no authentication method is used? What happens if we use expired tokens / keys? What happens when a different web client accesses the resources? Do we have auth headers as well?

Data

• Do we have a swagger we can reference for the API contract? How strict are the data types we're using? Should we be using strings everywhere? Why aren't we nesting this value? Why is this value nested? How much data can the API handle? Is pagination part of the API? Do we support other data types like CSV or XML as well as JSON?

Error

• Are the 4XX errors readable? Do we give the users notice of why the API request failed? How does the front-end / UI display errors in the API?

Response

• Should we always return a 200? How long should a request take? Do we have timeouts that we need to consider?

Further reading: VADER: A REST API Test Heuristic

POISED

Parameters, Output, Interop, Security, Errors, Data

POISED is one of my favourite mnemonics, because it is more aimed at looking for trouble, rather than just gathering information. Although some of the letters can be generic (such as security — a huge topic) it can lead you to look more into APIsec OWASP or how you can test your current API's authentication. The only issue I have with POISED is that I often forget what the letters represent — this is why I sometimes write it down before a test session that I know requires deep diving and looking for elusive bugs.

• P — Parameters: What parameters does the API accept? Are they validated? What happens with unexpected or missing ones?
• O — Output: What does the API return? Is the response format correct, consistent, and well-structured?
• I — Interop: How does the API interact with other systems? Does it play nicely with different clients, versions, or integrations?
• S — Security: Is authentication and authorisation working correctly? This can lead you toward APIsec, OWASP API Security Top 10, and how your API handles sensitive data.
• E — Errors: How does the API handle failure? Are error codes meaningful, consistent, and not leaking internal information?
• D — Data: What data is being sent and received? Is it validated, sanitised, and in the expected format?

ICEOVERMAD

Integration, Consumers, Endpoints, Operations, Volume, Error Handling, RESTful, Modularity, Authentication, Definitions

This one was new to me until recently. It was invented by someone known as @northern_tester and I actually really like what this mnemonic represents. It's focused on principles I consider important in API testing — particularly how an API is consumed by end users and how we can frame the information we gather while testing.

• I — Integration: How will consumers integrate with the service? When? Is it browser-rendered or file-based?
• C — Consumers: Who is consuming the service? Is the end user a human or a machine? What problem does it solve for them?
• E — Endpoints: What form does the endpoint take? Single, multiple, or load-balanced? What security is applied?
• O — Operations: What business functions does the service perform?
• V — Volume: How does the service handle load and data volume?
• E — Error Handling: How are errors surfaced and communicated?
• R — RESTful: Does the API adhere to REST principles?
• M — Modularity: Is the API well-structured and loosely coupled?
• A — Authentication: How is access controlled and verified?
• D — Definitions: Is the API well-documented? Is there a contract (e.g. OpenAPI/Swagger) to test against?

What makes ICEOVERMAD stand out is its consumer-first perspective. Where BINMEN focuses on inputs and VADER covers the HTTP layer, ICEOVERMAD asks you to step back and think about the bigger picture — who uses this API, how they integrate with it, and whether the documentation matches reality.

How to use these mnemonics together

These mnemonics aren't mutually exclusive — they complement each other. A good approach is to start broad and get more specific:

1. CRUD to map out the basic operations you need to cover
2. VADER to work through the HTTP layer systematically
3. BINMEN to stress-test your inputs on payloads, parameters and headers
4. POISED when you want to shift into an adversarial mindset and look for security and data issues
5. ICEOVERMAD when you want to zoom out and consider the API from a consumer and integration perspective

None of these replace exploratory thinking — they're prompts, not scripts. The goal is to use them as a launchpad, then follow your curiosity wherever it leads.