Sanity Testing - Software Testing

Last Updated : 1 Jul, 2026

Sanity testing is a quick, focused testing process performed after receiving a new build with minor changes or bug fixes. It verifies whether the specific functionality works correctly without testing the whole application.

  • Performed after small changes or bug fixes in the code.
  • Focuses only on specific affected modules, not the entire system.
  • Ensures that the bug fix works and no major issues are introduced.

Example: After fixing a login bug, the tester checks only the login functionality in the new build. If login works with valid credentials, the sanity test is passed; otherwise, the defect is reported again

Features of Sanity Testing

Ensures that recent changes or bug fixes are working correctly without affecting the core functionality of the application.

features_of_sanity_testing
Features of Sanity Testing
  • Focused Scope: Concentrates only on the modules or functionalities affected by recent changes instead of testing the entire application.
  • Unscripted: Usually performed without predefined test cases and often conducted in an ad hoc manner.
  • Minimal Documentation: Emphasizes quick validation over detailed test planning and documentation.
  • Narrow and Deep: Covers limited but critical functionalities in detail instead of broad coverage.
  • Performed by Testers: Conducted by QA testers who quickly evaluate the stability of recently modified areas.

Sanity Testing Process

Sanity Testing follows a quick and focused workflow to verify that recent changes or bug fixes are working correctly before moving to detailed testing. It ensures the build is stable without spending much time on full testing.

new_build_bug_fix
Sanity Testing process
  • Identify Changes: Analyze recent bug fixes or minor updates and understand the scope of changes made and determine the affected modules or features.
  • Plan Test Approach: Select only relevant test cases related to the changes and keep the testing scope limited and focused and avoid unnecessary or full regression coverage.
  • Execute Sanity Tests: Perform quick checks on modified functionalities and validate core behavior and system logic and ensure critical features are working as expected.
  • Verify Results: Confirm that bug fixes are working correctly and check for any unintended side effects and ensure no major issues are introduced.
  • Decision Making: Evaluate test outcomes and decide whether the build is stable. If the test passes, proceed to regression testing; if it fails, send the build back to the developers for rework.

Entry and Exit Criteria

Sanity testing helps ensure that the build is stable and ready for further detailed testing like regression testing.

Entry Criteria

  • A stable build is received from the development team.
  • Bug fixes or minor changes are implemented in the new build.
  • Test environment is properly set up and ready for testing.
  • Required modules or affected areas are available for testing.

Exit Criteria

  • Fixed functionality works correctly as expected.
  • No major or critical defects are found in the affected areas.
  • Build is stable enough to proceed with regression testing.
  • Sanity testing goals are successfully achieved within limited scope.

Advantages of Sanity Testing

  • Quick Detection of Critical Issues: Identifies defects in core and recently modified functionalities early.
  • Time-Saving: Focuses only on impacted areas, so it requires less time and minimal documentation.
  • Avoids Unnecessary Regression Testing: Rejects unstable builds early, saving effort and resources.
  • Cost-Effective: Uses fewer resources compared to full regression or detailed testing.
  • Useful Under Tight Deadlines: Ideal when time is limited and quick validation is needed.
  • Boosts Confidence and Productivity: Ensures key features are stable, allowing teams to proceed with further testing confidently

Limitations of Sanity Testing

  • Does Not Provide Complete Coverage: Tests only the affected functionality, leaving other parts of the application unverified.
  • Incomplete Testing: Does not evaluate the overall quality, performance, or reliability of the software.
  • May Miss Hidden Defects: Bugs in unrelated modules or deeper integration issues may go undetected.
  • Usually Unscripted: Often performed without detailed test cases, making it difficult to reproduce or document results.
  • Dependent on Tester Expertise: The effectiveness of sanity testing depends on the tester's experience and understanding of the application.
  • Cannot Replace Full Testing: It is a quick validation technique and cannot substitute for comprehensive testing methods such as regression or system testing.
  • Possibility of False Confidence: Passing sanity testing does not guarantee that the entire application is defect-free.
  • Limited Test Scope: Focuses only on changed or impacted areas and ignores unaffected modules.

Read More: Sanity Testing Vs Smoke Testing

Comment

Explore