logo logo

Software Testing Heuristics

Software Testing Heuristics

When you come across an application that you have never tested and don’t have much information about, how would you test it? Each person has a way to start testing applications. You will probably start by exploring it, in order to learn how it works. But surely you will list some actions that you would make in your test while exploring. This is the base of a heuristic. In this context, software testing heuristics are important in times of uncertainty, when you are not sure how to start. Its a guide that helps you get test ideas 💡

In this article, you will understand what a heuristic is, and why you should use heuristics in the context of software testing. The concept of mnemonics and the most known software testing heuristics will be presented. Finally, you will learn step by step how to use a software testing heuristic, how to create your own heuristic, and you will have access to a set of software testing heuristics that will be essential in your life as a QA from now on.

What Is a Heuristic?

There are a few definitions explaining what a heuristic is 📖

“A method of learning or solving problems that allow people to discover things themselves and learn from their own experiences.” – Cambridge Dictionary

“Heuristics defines a problem-solving technique in which the most appropriate solution is selected at successive stages of a program for use in the next step of the program.” – Science Direct

“Principles which reduce the complex tasks of assessing probabilities and predicting values to simpler judgmental operations.” – Amos Tversky and Daniel Kahneman

We can summarize these definitions by saying that a heuristic is a cognitive shortcut.


Why Should We Use a Heuristic in a Software Testing Context?

Since a heuristic is a cognitive shortcut, it can be easily applied in multiple areas, including in software testing. The main idea of using heuristics is when we have to solve problems and make decisions under uncertainly conditions.

Imagine yourself in a situation where you need to test an application that you have never seen before, and there is no documentation that can help you. Where should you start? What kind of test should you do? What data should you use? In which order it is interesting to be tested? 🤔

You can learn what is interesting to try and how to try. You can use heuristics created specifically for the software testing area. These are called software testing heuristics.



Mnemonic is a group of characters which is formed by the first letter of each principle of your heuristic. A mnemonic helps you to remember the principles of a heuristic in an easier way. For example, imagine a hypothetical heuristic that gives you test ideas related to positions of something: Top, Right, Bottom, and Left. You can use the TRBL mnemonic to remember each of the words in this heuristic.

Another example: Imagine other hypothetical heuristic that also gives you test ideas related to positions of something: Outside, Near, and Entrance. You can use the mnemonic ONE (that forms a known word) to remember the principles of this heuristic.

As can be seen, a mnemonic can form an acronym, or it can form a familiar word. Mnemonics are widely used due to our brain’s great memory capacity.


Well-Known Software Testing Heuristics

There is a long list of software testing heuristics that can be found on websites, blog posts, presentations, and books. In the photo below I present four of the well-known heuristics in software testing, and they can be applied without any difficulty in your testing activities, and in your exploratory testing cycles 🔄

Well-known Software Testing Heuristics


Context: Things that can be counted

This software testing heuristic helps us with the test ideas in areas you can count on. In this way, you can vary the way you test based on a few ideas 🔍

Zero, one, many

  • Use functions you can get 0, 1, and many records.
  • Examples
    • 0 – Search for a non-existent user;
    • 1 – Search for a specific user;
    • Many – Search for last name that returns many records.

Too many and too few

  • Use functions you can associate too many or too few records of one type.
  • Examples
    • Too Many – Sale with many products;
    • Too Few – Sale with few products.


Context: Input data

This heuristic comes from the British fairy tale called ‘Goldilocks and the Three Bears 🐻 This story is about a girl named Goldilocks which found three bowls of porridge: the first one is too hot, the second one is too cold, and the third is just right.

If you bring it into the software testing universe, this can be translated to “too big, too small, or just right”. The idea is that input data with values ​​that are too big, too small, and just right can be explored.

  • Examples:
    • Too Big – Test with 1000 characters a field that has a limit of 100 characters;
    • Too Small – Test with 1 character a field that has a limit of 100 characters;
    • Just Right – Test with 100 characters a field that is limited to 100 characters.


Context: Registration tests

CRUD (Create, Read, Update, and Delete) software testing heuristic is probably the best known of all. This heuristic has test ideas: create records, read/search records, update records, and delete records ⏺

  • Example: Imagine a hypothetical scenario of a user registration feature, we can use the CRUD heuristic to perform the following tests:
    • C – Create a user;
    • R – Get a user record / Search for a user;
    • U – Update the registration of a user;
    • D – Delete a user’s registration;


