>_ Sanity Testing Checklist

Short answer

A Sanity Testing Checklist is a short, targeted list of checks that QA or the team runs after a specific change, bug fix, hotfix, configuration update, or small improvement to quickly confirm that the changed part of the product works as expected and has not broken the closest related scenarios.

Sanity testing usually does not check the whole product. Its goal is to focus on a specific area: a fixed bug, changed form, updated checkout step, new validation rule, changed button, updated API response, role permission fix, email notification fix, or production hotfix.

The main idea is: sanity testing answers the question "does this specific change now work well enough for the team to move forward?"

Sanity testing is especially useful after small changes when full regression testing is too broad, but a simple smoke test is too general.

This guide can also be used as a sanity QA checklist, bug fix sanity checklist, hotfix testing checklist, focused regression checklist, or post-fix validation checklist for product and QA teams.

Sanity Testing vs Smoke Testing

Sanity testing and smoke testing are similar because both are fast checks. But they have different goals.

Smoke testing checks whether the product or build is basically alive:

• the app opens;
• login works;
• the main flow works;
• forms can be submitted;
• checkout works;
• there are no obvious blocker issues;
• production is not broken after deployment.

Sanity testing checks a specific change or specific area:

• the fixed bug no longer reproduces;
• the changed form works;
• the validation rule is applied correctly;
• the new setting did not break a related scenario;
• the hotfix actually fixed the production issue;
• nearby functionality around the change still works.

In simple terms: smoke testing is a broad and shallow check, while sanity testing is a narrow and focused check.

For example:

• After a new deployment to staging, the team runs a smoke test to make sure the build is usable.
• After fixing a password reset bug, the team runs a sanity test to make sure password reset now works and nothing obvious around it is broken.

Sanity Testing vs Regression Testing

Sanity testing and regression testing are also related, but they differ in depth and scope.

Regression testing checks whether existing scenarios were broken after changes. It may cover affected areas, high-risk flows, roles, integrations, mobile, data, fixed bugs, and broader product areas.

Sanity testing is usually narrower and faster. It checks the specific changed area and the closest related scenarios.

In simple terms: sanity testing is a targeted mini-check, while regression testing is a broader check of existing functionality after changes.

For example, if promo code logic changed:

• Sanity testing may check: valid code, invalid code, total recalculation, affected checkout summary.
• Regression testing may additionally check: cart, checkout, payment, order confirmation, emails, admin panel, analytics, and mobile checkout.

Sanity Testing vs Retesting

Sanity testing is also often confused with retesting.

Retesting is checking a specific bug again after it was fixed.

For example: there was a bug where "invalid email does not show an error." A developer fixed it, and QA checks that exact bug again.

Sanity testing goes slightly wider. It checks not only the bug fix itself, but also the closest logic around it.

For example, after an email validation fix, sanity testing may include:

• invalid email shows an error;
• valid email submits the form;
• error message appears next to the correct field;
• entered data is not lost;
• form submit still works;
• lead reaches CRM or email notification, if important.

In simple terms: retesting checks "was the bug fixed?", while sanity testing checks "does the fixed area now look healthy and not break nearby scenarios?"

When to use a Sanity Testing Checklist

Use a sanity testing checklist when you need to quickly check a specific change without running a full regression pass.

For example:

• a bug was fixed;
• a hotfix was released;
• validation logic was updated;
• a form was changed;
• a checkout step was changed;
• login or password reset logic changed;
• API response changed;
• permissions changed;
• status or business rule changed;
• email notification was updated;
• calculation changed;
• UI component changed;
• configuration or feature flag changed;
• production issue was fixed;
• after deployment, one specific area needs to be checked;
• after retesting, you need to confirm that the related scenario also works.

Sanity testing is especially useful when the change is small, but the risk in the changed area is high.

Short Sanity Testing Checklist

If you need a minimal sanity test, check that:

