Early in my QA career, I was assigned a bug to test, a minor fix in one of the key modules of our enterprise portal. I opened the application, focused only on the specific scenario mentioned in the ticket, confirmed that the issue was resolved, and confidently marked it as "Done"
A while later, my team lead reviewed the same fix but took a different path to reach the same functionality. Within minutes, he uncovered a new issue that had been introduced as a side effect of the fix.
He turned to me and asked, "Did you check this part?"
"Yes," I replied, "I tested it."
But what I really meant was: I only checked what I was told to check.
Watching him test it in front of me - navigating different routes, trying other workflows - I realized how limited my approach was. That bug fix had impacted a different module, something I hadn't even considered. That's when it clicked:
✅ Fix validation = Sanity Testing
Smoke Testing — “Are We Good to Go?”
When to use: After a new build is deployed Goal: Quickly check if the major features work before deeper testing
Imagine getting a fresh build after developers have pushed new code. Before diving into detailed testing, you want to know if the basic flows are working like login, navigation, dashboard load, etc. That’s where smoke testing comes in.
Think of it as: You move into a new apartment. The first thing you do? Flip on the lights, turn on the faucet, and check if the stove works — just making sure the basics are up and running.
Example: In one of my projects, after every deployment, I’d run a smoke test checklist that included:
Logging in with a valid user
Navigating to key modules
Checking if forms load
Submitting basic workflows without validation rules
If any of these failed — we’d stop testing and report the errors to developers.
Sanity Testing — “Did the Fix Actually Work?”
When to use: After a bug fix or small code change Goal: Verify that the fix works and didn’t break anything around it
Sanity testing is more focused than smoke testing. When a developer fixes a defect, we need to verify that the issue is resolved and that the functionality related to it still works as expected.
Think of it as: You ordered a sandwich with no onions. It came with onions, so you sent it back. Sanity testing is lifting the bread to make sure they actually removed the onions this time before you eat it. You’re not judging the whole sandwich’s taste yet, just checking the specific fix.
Example: Let’s say there was a bug where users were unable to reset their passwords through the account settings. After the fix, I:
Tried resetting the password with a valid email
Checked the password reset email was received
Followed the link to set a new password
Logged in using the new password
I did not test the entire login or registration process but just enough to confirm the password reset functionality was working properly and did not break related flows.
Regression Testing — “What Else Did We Break?”
When to use: After multiple fixes, new features, or before a release Goal: Make sure that existing features still work properly after any changes
Regression testing goes beyond just checking the fix. It’s about testing the impact of changes across the system, to make sure old features weren’t unintentionally broken.
Think of it as: You move the sofa to a new spot. Then you walk through the room to check if you can still open doors, reach the light switch, and have space to move, just to make sure one change didn’t disrupt the whole setup.
Example: When developers fixed a bug in the password reset flow. After the fix, I didn’t just test the reset, I also:
Tried logging in with the new password
Checked the “forgot password” link on both login.
Verified the reset email content and link expiration
Logged in as a new user to make sure nothing broke in the login system
This helped ensure that changes to authentication didn’t affect other login-related features.
Conclusion:
Understanding the difference between smoke, sanity, and regression testing is not just about knowing definitions but about applying the right approach at the right time. Smoke testing checks if the basic flow of the application is stable enough for further testing. Sanity testing quickly verifies specific fixes or changes without diving deep. Regression testing ensures that existing functionality remains unaffected by recent updates. Together, these testing types help QA teams catch issues early. It’s a simple shift that makes a big impact on quality and confidence in your releases.
