Software Testing:

The fastest way to know if a deployment is fundamentally broken — a quick sanity check that runs in minutes and gates every release.

The New Car Mystery

Imagine you just built a car from scratch. Before selling it, what would you test?

Think about different scenarios:

• Does the engine start? (Basic functionality)
• Do all doors open? (Individual components)
• Can it drive on the highway? (Complete journey)
• Does the radio work while driving? (Components working together)
• What happens in a 10-car pile-up? (Extreme stress)
• Can it handle 100,000 miles? (Long-term reliability)

Pause and think:

Would you test these all at once?

Would you test in a specific order?

What if you only had time for one test before the customer arrives?

The Answer: Different Testing Types for Different Goals

Just like testing a car requires multiple approaches, software testing has different types for different purposes:

Smoke Testing:

"Does it turn on?"

Functional Testing:

"Does each feature work?"

Integration Testing:

"Do parts work together?"

System Testing:

"Does the complete system work?"

API Testing:

"Do the interfaces work correctly?"

E2E Testing:

"Can a user complete their journey?"

Stress Testing:

"What breaks it?"

Chaos Testing:

"Can it survive disasters?"

Key insight: No single test type is enough! You need a testing strategy that combines different approaches at different stages!

🏗️ The Testing Pyramid: Foundation of Test Strategy

Before diving into each type, understand how they relate:

Mental model: Like building inspections:

• Bottom (Unit/Functional): Individual bricks are solid
• Middle (Integration): Walls are properly connected
• Top (System/E2E): Entire building is safe to occupy
• Stress/Chaos: Building survives earthquakes

💨 Smoke Testing: "Does It Even Work?"

What is Smoke Testing?

Smoke testing (aka sanity testing) is the quickest, most basic check to verify the software isn't fundamentally broken.

Origin of the name: When hardware engineers power on a circuit board, they check if smoke comes out. No smoke = safe to proceed with more tests!

Real-World Analogy:

Like checking a house before showing it to buyers:

Quick 5-minute walkthrough:

✓ Does the front door open?

✓ Do lights turn on?

✓ Is there electricity?

✓ Does water run?

If YES →

Show the house

If NO →

Fix critical issues first!

Smoke Test Examples:

Web Application:

Smoke Test Suite (runs in 2 minutes):

1. Can user load homepage?

2. Can user log in?

3. Can user see their data?

4. Is database responding?

If ALL pass → Deploy to QA environment If ANY fail → Roll back immediately!

E-commerce Platform:

Critical path smoke tests:

□ Homepage loads

□ Search works

□ Product page displays

□ Add to cart functions

□ Checkout button appears

If these fail, nothing else matters!

When to Run Smoke Tests:

Development Pipeline:

1. Code Commit

2. Build

3. [Smoke Tests]

4. Pass? → Full Test Suite

   ↓

   FAIL

   ↓

5. Notify developer immediately!

6. Don't waste time on broken build

Key characteristics:

• ⚡ Fast: 2-10 minutes maximum
• 🎯 Critical path only: Test what matters most
• 🚨 First line of defense: Catch obvious breaks
• 🔄 Run frequently: After every build/deploy

Key Takeaways

1. Smoke tests verify basic functionality after a build or deployment — a quick sanity check that the system starts and core features work
2. Smoke tests should run fast (under 5 minutes) — they gate deployments, so speed matters more than coverage
3. A failing smoke test means the build is fundamentally broken — stop deployment immediately and investigate
4. Keep smoke tests focused on critical paths — login, homepage load, primary API health check, database connectivity