← Back to libraryQuestion 246 of 273
📋Software TestingIntermediate

Regression Testing & Smoke Testing

📌 Definition:

Regression = re-testing existing features after changes. Smoke = quick health check before detailed testing.

📖 Detailed Explanation:

Regression testing and smoke testing are different but often confused. Regression is comprehensive (test all existing features). Smoke is quick (test only critical features). Think of smoke as 'is the system alive?' and regression as 'did we break anything?'

📎 Regression Testing:
Definition:

Re-testing existing functionality to ensure recent code changes didn't break anything

Why Needed:

Every code change risks breaking existing features. Need to verify no unintended side effects.

When Needed:
  • After bug fixes - Fix for one bug might break another feature
  • After new features - New code might interfere with existing code
  • After database updates - Schema changes might affect queries
  • Before production release - Final verification everything still works
Scope:

Previously working features (could be entire application)

Best Test Coverage:

80-90% of previously tested features

Automation Friendly:

Yes - highly recommended. Automation is perfect for regression.

Typical Example:
Scenario:

Fixed login bug where app crashed on 'forgot password'

Regression Test Flow:
  • Test login with valid credentials - Still works?
  • Test login with invalid credentials - Still shows error?
  • Test 'forgot password' flow - Fixed?
  • Test account lockout after 5 failed attempts - Still works?
  • Test password reset link - Still works?
  • Test remember me checkbox - Still works?
  • Test logout - Still works?
Regression Suite Examples:
  • Daily Regression Suite: 50 critical tests, runs overnight (15 minutes)
  • Weekly Regression Suite: 200 tests, runs every Friday (2 hours)
  • Pre-Release Regression Suite: All 1000 tests, runs before go-live (12 hours)
📎 Smoke Testing:
Definition:

Quick, shallow testing to verify basic functionality works before deep testing

Why Needed:

If critical features are broken, don't waste time on deep testing. Find showstoppers quickly.

When Needed:
  • After deployment - Verify system is live and responds
  • After new build - Before assigning detailed test cases
  • Before regression testing - No point testing if login is broken
Scope:

Only critical functionalities (happy paths only)

Typical Smoke Test Cases:
  • Application starts/loads
  • Login works with valid credentials
  • Navigation menu appears
  • Database connectivity working
  • Critical features load without errors
Execution Time:

5-15 minutes (very fast)

Automation Friendly:

Yes - should be automated for instant feedback

Smoke Test Example:
Scenario:

E-commerce site deployment

Smoke Tests:
  • TC1: Homepage loads in <3 seconds
  • TC2: User can search for products
  • TC3: User can add item to cart
  • TC4: Checkout button visible
  • TC5: Payment page loads
  • Pass/Fail: All must PASS. If any fails, deployment blocked.
📎 Relationship And Sequence:
Workflow:

New Build → Smoke Testing → If Pass → Full Regression Testing → If Pass → Release

Decision Tree:
  • Step 1: Run Smoke Test (5 min). If FAIL → Block. Stop here.
  • Step 2: If PASS → Run Regression Test (2 hours). If FAIL → Investigate.
  • Step 3: If PASS → Release to production
📎 Key Differences:
Comparison:
AspectSmokeRegression
ScopeCritical features only (5-10 tests)All existing features (100-1000 tests)
Time5-15 minutes2-12 hours
PurposeVerify system is aliveEnsure changes didn't break anything
When RunAfter every buildBefore release or after major changes
DepthShallow - happy path onlyDeep - all scenarios
🎯 Scenario-Based Interview Question:

You have 1000 test cases for regression. Release deadline is 4 hours away. Smoke tests all passed. Do you run full regression or deploy? Why?

💡 Quick Tip:

🔄 Smoke = Quick health check (5 min). Regression = Comprehensive verification (hours). Use both: Smoke first, if pass → Regression.

💡 Interview Focus:

Interviewers want to see you understand the purpose of each test type and make smart trade-offs.