Sanity Testing: Examples, Checklist, and Best Practices

OVERVIEW

In the fast-moving world of software delivery, every build carries the risk of breaking something that worked yesterday. This is where Sanity Testing steps in. It is a quick, focused quality check that answers one critical question: Is the build stable enough to proceed?

Sanity testing is like a quick health check for your software. It helps teams save time, build confidence, and avoid unnecessary full-scale testing when just a few parts of the system need validation.

Let's explore what sanity testing is, how it works, and why it is an essential part of your QA strategy, especially in agile and CI/CD environments.

Sanity testing is a subset of regression testing, performed to verify that a specific part of the application works correctly after changes such as bug fixes or small updates. It focuses only on the affected areas, checking if the changes meet requirements and if no dependent functionality is broken.

These points highlight how sanity testing serves as a fast and targeted quality check. Instead of re-running the full regression suite, it focuses only on verifying the most critical areas impacted by recent changes.

• Verifies basic commands and functions: Confirms that the primary actions or features in the updated area work as expected after changes.
• Performed when testing time is limited: Ideal for situations where deadlines are tight, allowing testers to check only the most important functionality.
• Usually non-scripted and quick: Carried out using the tester’s knowledge and intuition rather than detailed test cases, which speeds up the process.
• Ensures changes meet user expectations: Checks whether updates or fixes deliver the intended improvements for the end user.
• Checks minor bug fixes and essential functionality: Validates that small issues are resolved without affecting other dependent features.
• Performed after major changes or critical modifications: Useful for confirming that significant updates have not compromised the stability of the application.

Sanity testing plays a key role in quickly validating new or critical functionality after changes, helping decide whether deeper testing is worth the effort. It saves time, avoids unnecessary work, and ensures issues are caught early.

Here, we will understand why we should not neglect or avoid doing sanity testing

• Saves time : If sanity testing fails, there’s no need for lengthy regression or end-to-end testing as defects are sent directly to developers.
• Quick evaluation: Focuses only on the impacted features, using an intuitive, non-scripted approach for faster results.
• Reduces effort: Helps decide if further testing is necessary, avoiding wasted resources.
• Improve regression testing: Detects critical issues early, allowing regression tests to focus on stable builds.

However, with sanity testing, we can perform quick and superficial checks on the important features of software applications. Thus, testers quickly identify the major issues without checking the entire suite of test cases. Hence, the sanity test is a supplement to the retesting process.

• Finds build and deployment issues: Quickly identifies missing resources, compilation errors, or environment problems.
• Gives release readiness status: Provides a quick health check on the release, guiding next steps in testing and development.

Sanity tests allow developers and testers to validate their use in the Software Development Life Cycle. In line with this, here are two critical priorities of the sanity test.

• Sanity test cases use standard functionality, delivering high software project value to enhance user experience.
• Sanity test cases are selected based on regression tests to fulfill the Software Requirement Specification (SRS).

Apart from its set priority, the sanity test also has specific goals that the developers and testers must ensure. Some of those goals are as follows:

• To define the expected working of upcoming features.
• To save time and cost when the sanity test fails for a build.
• To ensure new updates do not lead to any changes in the existing function of the software.
• To validate the reliability of newly added features.

Now deep dive into more details on the sanity test and understand this with examples.

The sanity test is an essential component of software testing and is regarded as an initial step in the quality assessment of software applications. However, for perfect execution in the software development process, it is crucial to have sound knowledge of its characteristics.

Some of those are as follows:

• Part of regression testing: Sanity testing checks small but critical components after changes are made, ensuring they work before running a full regression test. It focuses only on key features affected by updates, making it a subset of regression testing.
• Unscripted: No predefined scripts are used. Testers rely on their experience to validate essential functions impacted by recent changes, ensuring flexibility in the process.
• Narrow and deep: The sanity test focuses on a limited set of complex or crucial functionalities or aspects of the tested application. However, the test of such functionality and aspects are done thoroughly.
• Minimal setup: Execution of the sanity test only requires basic data set-up and configuration.
• Pass and fail criteria: The sanity test gives pass or fails criteria, which are easily assessed.
• Repeatable: The sanity test can run in repetition with a similar outcome to confirm the correct working of the software application.
• Executed by testers: A sanity test is usually done by testers because this requires an understanding of software testing and technical expertise.

