Sanity Testing

In QA testing, we often need a quick answer 

“Is everything working fine after an update/fix or not?“ 

Sanity testing lets you quickly answer that question. You don’t run a deep analysis of your entire product, but a quick check that gives you confidence that the critical features of your software aren’t broken after changes.

In this article, we’ll break down defining sanity testing, what sanity testing is in QA, explain when it’s best to run it, share examples, and give you a ready checklist with step-by-step instructions on how to do it.

What Is Sanity Testing?

Sanity testing is a quick check you run after you make changes or fixes to your product. Its goal is to help you make sure everything works the way it was supposed to. You only check what was recently changed or where you suspect a problem, not the entire product.

From our experience, most QA issues show up right after updates. A developer fixes a bug or adds a new feature, and you need to clearly see whether the issue is truly fixed and whether anything nearby broke.

Sanity tests handle this task well. They are narrow in scope but focused in depth. Unlike a broad initial check, which looks at whether the whole product works, a sanity check covers only the modules that were touched or the areas that might be risky.

The typical result of sanity testing is simple: either you move on to deeper testing, or you send the current build back for more work. This go/no-go decision saves your team time. You shouldn’t spend hours on full QA website testing if critical changes fail.

Teams often don’t document sanity tests in advance and run them manually, especially if the checklist changes from one build to the next. These tests exist to answer one main question: Is the fix really fixed, and did it cause any side effects that affect the software’s core logic?

So, sanity testing in software testing is your way to stay confident and keep control over product quality after changes. And you need it in any modern QA workflow. 

We also want to look at the differences between testing approaches. Most often, the question comes up about sanity testing vs smoke testing. It’s simple. Sanity focuses on narrow, recently changed parts of your product, while smoke checks the basic functionality of the software as a whole.

When Should You Run Sanity Testing?

Sanity testing helps you decide whether to keep testing the build. This is especially valuable when you don’t want your team to spend hours running full regression after small changes. Below, we selected several situations where Sanity testing is a must.

Critical Bugs Were Fixed

If a developer fixed the reported issues, Sanity testing helps you make sure of the following:

• The problem was actually fixed.

• Other features still work, and nothing broke.

For example, you adjusted the login form on an online casino platform like Betsson or LeoVegas. Sanity testing checks that users can actually log in, not just that the logs show a successful fix.

After Small UI or Configuration Changes

Even when you only change minor settings of your product, like the interface or environment settings, they may have unexpected effects on visible aspects. Here, a sanity check verifies:

• Are all buttons and fields working properly and as expected?

• Are there any visual errors?

• Are all the basic user flows functioning as expected?

These are the tests that are particularly useful when you keep upgrading your product’s interface.

After Hotfixes or Patches

You should sanity test when your team is fast coming up with a fix or a patch. This guarantees the following:

• The urgent patch actually fixed the identified issue.

• Related modules were not broken and continue to work properly.

This testing is especially valuable when bugs are fixed directly in the production branch. You often see this in live iGaming or fintech products, for example, when a hotfix is deployed to a production environment at Kindred Group.

Before Full Regression

One of the main goals of sanity testing is to avoid unnecessary work for your team. It shows if changes break critical functionality. At this stage, running regression tests makes no sense. Before you move on to them, you need to get the build back to a working state.

Sanity testing can be run very frequently in Agile teams and CI/CD pipelines, with products being fixed and built on an ongoing basis. Testing assists you in discarding failed builds and selecting only those that have passed on to save time for your team.

How to Run Sanity Testing (Practical Workflow)

Sanity testing is a fast method to ensure that changes actually work and do not cause failures in critical sections of your software. The test yields a small, significant set of features associated with new changes, updates, and bug fixes. To make it easier for you to see how this works in real life, we put together a short step-by-step guide.

• Figure out what changed. The first step you are to take is to determine exactly what in your software has been altered after the latest remedies. Ask yourself these questions: Which tickets/PRs were closed? What were the affected sections of the product? This helps you pick the right tests and not waste time on those that are not.

• Identify the affected areas and dependencies. Once you decide on the changes, move on to clarifying the following points: Which specific modules and components were affected? Which related modules might be impacted, such as APIs, integrations, or configurations? Focus the test on these pain points, not cover the entire application functionality.

• Choose focused tests. At this stage, choose the set of checks you will run next: small functional test scenarios, targeted exploratory charters, or critical user paths. You aim to test your whole product and ensure that particular key features are working properly.

• Run the tests and record the results. You can run these tests manually or automate them. It all depends on how much work you have ahead. At this stage, it’s important to take screenshots, collect logs, and make notes. You must log every defect you find. This step is your sanity check. At this stage, you get a real picture of what works and what doesn’t.