Context: Regression Tests

RCRCRC (Recent, Core, Risky, Configuration, Repaired, and Chronic) software testing heuristic is related to ideas for testing an application from a regression point of view. It helps us to remember:

  • R – New features or new areas of code that have been added.
  • C – Critical functions or features that must continue to work.
  • R – Features or areas that are inherently riskier.
  • C – Code that is sensitive/dependent on environment settings.
  • R – Code that has been changed to fix defects and may have caused issues.
  • C – Code that could be chronically breaking or having issues.


Steps to Using a Software Testing Heuristic

It is very simple to use a software testing heuristic. However, it makes sense to structure the use in three steps that will guide us, in order to better use a heuristic ✅

Steps to use a Software Testing Heuristic


Identify the context you want to test. What kind of application, what kind of functionality, what requirement? It is very important to have full visibility before starting.


Choose the software testing heuristic that best fits to your context. You can look at a heuristic and analyse “What do I see in these principles that fits to what I am going to test?”. You can use a heuristic completely, you can use part of a heuristic, you can adopt a heuristic, you can create your own heuristic. Use it your way 💪


After understanding the context and selecting the heuristics, you should set up an exploratory test cycle to test your application. You can have an exploratory test cycle for the entire heuristic, or you can have a cycle for each principle of your heuristic.


Create Your Own Software Testing Heuristic

If a software testing heuristics is something that can provide ideas that guide a person to test an application, it might make sense that you create your own one. That way these test ideas are reusable, either for your own use at another time, or to share with others who also have no idea how to start testing a particular type of application.

Everything that is done in testing can become a heuristic, from activities that are performed before and during a software test cycle, to ideas on how to test an application or a feature.

To create your own software testing heuristic, just follow these three steps 3️⃣

Create your own Software Testing Heuristic

Identify Patterns

Considering that a software testing heuristic helps us to remember things we should test and therefore we will repeat, identifying patterns in your testing sessions is the surest way to create a new heuristic. You can think about why you ran some type of tests, think about why your actions were done in a specific order, and then try to identify patterns that you have in those actions.

A good tip to make it easier to identify patterns is to take good notes of what is done in your testing sessions and reflect soon after running a session. This will help you find patterns more easily. I suggest reading a little about the concept of Testopsy, which can help in this review.

Create Easy to Remember Words or Sentences

Using the identified patterns, create terms (words or sentences) that easily help you to remember the test idea.

Create a Mnemonic

Create an acronym or a word that represents the principles of your heuristic. It will be easier to memorize and remember when you need to use it.


Software Testing Heuristics Cheat Sheet

There are a lot of software testing heuristics cheat sheets available. In this article, I would like to share two of these cheat sheets 🧾

The first one is Testing Mnemonics:


The second and widely used one is the test heuristics cheat sheet, which includes ideas from Elisabeth Hendrickson, James Lyndsay, and Dale Emery.

I also want to recommend the book “Explore It!” by Elisabeth Hendrickson, which contains a lot of software testing heuristics in a wonderful cheat sheet that can be easily used in your daily activities as a QA 👩‍💻



In this article, you can learn what a heuristic is and why it should be used in the context of software testing. You also had the opportunity to learn about the best-known test heuristics. In addition, I provided step-by-step instructions for using a heuristic, as well as how to create your own one.

Take a new step in your career as a QA with this problem-solving technique, to help you come up with ideas of what to test when faced with uncertainty 🧐

About the author

Paulo Oliveira

I’m a proactive, cooperative, and responsible Quality Assurance Engineer with more than 14 years of experience in software testing. I love to automate tests for all kind of applications (both backend and frontend) in order to improve the team’s workflow, product quality, and customer satisfaction. Even though my main roles were hands-on testing applications, I’ve worked as QA Lead, planning and coordinating activities, as well as coaching and contributing to team member’s development. Mentoring people to achieve their goals is also something that makes my eyes shine.

Website- https://paulocoliveira.github.io/qa/

LinkedIn- https://www.linkedin.com/in/pcesar/

Leave a Reply