Test Execution Approaches

🎯 Test Execution Approaches: The Detective’s Toolkit

Imagine you’re a detective checking if a vending machine works perfectly. You don’t just press one button once — you try EVERYTHING to make sure it never fails!

🌟 The Big Picture

Testing software is like being a detective who tries to break things on purpose. Why? Because if YOU find the problem first, users never will!

Think of a vending machine. Before putting it in a mall, you’d want to check:

• Does it give the right snack when I pay? ✅
• What if I don’t pay enough? 🚫
• What if I press buttons really fast? ⚡
• What happens at the exact limit? 📏

These are the 8 Testing Approaches we’ll learn today!

1️⃣ Positive Testing: “The Happy Path”

What Is It?

Testing with correct inputs to make sure things work when used properly.

🍕 Real-Life Example

You order a pizza with valid toppings. The restaurant should make it correctly!

Input: Order pizza with cheese and pepperoni
Expected: Pizza arrives with cheese and pepperoni
Result: ✅ SUCCESS!

💡 Key Idea

“If I do everything RIGHT, does it work RIGHT?”

Simple Code Example

// Testing a calculator's add function
function add(a, b) {
  return a + b;
}

// Positive test: Valid numbers
add(2, 3)  // Should return 5 ✅
add(10, 20) // Should return 30 ✅

2️⃣ Negative Testing: “The Troublemaker Path”

What Is It?

Testing with wrong inputs to make sure the system handles mistakes gracefully.

🍕 Real-Life Example

You try to order pizza with “rocks” as a topping. The restaurant should say “Sorry, we can’t do that!”

Input: Order pizza with rocks
Expected: "Invalid topping" error message
Result: ✅ System handled it well!

💡 Key Idea

“If I do something WRONG, does it fail GRACEFULLY?”

Simple Code Example

// Testing login with wrong password
login("user@email.com", "wrongpassword")
// Should show: "Invalid credentials"
// Should NOT crash the system!

Why It Matters

Users WILL make mistakes. Your app should guide them, not explode! 💥➡️🤝

3️⃣ Edge Case Testing: “The Boundary Explorer”

What Is It?

Testing at the extreme limits — the very first, very last, minimum, or maximum values.

🎢 Real-Life Example

A roller coaster says “You must be between 4ft and 7ft tall.”

💡 Key Idea

“What happens at the EXACT edges?”

Simple Code Example

// Age must be 18-65 for insurance
function canGetInsurance(age) {
  return age >= 18 && age <= 65;
}

// Edge case tests:
canGetInsurance(18)  // ✅ Just allowed
canGetInsurance(17)  // 🚫 Just too young
canGetInsurance(65)  // ✅ Just allowed
canGetInsurance(66)  // 🚫 Just too old

4️⃣ Error Handling Testing: “The Crash Preventer”

What Is It?

Making sure the system shows helpful error messages instead of crashing.

🏧 Real-Life Example

An ATM runs out of cash. Instead of showing “ERROR 500 SYSTEM FAILURE,” it should say: “Sorry, this ATM is temporarily out of cash. Try the one nearby!”

graph TD
    A["User Action"] --> B{Error Occurs?}
    B -->|No| C["Continue Normally"]
    B -->|Yes| D["Show Friendly Message"]
    D --> E["Log Error for Developers"]
    D --> F["Suggest Next Steps"]

💡 Key Idea

“When things break, does it help the user or confuse them?”

Good vs Bad Error Messages

5️⃣ Input Validation Testing: “The Gatekeeper”

What Is It?

Checking that the system rejects bad data BEFORE processing it.

📝 Real-Life Example

A form asks for your phone number. If you type “banana,” it should say “Please enter numbers only!”

Types of Input to Validate

💡 Key Idea

“Stop bad data at the door!”

Simple Code Example

function validateEmail(email) {
  // Must have @ and a dot
  if (!email.includes("@")) {
    return "Email must have @";
  }
  if (!email.includes(".")) {
    return "Email must have a domain";
  }
  return "Valid!";
}

validateEmail("test")      // "Email must have @"
validateEmail("test@com")  // "Email must have a domain"
validateEmail("a@b.com")   // "Valid!"

6️⃣ Output Validation Testing: “The Quality Checker”

What Is It?

Making sure the result that comes out is correct, complete, and in the right format.

🧾 Real-Life Example

You buy 3 items at $10 each. The receipt should show:

• ✅ 3 items listed
• ✅ Total = $30
• ✅ Tax calculated correctly
• ✅ Date and time shown