• Make a decision about the next step. Next, look at the results. There are two possible outcomes. Everything works correctly, so move on to further testing. For example, you can start a full regression cycle. Reject the build and send the product back for fixes. This happens if the basic checks failed.

Remember the main rule: if the product failed sanity testing, there’s no point in spending resources on deep regression.

Sanity Testing Examples (3 Real Situations)

Sanity testing is easier to understand when you look at real cases. Below, you’ll see three sanity testing examples that show how teams handle quick fixes after bugs or changes.

Example 1 – Login Fix

Suppose a scenario: in a gambling application or a fintech app like Revolut, a bug blocked users from accessing their accounts using specific credentials. The bug was resolved, and then the sanity test was run by the QA team. The following points were checked:

• Entering the correct username and password, successful login.

• Entering a password with mistakes, the login is denied.

• Behavior of frozen or blocked accounts, if applicable to the functionality of the specific offering.

The goal of these checks is to ensure that the fix actually works and that the critical “login“ function is not broken after the release. The test results will help determine whether it’s possible to move on to full regression testing or whether it’s better to reject the build.

Example 2 – Hotfix for Payments/Checkout

Next, imagine that in your financial offering, such as a payment flow using Trustly or Adyen, the ’Confirm Order’ function stopped working after an update. This makes it simply impossible for the user to complete the critical path, so the development team releases an urgent hotfix. After that, the team runs sanity testing, within which:

• Items are added to the cart, and the process moves to the payment form.

• The “Confirm“ button is clicked, after which the user is redirected to a payment gateway such as Skrill or Neteller.

• It is checked how correctly the order data is displayed.

• If the address is incomplete or the data is entered incorrectly, full validation should be performed.

In this example, not the whole system is tested for functionality, but only the specific problem area. If the test shows a positive result, we start testing the product more deeply. If not, the product is returned for revision, and we wait for the next fixes.

Example 3 – API Changes (Contract and Authorization)

Gambling ecosystems often use API integrations, for example, in platforms like SoftSwiss, to authorize users or check their account balance. Suppose your team altered the POST /api/login endpoint in a casino platform such as EveryMatrix or added another parameter to the authorization flow. The test, in this case, should involve the following elements:

• Send a correct request to the POST/api/login endpoint and wait for a response with status and token.

• Check the response structure: field states, status, and errors.

• If this is a critical API for authorization or retrieving account data, make sure the response has not changed unexpectedly.

Such API-oriented sanity checking is important; it helps you understand that recent changes in your product have not broken the API or caused failures in integration with external systems. If the product fails the test, it is a signal to roll back the changes.

Sanity Testing Checklist (Copy/Paste Ready)

Below is a ready checklist that will help you go through the important steps and understand whether it is worth moving to deep product testing or not. This checklist is especially useful for sanity check testing in QA, when you need to confirm that all changes really work and the core functionality is not affected.

Before You Start

Gather all conditions and prepare the environment:

• Build, version, environment check. Make sure you are testing the correct build version and that the environment is configured properly.

• Understanding the scope of changes. You clearly know what exactly has changed (tickets, PRs, release notes).

• Assess risks. Which critical functions could be affected?

• Availability of test data. Are there sample data to work with?

• Criteria for sanity tests. Are they documented, or are you relying on a quick sanity check?

• Reporting method. How quickly can you communicate results to developers?

• Repeatability. Can you repeat the sanity test if needed, or will you have to choose tests again?

During Execution

Always focus on the most important things and document the results obtained:

• Focus on affected areas. Run checks only where changes occurred.

• Basic functionality check. Make sure the core logic works (for example, login, main flows).

• Integrations. In case of a change in APIs or other systems, look swiftly at the primary integrations.

• Record evidence. Screenshots, logs, and notes for each step checked.

• Detect defects. Log any found bugs immediately to speed up the fix cycle.

• Ad‑hoc checks. If something seems suspicious, check additionally, but don’t go too deep; this is sanity, not full regression.

After Execution

Summarize the results obtained to make a well-informed decision about next steps:

• Results summary. A brief record of what was verified and what failed.

• Defect report. Exact descriptions of found issues and steps to reproduce them.

• Go/No‑Go decision. Based on the sanity test, decide: Go – the build can proceed to regression or further to UAT/release. No‑Go – the build is rejected and returned for rework.

• Archiving results. Save the results for future reference to track problem patterns.

This ready-made checklist makes sanity testing clear and structured. You clearly understand what to check before, during, and after fixes. And all of this helps make well-informed decisions about further testing.

Best Practices That Make Sanity Testing Truly Useful