• it is clear what exactly changed;
• latest build or fix has been deployed;
• the correct environment is being tested;
• test data is prepared;
• the original bug or issue no longer reproduces;
• changed functionality works with valid data;
• changed functionality handles invalid data correctly;
• the closest related scenario works;
• user sees the expected result;
• data is saved or updated correctly;
• error message is clear, if there is an error;
• related UI is not broken;
• roles or permissions work, if affected;
• email, notification, or integration works, if affected;
• there are no critical console errors or failed API requests;
• found issues are documented;
• a decision is made: passed, failed, or needs regression.

This is not full QA and not full regression. It is a fast targeted check that helps the team understand whether the fix can be closed, testing can continue, or a broader regression pass is needed.

Sanity Testing Checklist

1. Define the goal of the sanity test

Before starting sanity testing, it is important to understand what exactly needs to be confirmed.

Check that:

• the bug, task, or change being tested is clear;
• what changed is clear;
• the affected product area is known;
• expected result is known;
• old incorrect behavior is known;
• new correct behavior is known;
• related scenarios that may be affected are known;
• what is included in sanity scope is clear;
• what is not included in sanity scope is clear;
• the person responsible for the pass / fail decision is known.

The main question for this part is: which specific change should work after the fix or update?

If the goal of the sanity test is not defined, the check can quickly turn into either a superficial click-around or an unplanned regression pass of the whole product.

2. Understand what changed

Sanity testing always starts with understanding the change. Even a small fix can affect several related parts.

Check that:

• task description is available;
• bug report is available;
• acceptance criteria are available;
• changed files, modules, or components are known;
• frontend changed or did not change;
• backend changed or did not change;
• API changed or did not change;
• database logic changed or did not change;
• roles or permissions changed or did not change;
• integrations changed or did not change;
• feature flags changed or did not change;
• developer or product team shared known risks.

If QA does not understand what changed, sanity testing becomes random. It is better to clarify the affected area before testing starts.

3. Prepare the environment and build

Sanity test should be performed on the correct product version.

Check that:

• required environment is available;
• latest build has been deployed;
• the fix is actually included in the build;
• version or commit matches the expected one;
• feature flag is enabled or disabled as needed;
• test user is available;
• test data is prepared;
• integration test mode works, if needed;
• logs or monitoring are available, if important;
• there are no known environment issues that may distort the result.

If you test an old build or the wrong environment, the sanity result will be useless.

4. Prepare test data

For sanity testing, you need exactly the data that makes it possible to check the change quickly.

Check that:

• data for the old bug scenario is available;
• data for the valid scenario is available;
• data for the invalid scenario is available;
• user with the required role is available;
• resource in the required status is available;
• existing record is available if the fix affects old data;
• new record scenario is available if important;
• test email inbox is available if email is being checked;
• test payment method is available if checkout/payment is affected;
• admin panel access is available if internal result needs to be checked.

Sanity testing should be fast. If test data is not ready, a short check turns into long preparation.

5. Check the original bug or changed scenario

Start with the main thing: reproduce the scenario that the fix or change was made for.

Check that:

• old bug no longer reproduces;
• changed feature works;
• expected result is achieved;
• user can complete the action;
• no blocker error appears;
• no unexpected redirect happens;
• no broken state appears;
• no endless loader appears;
• success state is displayed, if needed;
• UI behavior matches the task;
• backend result matches expectations, if it needs to be checked.

The main question is: does the exact thing that was supposed to be fixed or changed now work?

6. Check acceptance criteria

If the task has acceptance criteria, sanity testing should go through them.

Check that:

• each acceptance criterion is met;
• expected behavior matches the task;
• old behavior no longer appears;
• user-facing result is correct;
• business rule is applied;
• validation rule is applied;
• UI state is correct;
• data state is correct;
• error state is correct;
• no hidden condition was missed.

Acceptance criteria help avoid unnecessary regression and prevent important details from being missed.

7. Check the happy path in the changed area

After checking the specific fix, make sure the main happy path around the changed area still works.