To practically implement the features mentioned above, sanity tests are required in various test environments to ensure the software application functions correctly.

The sanity test focuses on one or more important functions in the testing software applications. It needs to be performed in different scenarios. Some of those are as follows:

• In a situation when small changes in the application’s code are made.
• When new features are added and ready to integrate into the software application.
• After a number of regressions test is done, and the new build is generated.
• Post bug fixes.
• Prior to production deployment.
• Before integrating features in the software application.

However, how often should we perform a sanity test in a Software Development Life Cycle? Well, it depends on your requirement and the complexity of the software application. As we have addressed the goal and priority of the sanity test, we will now understand the frequency of performing the sanity test.

The frequency to perform sanity tests is based on the Software Requirement Specification (SRS) and software development stage. Imagine you are in the software development team aiming to develop an application that performs as per user expectations.

Statista projected worldwide mobile application revenue to reach around $613 billion by 2025, which shows how much rides on every release working correctly.

You are aware of the high revenue growth and highly competitive market. This necessitates testing the new software application to ensure its proper functioning and no error on its release. Thus, you should perform sanity tests during the early stages of software development to ensure it works post-new build. This needs to be continued several times as you improve or edit the code or add new features to the software application.

A sanity test is mainly executed to verify whether the added functionality does not give errors in existing features. Further, it also validates that the system is in a “sane” state for moving ahead with future testing.

As the software application becomes stable, the number of times the sanity test should be performed decreases. However, it should be done whenever you need to perform sanity tests. This is only to fulfill the goals mentioned earlier.

In a nutshell, the frequency with which sanity tests are performed is determined by the specific need of the software application, the stage of software development, and the number of time changes made to the application.

You may ask why we need to perform a sanity test for a software application. It is a crucial part of testing software applications and ensuring their quality. However, its significance is not just limited to this.

The sanity test quickly evaluates the quality of a changed build and decides whether deeper testing is worth running. Two concrete scenarios show exactly what a sanity test does and does not cover:

• E-commerce discount code fix: Users report that a valid discount code fails at checkout. Developers ship a hotfix, and the sanity test verifies exactly three things: the previously failing code now applies correctly, the order total recalculates with the discount, and an invalid code is still rejected. The tester does not re-test search, product pages, or shipping, since those modules were untouched.
• Profile image upload fix: A bug fix restores the broken profile image upload. The sanity test uploads a valid image and confirms it renders on the profile, then checks the adjacent dependencies: the thumbnail updates in the site header, and removing the image reverts to the default avatar. If the upload works but the header thumbnail breaks, the sanity test fails and the build goes back to development.

Both examples follow the same pattern: verify the fix itself, verify its immediate neighbors, and stop. The sanity test only checks the modified or defective components and their direct dependencies. It does not check end-to-end functions.

A sanity test can be a helpful approach to get new functionality checked in less time. However, specific challenges with sanity tests cannot be ignored. Some of those challenges are:

Challenges:

• Limited Scope: Focuses on specific areas, so it may miss hidden issues or give false positives.
• Incomplete Coverage: Only provides a quick check, not a full analysis.
• Time Constraints: Often performed under tight deadlines, which can affect accuracy.
• Restricted Environment: Tests are run in a controlled setup that may not match the real production environment.

Solutions

• Prepare a clear test plan and review the Software Requirement Specification (SRS) before starting.
• Combine sanity testing with regression or other rigorous tests for better accuracy.
• Document the process and promptly share issues with the development team.
• Understand the difference between sanity and smoke testing to avoid confusion and ensure correct execution.

Most of the time, we are confused between Smoke Testing vs Sanity Testing . Smoke and sanity tests quickly check a software application's core function. They seem similar but differ in scope, objectives, and timing to perform tests within the Software Testing Life Cycle. The table below draws the clear difference between sanity and smoke tests.

Both sanity and smoke tests are crucial to develop a software application project. Which one should be executed first? Its answer is simple. The smoke test is executed first and then proceeds to the sanity test. However, their position in the Software Development Life Cycle is different.