To make testing truly useful and deliver real results, rather than just “testing for the sake of testing,“ it is important to make it effective. Below, we have gathered key practices that QA teams have repeatedly verified on real projects, including fintech and gambling products. By using them, you can maintain a balance between speed and verification quality.

Time‑Box it (15–60 Minutes Depending on Risk)

Sanity checks do not replace regression testing. This means they should be fast and not stretch over several days. Most teams limit the test’s execution time to 15–60 minutes. It all depends on how critical the area affected by the changes is.

Focus on Impacted Modules and Critical Paths

The main strength of sanity testing is its focus on a narrow area. Choose only the areas for testing that were affected by changes directly or indirectly. Here are a couple of practical examples:

• For payments, check transaction creation and confirmation.

• For the login button, check the correctness of authorization.

• For balance applications, check how data calculation and display occur.

Check the Fix Path and Possible Side Effects

A sanity test should show not only that the bug was fixed but also confirm that the fix did not affect related functionality. For one case, when you break the balance-view in your application, ensure that the transaction history still functions as intended.

Keep a Lightweight, Reusable Test Set

Design a test set that can be readily updated when the requirements change. This method will allow you to perform testing in the shortest possible time, without irrelevant talks and amendments. The test must be brief, pertinent, and easy for all team members to understand.

Automate Repetitive Checks (But don’t Turn Sanity into Regression)

Automation saves a lot of time on routine tests, especially when changes are made frequently. But it is important not to turn it into a full regression suite. Choose only those checks that truly make sense for continuous automatic repetition.

Sanity testing works best when it is fast, focused, and practical. It gives confidence that key changes have not broken your product’s functionality, while avoiding unnecessary checks that waste your company’s resources.

Common Mistakes in Sanity Testing and How to Avoid Them

Even experienced teams sometimes turn sanity testing into something that has no effect. For testing to actually work and provide quick signals, you should avoid common mistakes.

1. Doing “everything at once“ (turning sanity into regression). One of the most frequent mistakes is trying to cover too much. When the test set includes tests for everything at once, sanity stops being quick and focused. As a result, it becomes almost a full regression run, which can take hours. To avoid this, focus only on areas affected by changes and their closest dependencies.

2. Skipping dependencies and integration points. In other cases, testers fail to test related modules or APIs that might have been indirectly influenced by changes. This oversight may result in bugs coming up later, during regression testing, and, in production, even worse. Consequently, key dependency checks should be provided, particularly when modifications were done on interfaces between components.

3. Lack of exit criteria and weak reports. If the team does not define in advance what counts as a “successful“ sanity test, or does not make clear notes on exactly what was checked and what the results are, decisions about further testing become subjective and risky. Standardize exit criteria and keep short reports; this increases transparency and speeds up decision-making.

4. Mismatch between test scope and changes. Sometimes tests stay the same even when changes concern completely different functionality or logic. This means the sanity check becomes outdated. Regularly update the test set to directly reflect the current changes in the code or requirements.

Sanity Testing in Agile and CI/CD Pipelines

DevOps Agile, and teams are the modern-day, and QA testing of websites is part of the quality software delivery process. It helps quickly determine whether to continue with deeper checks or reject the build. The main idea is to fit a sanity check between other tests so that it gives a quick go/no-go answer after changes.

Where It Fits

One recommended workflow looks like this: build → smoke → sanity → regression (as needed). First, CI/CD deploys smoke testing as soon as the build is complete to ensure the build is stable and to determine whether it is worth continuing testing. In case passed smoke, sanity testing is used, and given particular changes, bug fixes, or minor upgrades. When a successful sanity check has been done, the team will then run more significant regression tests.

What’s Important to Track

When implementing sanity testing in Agile/CI pipelines, it’s useful to track the following metrics:

• Defect leakage. How many defects “slip“ into later stages or production after the sanity test? This helps understand how well tests catch errors early.

• Re‑open rate. The percentage of defects that are reopened after fixes. A high rate may indicate a weak sanity check.

• Time‑to‑validate. How long does it take from receiving the build to making a go/no‑go decision? This metric is important in Agile, where release speed is high and quick decisions are required.

In the end, sanity testing is a quick filter between smoke and regression that saves team resources and speeds up the CI/CD cycle, preventing unnecessary issues from reaching production.

Conclusion

Sanity testing is a fast and effective way to make sure that critical changes work and the system remains stable. It helps you save your team’s time, catch bugs early, and make confident decisions about further testing. By using focused sanity checks, your QA team minimizes the risk of regressions and speeds up releases.

If you want to implement sanity testing in software testing projects, whether in fintech or gambling, you can get professional support right now by using the Contact Us form. Our experts will help set up the process and make checks fast and reliably.