Check that:

• user can start the scenario;
• user can complete the scenario;
• required fields work;
• submit or action works;
• user sees the expected result;
• data is saved;
• status is updated;
• user can continue to the next step;
• there is no obvious UI issue;
• there is no obvious console error.

For example, if the fix was related to a validation error in a lead form, sanity testing should check not only invalid input but also successful submit with valid data.

8. Check a negative scenario

Sanity testing is not always deep, but one or two negative scenarios are often necessary.

Check that:

• invalid input is handled;
• missing required field shows an error;
• forbidden action is rejected;
• expired link or token is handled if related to the change;
• failed request shows a clear error;
• user can retry;
• data is not lost after the error;
• system does not move into a broken state;
• no 500 error appears for a normal invalid scenario.

Negative scenarios are especially important for forms, login, password reset, checkout, API validation, permissions, and business rules.

9. Check the closest related scenarios

Sanity testing should not cover the whole product. It should cover nearby scenarios around the change.

Check that:

• neighboring user flow works;
• similar scenario works;
• old related behavior is not broken;
• user can move to the next step;
• user can go back;
• repeated action does not break state;
• data from the changed area is used correctly later;
• related UI component works;
• related API response is not broken;
• related email or notification works, if important.

For example, if password reset changed, nearby scenarios may include login with the new password, old password failure, expired reset link, and private page access after login.

10. Check data saving and data correctness

Sanity testing should confirm that the result of the action is saved correctly.

Check that:

• created data appears in the right place;
• updated data is actually updated;
• deleted or archived data behaves correctly;
• status changed correctly;
• calculated value is correct;
• timestamp is correct;
• user ID or owner is correct;
• data is visible to the right roles;
• data is not visible to the wrong roles;
• admin panel shows the expected result, if important;
• API or database result matches UI, if included in scope.

Sometimes the UI looks correct, but data is saved incorrectly. For sanity testing in business-critical areas, this is important to verify.

11. Check UI sanity in the changed area

If the change affects frontend, quickly check the visual state of the changed area.

Check that:

• layout is not broken;
• text is not cut off;
• buttons are visible;
• fields are accessible;
• loading state is displayed;
• error state is displayed;
• success state is displayed;
• modal or dropdown works if related to the change;
• long text does not break the component;
• empty state looks acceptable;
• there is no obvious spacing issue;
• there is no test copy or placeholder text.

Sanity UI check should not become full visual QA, but obvious breakages should be caught immediately.

12. Check roles and permissions, if affected

If the change affects access, accounts, admin actions, organization, workspace, or user data, permissions should be checked separately.

Check that:

• authorized user can perform the action;
• unauthorized user cannot perform the action;
• regular user does not receive admin access;
• admin access works;
• user sees only their own data;
• user does not see someone else's data;
• direct URL does not bypass permissions;
• API request does not bypass permissions;
• changed permission takes effect;
• old permission behavior does not accidentally remain.

Permission bugs are often not visible through the normal happy path. Even for sanity testing, direct URL or role checks may be required.

13. Check API or backend result if the change is backend-related

If the fix was in backend, API, validation, status logic, or data model, a UI-only check may not be enough.

Check that:

• API returns the expected status code;
• response body matches the expected schema;
• validation works on the backend;
• wrong request does not return 500;
• changed field is returned correctly;
• old field is not broken if backward compatibility is needed;
• database update is correct;
• related endpoint is not broken;
• logs do not show errors;
• there is no unexpected server error.

For API-related changes, sanity testing should check not only UI but also backend behavior.

14. Check emails, notifications, or integrations, if affected

If the change is connected to external systems, sanity testing should verify end-to-end delivery.

Check that:

• email is sent;
• email is delivered to the correct user;
• email contains correct data;
• notification is sent;
• notification opens the correct screen;
• CRM receives data;
• webhook is sent;
• external API receives the correct payload;
• failed integration does not break user flow;
• notification is not duplicated;
• email does not contain staging links;
• internal alert is sent to the team, if needed.

