Defect Root Cause Analysis in Software Testing

A development team fixes a defect that prevented customers from applying discount codes during checkout. The corrected build reaches QA, but running the complete regression suite immediately would consume several hours.

The tester first performs a short, focused check. They confirm that valid discounts apply correctly, invalid codes display an appropriate error, the cart total updates, and checkout can still continue. If these checks fail, the build returns to development without consuming the time required for wider regression testing.

That focused evaluation is sanity testing.

Sanity testing helps teams determine whether a specific change is working plausibly and whether the affected area is stable enough for broader testing. It is deliberately narrow, fast, and closely connected to recent modifications.

What Is Sanity Testing?

Sanity testing is a narrow form of functional validation used to determine whether a recent software change behaves reasonably and whether the affected area is ready for more extensive testing.

The change may be:

• A defect fix
• A minor enhancement
• A small feature addition
• A configuration change
• A dependency update
• A targeted patch
• A change to an integration

Rather than testing the entire application, sanity testing concentrates on the modified behaviour, its immediate dependencies, and one or two important related journeys.

For example, if a team changes an invoice-download feature, sanity testing may verify that the user can generate an invoice, download it in the required format, and open the resulting file. It may also check that the correct account and transaction details appear.

The complete regression suite may later examine historical invoices, different user roles, several file formats, reporting, storage, localization, accessibility, and performance. Sanity testing does not attempt to provide that depth.

Its immediate question is:

Does this change make enough sense and work well enough for broader testing to continue?

An Important Note About the Term “Sanity Testing”

“Sanity testing” does not have one universally applied meaning across every organisation.

Some teams use sanity testing and smoke testing interchangeably. Others define sanity testing as a narrow subset of regression testing performed after a small change. Some use “sanity check” informally for any quick validation that determines whether a result appears reasonable.

The ISTQB glossary defines a smoke test as a suite covering the main functionality of a component or system to determine whether it works properly before planned testing begins. It does not maintain the same distinct standardised entry for sanity testing.

For clarity, this guide uses the convention common in modern QA teams:

Smoke testing is broad and shallow across the build. Sanity testing is narrow and focused around a particular change.

The name matters less than agreeing on scope, timing, ownership, and the decision the check supports.

Purpose of Sanity Testing

Sanity testing prevents teams from spending significant testing time on a change that has failed at a basic level.

Its purpose is not to prove that the product is release-ready. It provides an early indication that:

• The intended change is present.
• The modified functionality behaves plausibly.
• Important adjacent behaviour still works.
• No obvious blocker prevents deeper testing.
• The build can proceed to relevant regression, integration, exploratory, or acceptance testing.

A successful sanity test reduces uncertainty but does not eliminate it. A four-minute check of a corrected payment workflow cannot establish that every payment method, currency, retry condition, refund scenario, or downstream report is correct.

Characteristics of Sanity Testing

It Has a Narrow Scope

Sanity testing concentrates on one change or a closely related group of changes. It does not attempt to verify every existing feature.

It Is Relatively Fast

The test should provide feedback early enough to prevent wasted effort. If a “sanity suite” takes several hours, its scope probably overlaps with broader regression testing.

It Is Based on Change Impact

The tester needs to understand what changed and which nearby behaviours may be affected. A fixed generic checklist is not sufficient for every build.

It Uses High-Value Scenarios

Sanity testing prioritises direct behaviour, critical dependencies, and common user paths instead of extensive edge-case coverage.

It Supports a Continue-or-Stop Decision

The outcome should be actionable. If a release-blocking sanity test fails, the team should stop broader testing and return the build for investigation.

It May Be Manual or Automated

Short exploratory checks are often manual, while stable and frequently repeated checks can be automated.

Sanity Testing Example

Imagine that users cannot update their delivery address because the application rejects valid postal codes containing spaces. A developer corrects the validation rule.

A focused sanity test could verify:

1. A valid postal code containing a space is accepted.
2. A valid postal code without a space continues to work where permitted.
3. Invalid characters are still rejected.
4. The updated address can be saved.
5. The saved address appears correctly on the account.
6. Checkout can use the updated address.

These checks validate the changed rule and its closest customer-facing consequences.

Broader regression testing may later cover:

• Addresses in every supported country
• Billing addresses
• Tax calculations
• Shipping availability
• Fraud checks
• Saved payment methods
• Historical orders
• Address autocomplete
• Mobile and web compatibility
• Localization

Sanity testing intentionally stops before that wider coverage.

Sanity Testing vs Smoke Testing

Sanity and smoke testing are both fast preliminary checks, but they usually differ in scope and trigger.

