You just received a new build. The developer says they fixed a critical bug and made a small change to the search feature. Do you run the entire regression suite? Of course not — that would take hours. Instead, you run a sanity test. Sanity testing is a subset of regression testing that verifies whether a specific bug fix or new feature works as expected, without testing the entire application.
Sanity Testing in Simple Terms
After a developer fixes a bug or adds a small feature, you don't re-test the entire application. Instead, you do a focused sanity check on just that change and the areas immediately around it.
Example: A developer fixes a bug where the "Forgot Password" email wasn't sending. Sanity testing would verify: 1. The email sends correctly now 2. The reset link in the email works 3. Password can be changed via the link 4. Login works with the new password
You wouldn't test unrelated features like search or checkout.
Sanity vs Smoke vs Regression Testing
| Aspect | Smoke | Sanity | Regression | |--------|-------|--------|------------| | Scope | Entire build | Specific fix/feature | Full test suite | | Depth | Shallow | Moderate | Deep | | When | New build | After bug fix | Before release | | Time | 5-15 min | 15-60 min | Hours to days | | Goal | Build stability | Fix verification | No regressions |
When to Perform Sanity Testing
- After a developer marks a bug as fixed
- After a minor feature update or configuration change
- When time is limited and full regression isn't feasible
- During hotfix deployments
- After environment-specific fixes
Best Practices
- Focus on the change — test the fix and its immediate neighbors
- Document what you tested — even a brief note helps
- Include boundary conditions — don't just test the happy path
- Know when to escalate — if sanity reveals more issues, trigger full regression testing
- Use [test cases](/resources/test-case-template) as a reference, but don't follow them rigidly
Sanity Testing is a Skill
Good sanity testing requires judgment. You need to understand the code change well enough to know what might break around it. This comes with experience and domain knowledge. It's one of the skills that separates a good QA engineer from a great one.
Learn more about essential QA skills in our career roadmap.