For example, if the fix was related to a demo request form, sanity testing should check not only the success message but also the CRM/email result. For deeper email coverage, use a Transactional Email Testing Checklist.

15. Check mobile or browser sanity if the change is frontend-related

If the change affects UI, forms, layout, checkout, navigation, or auth, a short mobile/browser check is often needed.

Check that:

• changed area works in desktop browser;
• changed area works in mobile viewport;
• key action can be completed on mobile;
• mobile keyboard does not break the form;
• there is no horizontal scroll;
• main browser works;
• Safari is checked if there is risk;
• Chrome is checked;
• there is no browser-specific visual issue;
• there are no critical console errors.

You do not need to run full browser regression every time. But if the change is frontend-related, one mobile/browser sanity check can catch an obvious issue.

16. Check console errors, logs, and monitoring

Sanity testing may pass visually while errors happen in the background.

Check that:

• there are no critical console errors;
• there are no failed API requests in the checked scenario;
• there are no unexpected 500 responses;
• logs do not show new server errors;
• error tracking did not receive a new issue;
• monitoring does not show a spike;
• integration logs are clean if integration is affected;
• no repeated error appears after the action;
• there is no warning that indicates broken behavior.

Not every warning is a blocker. But critical errors, failed API calls, auth errors, payment errors, or server errors should be reviewed immediately.

17. Check production sanity after hotfix, if needed

If the change was a hotfix for production, run a short production sanity test.

Check that:

• production opens;
• hotfix is actually deployed;
• original production issue no longer reproduces;
• changed flow works;
• related critical flow still works;
• there is no obvious production error;
• logs do not show an increase in errors;
• monitoring is stable;
• user-facing state is correct;
• support or business team confirms the result, if needed;
• rollback is not needed.

Production sanity should be short and safe. Its goal is to make sure the hotfix resolved the issue and did not create an obvious new blocker.

18. Make a decision: passed, failed, or needs regression

Sanity testing should end with a clear result.

Document:

• sanity test passed;
• sanity test failed;
• additional regression is needed;
• what exactly was checked;
• what was not checked;
• which issues were found;
• whether there is a blocker;
• whether there is a critical bug;
• whether the fix can be closed;
• whether QA can continue;
• whether testing scope needs to be expanded.

"Seems okay" is a poor sanity testing result. The team should understand whether the checks are enough or a broader regression pass is needed.

19. Document the sanity test result

Even a short sanity test is better documented, especially if it is related to a release or production issue.

Record:

• task or bug ID;
• environment;
• build version;
• checked scenario;
• checked related areas;
• test data;
• result: pass / fail;
• found issues;
• remaining risks;
• recommendation;
• QA owner;
• timestamp, if important for release process.

For a small team, this may be a short comment in a ticket. For release process, a more formal summary is better.

20. Repeat sanity test after additional fixes

If sanity testing failed and a developer made another fix, repeat the targeted check.

Check that:

• old issue no longer reproduces;
• new fix works;
• issue from the previous sanity check is closed;
• related scenario still works;
• there is no new obvious regression;
• data state is correct;
• logs are clean;
• final result is documented.

If the fix changed several times, do not check only the latest tiny detail. Run through the full narrow sanity scope again.

Common mistakes

1. Making sanity testing too broad

Sanity testing should be focused. If the checklist turns into checking the whole product, it is already regression testing.

2. Making sanity testing too shallow

Sanity testing is not just opening a page and checking that it loads. It should check the specific change, expected result, and closest related scenarios.

3. Confusing sanity testing with smoke testing

Smoke testing checks whether the build is basically alive. Sanity testing checks a specific fix or change. These are different tools for different situations.

4. Checking only the bug fix and not the nearby area

The bug may be fixed, but a related scenario may be broken. Sanity testing should include at least one or two nearby scenarios around the change.

5. Not checking invalid scenarios