What to Check in Outputs

graph TD
    A["Output Validation"] --> B["Correct Value?"]
    A --> C["Right Format?"]
    A --> D["Complete Data?"]
    A --> E["Proper Precision?"]

    B --> B1["2+2 should = 4"]
    C --> C1["Date: MM/DD/YYYY"]
    D --> D1["All fields present"]
    E --> E1["$10.00 not $10.001"]

💡 Key Idea

“Is what comes OUT exactly what should come out?”

Simple Code Example

function formatPrice(cents) {
  return "quot; + (cents / 100).toFixed(2);
}

// Output validation tests:
formatPrice(1000)  // Should be "$10.00" ✅
formatPrice(1)     // Should be "$0.01" ✅
formatPrice(999)   // Should be "$9.99" ✅
// NOT "$10" or "$10.0" or "10.00"

7️⃣ Test Preconditions: “The Setup Checklist”

What Is It?

Checking the starting conditions before a test runs. Is everything ready?

🎬 Real-Life Example

Before filming a movie scene:

• ✅ Camera is charged
• ✅ Actors are in position
• ✅ Lights are on
• ✅ Sound is recording

If ANY of these isn’t ready, you can’t start!

💡 Key Idea

“Is everything SET UP correctly BEFORE we begin?”

Common Preconditions

Simple Code Example

// Test: User can view their orders
// PRECONDITIONS:
// 1. User must be logged in
// 2. User must have at least 1 order

function testViewOrders() {
  // Check preconditions first!
  if (!user.isLoggedIn) {
    return "SKIP: User not logged in";
  }
  if (user.orders.length === 0) {
    return "SKIP: No orders to view";
  }

  // Now run the actual test...
  const orders = getOrders(user.id);
  return orders.length > 0 ? "PASS" : "FAIL";
}

8️⃣ Test Postconditions: “The Cleanup & Verify”

What Is It?

Checking the ending state after a test. Did everything end up correct?

🧹 Real-Life Example

After a cooking show:

• ✅ Dish is complete and looks right
• ✅ Kitchen is cleaned
• ✅ All ingredients are put away
• ✅ Stove is turned off

💡 Key Idea

“After the action, is the FINAL STATE correct?”

What to Verify

graph TD
    A["Action Completed"] --> B["Postcondition Checks"]
    B --> C["Data Changed Correctly?"]
    B --> D["Side Effects Correct?"]
    B --> E["System in Valid State?"]
    B --> F["Cleanup Done?"]

Simple Code Example

// Test: Delete a user account
function testDeleteUser() {
  // Action
  deleteUser("user123");

  // POSTCONDITIONS to verify:
  // 1. User no longer exists in database
  const userExists = findUser("user123");
  assert(userExists === null);

  // 2. User's posts are also deleted
  const userPosts = findPosts("user123");
  assert(userPosts.length === 0);

  // 3. User's session is ended
  const session = getSession("user123");
  assert(session === null);

  return "PASS: All postconditions met!";
}

🔄 How They All Work Together

Think of testing a shopping cart:

graph TD
    A["📋 PRECONDITIONS"] --> B["User logged in<br/>Product exists<br/>Cart is empty"]
    B --> C["▶️ ACTION: Add item to cart"]

    C --> D["✅ POSITIVE TEST"]
    D --> D1["Add valid item → Item appears"]

    C --> E["❌ NEGATIVE TEST"]
    E --> E1["Add deleted item → Error shown"]

    C --> F["📏 EDGE CASE"]
    F --> F1["Add max 99 items → Limit message"]

    C --> G["⚠️ ERROR HANDLING"]
    G --> G1["Network fails → Retry option"]

    C --> H["📥 INPUT VALIDATION"]
    H --> H1["Quantity = -5 → "Invalid""]

    C --> I["📤 OUTPUT VALIDATION"]
    I --> I1["Total = correct sum"]

    D1 --> J["📋 POSTCONDITIONS"]
    E1 --> J
    F1 --> J
    J --> K["Cart has correct items<br/>Stock updated<br/>Price calculated"]

🎯 Quick Summary

🌟 Remember This!

Good testers think like detectives AND troublemakers. They try everything — the right way, the wrong way, and the weird way — to make sure the software is bulletproof! 🛡️

You’re not trying to prove it works. You’re trying to prove it CAN’T break!

Now you know all 8 testing approaches! Go find those bugs before users do! 🐛🔍