Password reset hotfix
Request reset email, follow link, set new password, and log in with the updated credentials.
Verify with confidence
Sanity Testing for modern web teams
Sanity testing is a narrow re-check after a bug fix or small change: did the fix work, and did we avoid obvious breakage nearby? It is deeper than smoke but far smaller than full regression.
Quick answer
What is sanity testing?
Sanity testing validates that a specific change behaves as intended and that related areas still basically work.
Teams run sanity passes after hotfixes, patch releases, or targeted feature work. Instead of re-running every historical case, testers focus on the changed module plus adjacent flows that share components or data.
Sanity differs from smoke in scope: smoke asks if the build is broadly usable; sanity asks if this particular fix or feature is safe to promote. It is often manual early on and becomes automated as recurring fixes stabilize.
Outcome
Confirm a fix without a full run
The workflow
How to run sanity testing
Design sanity as a reusable mini-suite tied to product areas.
-
Identify the change blast radius
Map screens, APIs-in-the-UI, and shared components touched by the fix.
-
Select targeted cases
Pull cases covering the fix scenario, one happy path, and one edge case for the same module.
-
Run on the environment that received the fix
Execute against staging or the hotfix branch URL so results reflect the build under test.
-
Time-box the pass
Sanity should finish quickly-if it approaches full regression length, you are running the wrong suite.
-
Promote only after sanity green
Make sanity a explicit gate in release checklists before merge to production.
In practice
Examples
Focused sanity checks after common web changes.
Tax calculation patch
Re-run checkout with multiple addresses and confirm tax lines update for the fixed region only.
Permissions bug fix
Verify the corrected role can access the admin screen and that other roles still cannot.
UI component library upgrade
Open pages using the updated date picker and modal across two product areas.
Best practices
Best practices
Sanity stays valuable when it is repeatable, not improvised every time.
-
Maintain sanity packs per module
Pre-build short case groups for billing, auth, and settings so hotfix nights are not ad hoc.
-
Record sanity flows once in automation
Turn recurring sanity checklists into recorded cases you can re-run in minutes.
-
Do not skip adjacent negative checks
Include one case that should fail or stay blocked to catch over-fixes.
-
Log sanity results with the change ticket
Attach run IDs or screenshots to the fix ticket for auditability.
From guide to repeatable system
How QAlity helps with sanity testing
Sanity checks stay fast when you re-run a tight subset of recorded flows in the cloud minutes after a fix lands.
How to stabilize automation API Testing
01
The challenge
After a hotfix, teams re-run entire regression suites to feel safe
How QAlity helps
Run targeted cases or mini-suites on demand
Select the cases tied to the changed module and execute them immediately in QAlity cloud. No need to queue a two-hour full suite for a one-line fix.
Cloud execution
02
The challenge
Sanity scripts rot because they are one-off manual checklists
How QAlity helps
Recorder keeps sanity flows reusable and readable
Turn the post-fix checklist into a short recorded case once. Next time the same area changes, re-run the same flow instead of rewriting steps.
Chrome recorder
03
The challenge
Teams need to confirm the fix on staging before promoting
How QAlity helps
Environment-specific runs separate staging sanity from production
Execute sanity against the environment where the fix landed so pass/fail reflects the build under test, not last week's production data.
Multiple environments
Questions, answered
What teams ask before they start
Quick answers to the most common questions teams have before getting started with QAlity.
When should we run sanity instead of full regression?
Run sanity after small, isolated fixes when time to release is short and the change touch surface is well understood. Run full regression when shared libraries, schemas, or auth models change.
How does QAlity speed up sanity testing?
Record module-specific sanity flows once, then re-run selected cases or mini-suites on demand in QAlity cloud-often minutes after a fix lands on staging.
Can sanity tests use different data than regression?
Yes. Sanity often uses lightweight fixtures focused on the fix scenario. Keep data isolated so sanity runs do not depend on long regression setup.
Start with one critical flow
Re-verify fixes in minutes
Run targeted sanity suites in QAlity cloud right after your hotfix build is ready.