Sanity testing is a subset of regression testing, so the two are often confused. The practical difference is scope and cost: a sanity test answers "did this change break its own area?" in minutes, while a regression suite answers "does the whole application still work?" in hours.

The two work as a sequence, not alternatives: a failed sanity test rejects the build before any regression time is spent, and a passed one is the entry ticket to the regression suite.

The technique is uncontroversial; the name increasingly is not. Because "sanity" frames correctness in mental-health language, many engineering organizations and style guides now prefer neutral alternatives, and you will see the shift in documentation, code review comments, and job descriptions.

Common replacements, all describing exactly the same quick verification:

• Confidence check: the most widely adopted alternative in engineering teams.
• Quick verification: plain-language, common in process documents.
• Rationality check / coherence check: used where the check validates that outputs are plausible rather than exact.

Is it okay to still say "sanity check"? It remains the dominant industry term and appears throughout tooling and documentation, so you will keep encountering and using it. If your team or client prefers inclusive language, "confidence check" communicates the same intent with no loss of meaning, and nothing about how the test is performed changes.

Sanity testing takes place in the testing phase of the Software Development Life Cycle, which follows a deployment phase. Under the testing phase, it is a part of functional software testing and is executed after minor changes or bug fixes in the software build.

A sanity test is mainly done after unit, integration, and system testing. As the software application passes an initial phase of testing, a sanity test is executed to validate whether changes or fixes made in the application caused any new issues or bugs.

On completion of the sanity test, acceptance testing occurs, where the end-user tests whether it meets the Software Requirement Specification (SRS).

The sanity test is known to test the specific functions of the application. However, other aspects of software applications are tested in sanity testing. Some of those include the following:

• Basic function: The tester performs a sanity test to check the basic working features of the application as per user expectations. For example, if you want to verify the launch of the application, you should check the functionality of the user interface, like button navigation, etc. In such a test scenario, sanity testing evaluates those with accuracy.
• Data integrity: Testers verify the provided data's accuracy and retrieval in the software application.
• Security: Sanity testing checks the basic features like data encryption, user authentication, and access control of the software application.
• Compatibility: Sanity tests also check for the compatibility of the software application across different browsers, devices, and OS configurations.
• Performance: Sanity tests validate the application's performance under complex environments.
• Error handling: It refers to how the software application handles errors and exceptions during its execution. Sanity test checks for the error-handling capabilities of the software application by intentionally introducing errors or exceptions in the system and verifying that the application can handle them properly.
• Install and Uninstall: The sanity test checks whether an application can be installed. This involves ensuring a smooth installation process and how software runs after installation.

To determine the critical functionalities of the software application, a sanity test follows three steps, which are as follows:

• Identification: In the first step, new functionality and features are identified. Additionally, while fixing bugs, new modifications presented in the code are found. This shows that we are required to determine the scope of the sanity test in terms of changes to be made in the software application.
• Evaluation : In the next step, you have to evaluate and modify the new components of the software application to ensure their functioning is in line with the Software Requirements Specification (SRS.)
• Testing: The final step is testing, where a small part of the newly associated components of the application is tested in-depth.

We have two approaches to practically implement the above steps: manual testing and automation testing. Choosing the type of approach depends on the requirement or specification of the application or the bugs identified.

Because a sanity test is unscripted, teams need explicit conditions for when it starts and when it stops. Without them, the quick check either runs on an unstable build (wasting the effort) or drags into an informal regression cycle.

Entry criteria (all must hold before the sanity test begins):

• The build has deployed successfully to the test environment with no installation or compilation failures.
• The smoke test has passed, confirming the application launches and its core paths respond.
• The change is documented: the bug fix, hotfix, or minor code change is listed with the modules it touches.
• Required test data and environment configuration for the affected area are in place.

Exit criteria (any one ends the sanity test):

• Pass: all modified features work correctly, adjacent dependent features are unaffected, and the build is cleared for the full regression suite.
• Fail: a critical blocker is identified in the changed area, so the build is rejected back to development immediately and no further testing effort is spent on it.
• In both cases the verdict and evidence (screenshots, logs) are recorded and shared with the team.