If the fix is related to validation, permissions, auth, or forms, a negative scenario is required. Otherwise, the most important risk may be missed.

6. Not checking data

The UI may show success, but data may not be saved, may be saved in the wrong place, or may receive the wrong status. For business-critical changes, result data should be checked.

7. Not looking at logs or console

The interface may look fine while API requests, integrations, or backend logic fail in the background.

8. Not documenting the result

If the sanity result is not written anywhere, the team does not know whether the bug can be closed, QA can continue, or the hotfix can be released.

9. Using sanity testing instead of regression when risk is high

If the change affected many areas, a critical flow, payment, auth, data migration, or permissions, one sanity test may not be enough.

10. Not running production sanity after a hotfix

A hotfix may work on staging, but production may differ in configuration, data, integrations, or feature flags. After a production hotfix, a short sanity check is needed.

FAQ

What is a Sanity Testing Checklist?

A Sanity Testing Checklist is a short, targeted list of checks after a specific change, bug fix, hotfix, or small update.

It helps make sure that the changed part of the product works as expected, the original bug no longer reproduces, and the closest related scenarios are not broken.

How is sanity testing different from smoke testing?

Smoke testing checks whether a build or product works at a basic level overall.

Sanity testing checks a specific change or specific area after a fix.

In simple terms: smoke testing is a broad and shallow check, while sanity testing is a narrow and focused check.

How is sanity testing different from regression testing?

Regression testing checks existing functionality after changes and may cover many affected areas.

Sanity testing is usually smaller in scope. It checks the changed area and the closest related scenarios.

If sanity testing reveals risk or the change turns out to be broader than expected, the team may decide to run regression testing.

How is sanity testing different from retesting?

Retesting checks whether a specific bug was fixed.

Sanity testing checks the bug fix plus the closest functionality around it.

For example, retesting checks that password reset link now works. Sanity testing additionally checks that the user can log in with the new password, old link no longer works, expired link shows an error, and private page opens after login.

When should sanity testing be done?

Sanity testing should be done:

• after a bug fix;
• after a hotfix;
• after a small feature update;
• after a configuration change;
• after a validation change;
• after a UI component fix;
• after an API response fix;
• after a permission fix;
• after a production issue fix;
• before closing a bug or continuing broader QA.

What should be included in a sanity testing checklist?

At minimum, include:

• what changed;
• environment and build;
• test data;
• original bug or changed scenario;
• acceptance criteria;
• happy path;
• negative scenario;
• related scenario;
• data correctness;
• UI sanity;
• permissions, if affected;
• integrations, if affected;
• console/logs;
• pass / fail decision.

Should sanity testing be done after every bug fix?

Not after every small cosmetic fix, but after most functional bug fixes - yes.

If the fix affects a form, login, checkout, data, permissions, API, email, integration, or critical user flow, sanity testing is very useful.

Can sanity testing be automated?

Partly, yes. Good candidates for automation include:

• repeated bug fix checks;
• API sanity checks;
• form submit sanity;
• login sanity;
• checkout sanity;
• permission sanity;
• production health checks;
• critical workflow sanity.

Manual sanity testing is still useful for new fixes, UI changes, edge cases, and quick validation before release.

How do you know if a sanity test passed?

A sanity test can be considered passed if:

• original bug no longer reproduces;
• changed functionality works;
• acceptance criteria are met;
• basic happy path works;
• key negative scenario is handled;
• related scenario is not broken;
• data is saved correctly;
• there are no blocker or critical issues;
• there are no critical console or log errors;
• result is documented.

What should you do if sanity testing fails?

If sanity testing fails:

• document the issue;
• describe expected and actual result;
• attach steps, screenshot, or logs;
• return the bug/task to the developer;
• do not close the fix;
• do not expand testing unnecessarily until the basic issue is fixed;
• after the new fix, repeat sanity testing.

If the failure shows that the change affected more areas than expected, expand the scope to regression testing.