A smoke test may confirm that users can log in, view products, and reach checkout. A sanity test may focus specifically on a recently changed discount calculation within checkout.

Sanity Testing vs Regression Testing

Sanity testing may be treated as a small, highly targeted subset of regression coverage. However, it does not replace the wider regression suite.

If a tax-calculation fix passes sanity testing, the regression suite may still reveal that the change broke refunds, invoices, subscriptions, or finance reports.

Sanity Testing vs Retesting

Retesting, also called confirmation testing, verifies whether a specific defect has been fixed.

Sanity testing assesses whether the corrected or modified area works reasonably enough to continue testing.

Suppose a defect report says that the Reset Password button returns an error.

Retesting repeats the original steps and confirms that the button now sends the reset email.

Sanity testing may additionally verify that the link opens, the password can be changed, the old password stops working, and the user can log in with the new password.

Regression testing then checks connected authentication workflows such as registration, session management, account lockout, and multi-factor authentication.

Sanity Testing vs Functional Testing

Functional testing is the wider practice of checking whether software behaves according to its functional requirements.

Sanity testing uses functional checks, but its scope and objective are narrower. It evaluates a small set of behaviours to determine whether a change is sufficiently stable for further testing.

A complete functional test of a search feature may cover filters, sorting, pagination, spelling, permissions, empty results, special characters, and large datasets. A sanity test after a sorting fix may validate only the corrected sort order and a few closely connected search behaviours.

When Should Sanity Testing Be Performed?

After a Defect Fix

Confirm that the corrected functionality and its immediate dependencies behave reasonably before running broader regression tests.

After a Minor Enhancement

A change to a filter, form, calculation, report, or user setting should receive focused validation before more extensive testing.

After a Small New Feature

Sanity testing can determine whether a new feature is integrated well enough for detailed functional, exploratory, and regression testing.

After a Configuration Change

Updates to feature flags, timeouts, permissions, routing, or environment variables can be validated through a small targeted suite.

After a Dependency or Integration Update

A minor SDK or API update may justify focused checks of the integration and the workflow it supports.

After a Targeted Patch

Hotfixes and production patches require rapid but disciplined validation. Test the direct correction, high-risk dependencies, and the deployment result.

After an Environment Deployment

A deployment-specific check may be called a sanity test in some teams, although broad post-deployment validation is often categorised as smoke testing. Define the terminology within the organisation.

When Should Sanity Testing Be Skipped?

Sanity testing is less useful when the change is so broad that a focused scope cannot provide meaningful confidence.

Examples include:

• Major architectural migrations
• Large framework upgrades
• Complete user-interface redesigns
• Extensive database migrations
• Changes to several shared services
• Large multi-feature releases
• Unclear or undocumented change impact

These changes may require smoke testing followed directly by broad regression, integration, performance, security, or acceptance testing.

Sanity testing may also be unnecessary when an automated targeted suite already provides the same immediate evidence reliably within the pipeline. The activity still exists, but the organisation may not label it separately.

Entry Criteria for Sanity Testing

Sanity testing should begin only when:

• The build has been deployed successfully to the test environment.
• Basic smoke or build-verification checks have passed where required.
• The change is available in the build.
• Release notes, defect details, or change information are available.
• The tester understands the expected behaviour.
• Required accounts, data, integrations, and permissions are ready.
• The environment is stable enough to interpret results.

Starting without understanding the change turns sanity testing into random surface-level exploration.

How to Perform Sanity Testing

Step 1: Understand What Changed

Review the user story, defect report, acceptance criteria, release notes, code-change summary, configuration update, and developer comments.

Identify:

• What was changed
• Why it was changed
• Which component was modified
• What user-visible behaviour should differ
• Which dependencies may be affected
• What risks the developer or tester already knows

A short conversation with the developer can prevent both unnecessary tests and dangerous omissions.

Step 2: Define the Focused Scope

Select the smallest group of tests capable of determining whether the change is plausible and testable.

Include:

• The direct modified behaviour
• The original defect scenario, if applicable
• One or two common successful paths
• An important invalid or failure path
• Closely connected functionality
• A critical downstream effect

Avoid unrelated application areas unless the change affects a widely shared component.

Step 3: Define Pass and Fail Criteria

The team should know which failures stop testing.

For example:

• The corrected scenario must pass.
• No critical error or crash may occur.
• Data must be stored accurately.
• The immediate dependent workflow must remain usable.
• No high-severity defect may block broader testing.

Without explicit criteria, teams may continue testing an unsuitable build because the failure appears “small.”

