Sanity Testing - Software Testing

Last Updated : 1 May, 2026

Sanity Testing is a quick and focused testing technique performed after minor changes or bug fixes to ensure that the specific functionality is working correctly. It acts as a checkpoint before proceeding with further detailed testing.

  • Narrow Scope: Covers only affected areas of the application, not the entire system.
  • Time-Saving: Quickly verifies functionality, avoiding unnecessary full testing cycles.
  • Build Stability Check: Ensures the build is stable enough for further testing.

Functionality of Sanity Testing

Focuses on quickly verifying that modified or newly added functionalities are working as expected after minor changes or bug fixes.

  • Integration Check: Ensures recent changes or bug fixes have not negatively affected the integration between modules or components.
  • Bug Fix Verification: Confirms that reported defects are properly resolved and related features are functioning correctly.
  • Quick Stability Assessment: Determines whether the build is stable enough to proceed with further testing, saving time and resources.
  • Basic Regression Check: Performs a limited check to ensure existing critical functionalities are not impacted.
  • Frequent Validation: Can be executed repeatedly on incremental builds, especially in Agile and continuous integration environments

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
  1. Identify Changes : Analyze recent bug fixes or minor updates and understand the scope of changes made and determine the affected modules or features.
  2. 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.
  3. Execute Sanity Tests : Perform quick checks on modified functionalities and validate core behavior and system logic and ensure critical features are working as expected.
  4. Verify Results : Confirm that bug fixes are working correctly and check for any unintended side effects and ensure no major issues are introduced.
  5. Decision Making : Evaluate test outcomes and decide whether the build is stable or not and if pass then proceed to regression testing and if fail then send back to developers for rework.

Example of Sanity Testing

Scenario:

A login issue was reported where users were unable to log in even with correct credentials. Developers fixed the bug and provided a new build.

Sanity Testing Steps:

  • The tester installs the new build with the bug fix.
  • Focus is only on the login functionality (not the whole application).
  • Tester enters valid username and password → checks if login is successful.
  • Tester may also check a few related cases (e.g., invalid password, empty fields).
  • Verify that the fix works and no new issue is introduced.

Result:

  • If login works correctly -> Sanity Test Passed -> Proceed to Regression Testing
  • If login still fails or causes new issues -> Sanity Test Failed -> Report defect and send for rework

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.

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

Disadvantages of Sanity Testing

  • Does Not Provide Complete Coverage: Since only impacted areas are tested, other parts of the system may remain unverified.
  • Incomplete Testing: Does not provide a full evaluation of the system’s overall quality or performance.
  • May Miss Hidden Defects: Issues in untouched modules or deeper design-level problems may go unnoticed.
  • Unscripted Nature: Usually not documented, making future reference or tracking difficult.
  • Dependent on Tester Expertise: Effectiveness relies heavily on the tester’s knowledge and understanding of the system.
  • Possibility of False Confidence: Since it is a quick check, some defects may be overlooked, giving a false impression of stability.

Sanity Testing Vs Smoke Testing

BasisSanity TestingSmoke Testing
PurposeVerify that specific bug fixes or changes are working correctlyCheck whether the basic build is stable for further testing
When PerformedAfter minor changes or bug fixesAfter receiving a new build
ScopeNarrow and focused on affected areasBroad and covers major functionalities
DepthMore detailed than smoke testing but limited to specific areasShallow and surface-level testing
Test CasesSelected test cases related to changesBasic test cases covering critical paths
ExecutionCan be manual or automatedUsually automated (can be manual too)
ObjectiveValidate correctness of fixesValidate stability of the build
Time ConsumptionLess time due to limited scopeVery quick and minimal time
OutcomeDecide if changes are correct and stableDecide if build is testable or not
Comment

Explore