Even though sanity testing is largely unscripted, a lightweight test case definition keeps the check consistent across testers. A sanity test case needs only five parts:

• Objective: the specific change under verification, stated in one line (for example, "discount code SAVE10 applies at checkout after hotfix #4521").
• Precondition: the build number and environment the entry criteria were met on.
• Steps: the shortest user path through the changed functionality, typically 3 to 6 steps.
• Expected result: the observable behavior that proves the fix works.
• Verdict: pass or fail, with a screenshot or log attached as evidence.

Reusable sanity testing checklist, run it against every changed build:

• Identify the modules impacted by the change from the commit or release notes.
• Verify the reported issue the hotfix targets is actually resolved.
• Check adjacent dependencies: features that consume or feed data to the changed module.
• Walk the critical path once (log in, perform the core action, log out).
• Watch for new console or server errors while executing the steps.
• Record the verdict and evidence, then apply the exit criteria: pass to regression, or fail back to development.

Sanity tests can be executed with both manual and automated approaches. However, both have their specific advantages and disadvantages. Let's see each of them.

Manual Sanity Testing

In manual sanity testing, critical test cases are executed to validate the software’s stability and functionality. Such an approach is helpful in case of limited resources and time for testing, and changes done are minor.

How to Perform Manual Sanity Testing?

The steps for a manual sanity test are mentioned below:

• Analyze the test cases to ensure the expected working of the software application.
• Create test cases that cover crucial functionality of the software to be tested.
• Evaluate the outcome of the test cases to find whether the sanity test is passed. In case the sanity test fails, it is marked as unstable, and then we are required to conduct further tests.
• The result is then shared with the development team to address the identified bug or error during the testing.
• On fixing the error or bug, a re-test of the application is done to ensure its stability.

It should be noted that a manual approach requires highly-skilled testers with good knowledge of software and its functionality.

Automated Sanity Testing

Automated sanity tests involve using automated testing tools and frameworks to verify the basic function of the application. It includes creating automated test cases that run automatically in the application every time a new build or release is developed.

You can prefer the automation method to perform sanity tests for complex applications, which demands significant testing to ensure its reliability and stability.

Sanity tests are more often automated because they are a subset of regression tests. Automation saves time and resources in the testing process, along with maintaining the quality of the software application.

How to Perform Automated Sanity Testing?

You can follow below given general steps to perform an automated sanity test.

• Define the software application's functionalities, which require testing.
• Now, create test cases that include the defined functionality of the software application.
• Select a test execution tool that automates the test cases created by you based on the functionality. Some available tools include Selenium, Playwright, Appium, etc.
• You need to set up a test environment with proper configuration. In other words, ensure the availability of software, hardware, and network resources when you execute a sanity test.
• Run the sanity test and observe the test results. If the test fails, analyze its actual cause and fix the issue.
• On completion of the test run, evaluate the test result to find any bugs.
• Now, you have to report those identified bugs to the developers. However, the best practice here includes detailed information in terms of screenshots and test log files.
• You can repeat the process to re-check the stability of the software application.

In agile teams, a manual-only sanity check becomes the bottleneck: builds land several times a day, and each hotfix needs the same verification. The fix is to run the sanity suite as an automated quality gate inside the pipeline itself.

The pattern looks the same in Jenkins, GitHub Actions, or any CI tool:

• A hotfix or feature branch deploys to the test environment, triggering the pipeline stage.
• The automated sanity suite runs: a small set of critical-path tests scoped to minutes, not the full regression suite.
• On failure, the gate blocks promotion to staging and notifies the team, so a broken build never travels further down the pipeline.
• On success, the build is marked sane and the longer regression suite is queued.

Keep the gate fast by running the sanity suite on a cloud grid in parallel rather than sequentially on the CI runner. If you use Jenkins, the setup for routing tests to the cloud is covered in the Jenkins pipeline integration docs; the same suite definition then serves every hotfix without per-release scripting.

Performing sanity tests using automated test tools lower the working load of the testers and developers. It shortens the release time of software applications through the quick execution of sanity tests. Here are some popular automation testing tools to perform sanity tests:

• Selenium: It is an open-source automation testing tool utilized for web application testing. It supports multiple programming languages like Java, JavaScript, Python, etc.
• Cypress: It is an open-source JavaScript automation testing tool built on Mocha. Cypress utilizes unique DOM manipulation techniques and supports multiple programming languages like C#, Perl, PHP, etc.
• Playwright: It is a Node.js library for web automation. It is used to automate Firefox, Webkit, and Chromium with a single API.

The list of sanity testing tools above is just a few examples of many other options in automation tools. You should evaluate different options based on the specific needs of the applications.

However, automation tools have some limitations, which can create hurdles in performing sanity tests. For example, automation tools have limited scope as you can only test to which they are programmed. Further, issues of maintenance overhead and huge costs with automation tools demanded alternative options.

It is preferred to run sanity tests in a cloud platform. Cloud-based testing platforms like TestMu AI can offer several advantages for sanity testing in software development, including reliability and scalability. If you want to scale your digital experiences, it is recommended to perform cloud testing. Let us learn this in detail in the below-given section.

Now that you know the different ways to perform sanity tests and their advantages, let us dig into performing sanity testing on the cloud. Sanity tests in the cloud-based environment can lower infrastructure costs, give scalability to run automated tests, enable team collaboration, and provide flexibility in the testing environment.

Cloud-based continuous quality testing platforms like TestMu AI help you perform manual and automated web and mobile app testing on over 3,000+ browsers, devices, and OS. With TestMu AI, you can automate your test suites using different frameworks like Selenium, Cypress, Playwright, Appium, Espresso, XCUITest, and more.

Follow the below-given steps to conduct a sanity test using TestMu AI.

Manual testing with TestMu AI

You can execute web and mobile application tests through the Real Time Testing feature of TestMu AI. Follow these steps to run real-time testing.

Here is how you perform real-time testing for your website or web application:

• Register for free and sign in to your TestMu AI account.
• From the modal box, click the Realtime Testing card.

• Enter the test URL, choose Web or Mobile tab, and select browser VERSION, OS, and RESOLUTION. Then click START.

  A cloud-based machine will be launched running real browsers and operating systems where you can perform sanity tests while leveraging features like one-click bug logging, video recording, capturing screenshots, etc.

  

Similarly, you can test mobile web and native applications on Android Emulators, iOS Simulators, and real mobile devices.

Automation Testing with TestMu AI

TestMu AI gives access to 3,000+ desktop and mobile browser environments to run automated tests using different automation testing frameworks. To perform an automated sanity test, you can follow these steps.

• Register and sign in to your TestMu AI account.
• Go to Automation > Builds from the left menu bar.

• You will get two options: Demo Project or Configure Test Suite.

• To run the sanity test, select configure Test Suite and choose the preferred automation testing framework.

• Now, you can configure your tests and initiate a sanity test.

On a similar note, you also perform app test automation using frameworks like Appium, Espresso, and XCUITest.

Watch the below to learn more about performing app automation using TestMu AI.

You can also Subscribe to the TestMu AI YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress testing, and much more.

To run effective sanity tests and ensure critical functionalities work as expected, follow these practices:

• Define Objectives: Clearly identify what needs to be tested and why. A well-defined scope ensures focus on the most important features affected by recent changes, avoiding unnecessary testing.
• Automate When Possible: Automating sanity tests accelerates execution and reduces the risk of human error. Automation is particularly useful when the same checks need to be run frequently after multiple builds.
• Use a Standard Environment: Keep the testing environment consistent in terms of software versions, hardware specifications, and network settings. This consistency ensures that results are reliable and comparable across test cycles.
• Prioritize Test Cases: Rank test cases based on the risk and criticality of the functionality. This ensures that the most impactful areas are verified first, reducing the chance of missing critical defects.
• Document Outcomes: Keep a record of test results, issues found, and corrective actions taken. Documentation helps track progress, supports future audits, and provides valuable insights for process improvement.
• Test Regularly: Conduct sanity tests after every significant code change or build update. This proactive approach allows for early defect detection, reducing the cost and complexity of fixes.
• Pre-Load Test Checks: Before running heavy load or performance tests, execute sanity tests to confirm that the application is stable under normal conditions. This avoids wasting time on performance tests if the build is already unstable.