Step 4: Prepare the Environment and Test Data

Confirm the correct build, configuration, database version, feature flags, accounts, permissions, and integrations.

Use test data that represents the changed behaviour. If a discount fix applies only to returning customers in one market, a generic new-user account will not validate it.

Step 5: Validate the Direct Change First

Begin with the exact behaviour the build was intended to modify.

If the change is a defect fix, repeat the original reproduction steps. If this direct validation fails, broader sanity checks may add little value unless more evidence is required for diagnosis.

Step 6: Test Closely Related Behaviour

Check the immediate workflow before and after the modified step.

For a file-upload fix, this may include selecting the file, validating it, uploading it, displaying progress, saving the result, viewing the uploaded file, and handling a failed upload.

The objective is to identify obvious side effects without expanding into complete regression testing.

Step 7: Record the Result and Make a Decision

The final result should be one of three outcomes:

Pass: The change appears stable enough for planned testing.

Fail: A blocking issue requires correction before broader testing.

Pass with known limitations: Testing may continue with documented risks, exclusions, or non-blocking defects.

Record the build, environment, scope, data, results, defects, and decision. The documentation can remain concise because sanity testing is intended to provide rapid feedback.

Step 8: Retest and Continue

If the build fails, report the defect with reproducible evidence. After correction, rerun the direct test and relevant sanity scope.

Once the sanity test passes, continue with the appropriate regression, integration, exploratory, performance, security, or acceptance testing.

Reusable Sanity Testing Checklist

Adapt this checklist to the specific change rather than applying every item to every build.

Change and Environment

• Confirm that the correct build and change are deployed.
• Review the change summary, requirements, and known limitations.
• Verify the environment, configuration, feature flags, and dependencies.
• Prepare suitable accounts, roles, and test data.

Direct Functionality

• Execute the exact changed or corrected behaviour.
• Confirm the expected successful result.
• Check one important invalid or failure condition.
• Verify that the application does not crash or become unusable.
• Confirm that error messages and recovery actions make sense.

Related Behaviour

• Test the immediate step before the change.
• Test the next important step after the change.
• Verify that data is saved, retrieved, or transferred correctly.
• Check one closely connected feature or integration.
• Confirm that repeated actions do not create duplicates or inconsistent state.

Decision

• Record pass, fail, or pass-with-limitations.
• Report blocking defects immediately.
• Document untested risks or environmental constraints.
• Continue with broader testing only when the entry conditions are satisfied.

Sanity Testing Example: Checkout Discount Fix

A defect prevents customers from combining a loyalty discount with free shipping. The development team provides a corrected build.

The sanity-testing scope could include:

1. Apply a valid loyalty discount.
2. Confirm that the cart total changes correctly.
3. Add an item that qualifies for free shipping.
4. Verify that free shipping remains applied.
5. Continue to payment.
6. Confirm that the final total matches the cart.
7. Refresh or reopen the cart and verify that both benefits remain.
8. Try an invalid loyalty code and confirm that it does not affect shipping.

If the calculation or checkout flow fails, the build returns to development.

If the sanity test passes, broader regression testing can cover coupon types, membership levels, currencies, tax jurisdictions, refunds, cancellations, payment methods, and historical orders.

Can Sanity Testing Be Automated?

Yes. Sanity testing is frequently described as manual because its scope may change with each modification. However, stable and repeated sanity checks can be automated effectively.

Automation works well when:

• The same type of change occurs regularly.
• The expected result is deterministic.
• Test data can be prepared consistently.
• The check is run after frequent deployments.
• The workflow is important and stable.
• Fast feedback is required in CI/CD.

For example, a billing application may automatically run targeted checks after changes to invoice generation. These could validate invoice creation, totals, file generation, and download.

Manual sanity testing remains useful when the feature is new, the interface changes frequently, the expected behaviour requires human interpretation, or exploratory investigation is needed.

The strongest approach is often hybrid: automation confirms predictable behaviour, while a tester explores risks introduced by the particular change.

Sanity Testing in CI/CD

In a CI/CD pipeline, the term sanity suite may describe a fast group of tests selected according to the modified component.

A practical sequence might be:

1. Build and static checks
2. Unit tests
3. Smoke or build-verification tests
4. Targeted sanity tests
5. Integration and API tests
6. Selected regression tests
7. Broader pre-release validation

The boundary between smoke, sanity, and targeted regression automation may not always be visible in the pipeline. What matters is that each stage has a defined purpose, scope, execution time, and failure response.

If a sanity check is a required quality gate, the pipeline should stop when it fails rather than continue running expensive downstream suites.

