Today is your first day of switching to a new project. You have been testing your previous application for almost a year and you are not an expert but an advocate of the application. However, today you are going to be an apprentice in this new project.

The first thing you would do is explore the application to get an insight into how it works. While you are exploring the application, you may take some notes. This is the starting point of heuristics. Software testing heuristics play a major role during such uncertainties.

In this article, we will discuss what heuristics are, why we should rely on heuristics for software testing, and how to practically use heuristics for testing.

What Are Heuristics?

Heuristics is a word that comes from Greek which means ‘*Serving to Discover*’, a way of generating educated guesses. In other words, it is a process that allows us to learn by predicting and allowing us to select the most appropriate solution to be used in the next step.

In simple terms, when there are large amounts of information with numerous amounts of choices, for the human brain to make decisions, the brain adopts to make decisions based on past experience.

As you are aware, software testing is a stressful task that involves lots of critical thinking. The stress comes due to several factors like time limitations, application complexities, limited information, and so on.

In scenarios where there is limited information, we can apply heuristics specially designed for application testing known as software testing heuristics to reduce stress and overcome time constraints.

Common Software Testing Heuristics

While there are numerous software testing heuristics, below I have listed the most used heuristics.

• RCRCRC
• CRUD
• Goldilocks
• FEW HICCUPPS

Let’s look at each of them with some real-world testing examples.

RCRCRC

The mnemonic is RCRCRC used to remember the heuristic that helps in regression testing. Each letter represents a word that unveils testing ideas.

• Recent – what new changes have been added to the code base and what should be focused on testing due to the change.
• Core – What critical components of the application have been impacted and should be tested.
• Risk – What features are at risk and should be well tested.
• Configuration – What should be tested to verify environmental dependencies.
• Repaired – What code has been changed due to defect fixing and what testing should be carried out based on the fix.
• Chronic – From the seven testing principles, if you re-call defect clustering, chronic refers to the same point. There are features in the application that often break. What features need more focus.

Now let’s cover this heuristic with a real-world example.

Assume you are working on an e-commerce application that sells consumer goods.

• R - Recently you started accepting payments via PayPal. Hence you need to thoroughly test the PayPal integration.
• C – As an e-commerce application, Product search functionalities, Customer management, and Payment processing are the core functionalities you need to focus on where the revenue generation path lies.
• R – The Shopping Cart and Checkout should be tested thoroughly since there is a risk of having bugs due to the new PayPal integration.
• C – Verify the PayPal and other third-party integrations as they are managed via configurations based on the environment.
• R – During this release, you have fixed some bugs related to stock management and hence you need to test the functionality around the stock management.
• C – When looking at the past bug history, you have identified most of the bugs have been reported around monthly sales reports. Hence the defect clustering occurs around sales reports, and you may need to focus on that too.

CRUD

CRUD stands for Create, Read, Update, and Delete, which reflects the life-cycle of data.

Let’s start with a practical application. Assume in your e-commerce application, you recently developed a feature for the registration of vendors. Now you need to test this feature.

• C – Creation of vendors.
• R – Filter or Search-created vendors in the application.
• U – Verify a created vendor can be updated.
• D – Verify a created or an updated vendor can be deleted.

Each operation may come up with business rules with the business requirements. This is a generic heuristic to test the life-cycle of data that can be improved for specific scenarios.

Goldilocks

This heuristic focuses on the idea of too big, too small, and just right which means testing boundaries. Goldilocks works well with data entry fields where we need to verify character constraints.

Phone numbers, tax identification numbers, and driving license numbers are some of the good examples that can be tested with Goldilocks.

Assume, the tax identification number should have 9 characters. We can derive different testing scenarios with the help of Goldilocks, like

• When entering characters less than 9.
• When entering characters more than 9.
• When entered exactly 9 characters.

FEW HICCUPPS

When there is little to no specification available, this heuristic comes in handy.

• Familiar – The system is expected to be consistent and familiar.
• Explainability – The system is expected to be understandable and able to explain its behaviour.
• World – Consistency with the things that we are aware of.
• History – Consistency between present and past versions of the system.
• Image – Consistency of an image with the brand and its reputation.
• Comparable Product – Consistency with systems that are in some way comparable, like products in the same product line or competitive products, services, or systems.
• Claims – Consistency with references, specifications, design documents, public announcements, meetings, and so on.
• User Expectations – Consistency with the expectations of users.
• Product – Consistency within the elements of the system.
• Purpose – Consistency with the explicit and implicit uses.
• Standards – Consistency with the industry standards.
• Statuses – Consistency with laws and regulations.

Let’s try to apply this in a practical scenario. You are launching an upgraded version of your e-commerce application and I am sure you are aware of the challenges technical teams face when launching groundbreaking changes.

• Familiar – Let’s say you changed the menu navigation in your recent deployment, so it is better to verify the impact on the unfamiliarity or any concerns faced by existing users.
• Explainability – In your e-commerce application, you are planning to introduce a new fast payment system. Users always have second thoughts when carrying out transactions and hence as testers, we need to evaluate self-explainability in such cases for wide adoption of users, especially in terms of security.
• World – With the new upgrade you are enhancing the user interface to provide a better experience for the users. When we are testing, we need to focus on generally accepted standards such as showing appropriate messages when required, for instance when a form is submitted, it is necessary to display a success or a failure message with the right content.
• History – More focus should be placed on the paths of the application. For instance, if you change the process of placing an order, you may need to revisit if that change aligns with the previous versions of the application or on the other hand what value the new implementation offers if it deviates.
• Image – you are re-branding your product with the upgrade and now we need to validate if the new brand logo and colours align with the image that the product has created over the years.
• Comparable Product – In order to compete with the market, you should verify  if the application possesses the features that the rest of the applications in the market have.
• Claims – Assume, the new payment system experiences a performance issue when there is considerable load in the system. That should be communicated to the respective teams and may need to be announced during the release to set the right expectations for the customers.
• User Expectations – With the previously collected data, you need to validate if the users' expectations are met with the new upgrade such as a faster and easier payment system, and modern user-friendly intuitive interfaces.
• Product – This is more biased towards testing the usability of the application. As a tester, we need to validate if the new user Interfaces implemented, aligns with the other interfaces, colours, and typography of the application.
• Purpose – The new payment mechanism you are rolling out should be cross-verified if the functionality offers users faster hassle-free payment processing without bombarding security.
• Standards – Verify compliance with the coding standards and guidelines and follow best practices like code readability, maintainability, and so on.
• Statuses – Check if the application adheres to laws and regulations like GDPR, especially when collecting data from users and define our terms and conditions.

In conclusion, heuristics is our savior to eliminate distractions and obstacles and guide us when there are numerous amount scenarios to perform during our testing.

By employing defined testing heuristics like RCRCRC, CRUD, Goldilocks, and FEW HICCUPPS, testers can address various scenarios of an application from regression testing to data life cycle validation and boundary testing.

Ultimately, integrating heuristics into your testing process will improve your ability to discover defects earlier in the life cycle and contribute more effectively to the success of your projects.