Tools for Sanity Testing

Sanity testing does not require a dedicated category of tool. Teams use the same tools that support functional, API, mobile, and automated testing.

Choose the tool based on the interface being tested and the team’s existing technology—not because it is marketed specifically for sanity testing.

Best Practices for Sanity Testing

Base the Scope on the Change

A generic sanity checklist may become a disguised smoke test. Use release notes, dependencies, and impact analysis to select relevant checks.

Keep the Suite Small

If the suite attempts to protect the complete application, it has moved into regression testing. Preserve a short feedback cycle.

Test the Direct Change First

Do not spend time on adjacent behaviour when the actual correction or enhancement already fails.

Include One Meaningful Failure Path

A successful path alone may create false confidence. Check an invalid input, denied permission, failed dependency, or other relevant exception.

Use Representative Data

The right test case with unrealistic data can still miss the defect. Choose accounts, roles, records, and configurations that exercise the actual change.

Avoid Duplicating Smoke and Regression Suites

Each suite should have a clear job. Duplicate coverage increases maintenance without necessarily increasing confidence.

Automate Repeated Checks

Automate stable, deterministic sanity tests that run frequently, but do not force automation onto rapidly changing or judgement-heavy scenarios.

Make the Failure Decision Explicit

Define which failed tests reject the build and who can approve an exception.

Common Challenges in Sanity Testing

The Scope Expands Unnecessarily

Testers may keep adding related scenarios until sanity testing becomes a full regression cycle.

Set a time boundary and focus on the decision the test needs to support.

Hidden Dependencies Are Missed

A small code change may affect a shared service or component.

Review dependency information and ask developers which other features use the changed code.

The Environment Produces False Failures

Incorrect feature flags, unavailable services, invalid data, or mismatched versions can make a correct change appear broken.

Verify environment health before rejecting the build.

The Test Is Too Superficial

Checking only that a screen loads may miss incorrect calculations, unsaved data, broken permissions, or failed downstream processing.

Validate the meaningful outcome, not only the visible interface.

Teams Use Conflicting Terminology

One team may call a suite “smoke,” another “sanity,” and another “targeted regression.”

Document the scope and objective instead of relying on the label alone.

Advantages and Limitations of Sanity Testing

Frequently Asked Questions

What is sanity testing in simple terms?

Sanity testing is a quick, focused check that determines whether a recent software change works reasonably and whether its affected area is stable enough for more extensive testing.

What is the main purpose of sanity testing?

Its purpose is to prevent teams from spending time on detailed testing when a specific change or fix has already failed at a basic functional level.

Is sanity testing the same as smoke testing?

Not under the convention used in this guide. Smoke testing broadly checks the health of a build, while sanity testing narrowly checks a particular change and closely related functionality.

Is sanity testing a type of regression testing?

It is commonly treated as a narrow subset of regression testing because it checks behaviour after a change. However, terminology and classification vary between organisations.

Who performs sanity testing?

QA engineers commonly perform it, but developers, SDETs, product teams, or release engineers may also execute manual or automated sanity checks depending on the delivery process.

Can sanity testing be automated?

Yes. Stable, deterministic, and frequently repeated sanity checks can be automated. Manual testing remains useful for new, changing, visual, or exploratory scenarios.

When should a build fail sanity testing?

A build should fail when the direct change does not work, a critical related workflow is broken, data becomes inconsistent, the application crashes, or another predefined blocking condition occurs.

What happens after sanity testing passes?

The build proceeds to the appropriate next activities, which may include integration, regression, exploratory, performance, security, compatibility, or acceptance testing.

How long should sanity testing take?

There is no universal duration. It should be short enough to provide early feedback and narrow enough to avoid becoming a regression suite. The time depends on the change’s complexity and risk.

Does sanity testing require documented test cases?

Not always. Experienced testers may use a focused checklist or charter for a one-time change. Repeated or release-critical checks should be documented for consistency and traceability.

Conclusion

Sanity testing is a focused decision-making tool. It tells the team whether a particular software change behaves plausibly and whether investing in broader testing is worthwhile.

Its value comes from discipline. The tester must understand the change, select a compact but meaningful scope, validate the direct behaviour first, inspect close dependencies, and make a clear pass-or-fail decision.

Sanity testing should not be treated as proof that the entire application is stable. It does not replace smoke, regression, integration, performance, security, or acceptance testing. Instead, it prevents those larger activities from beginning on a change that has already failed at a basic level.

Whether the check is performed manually or through a CI/CD pipeline, the principle remains the same: test the change quickly, validate its immediate consequences, and proceed only when the result makes sense.