Boundary Value Analysis (BVA) — Testing the "Edges" 📐

Welcome to Day 9 of my 15-day Manual Testing journey! 🛠️

Yesterday, we learned how to write the perfect Test Case**. But how do you decide what data to put in those cases? If a field accepts numbers from 1 to 100, do you test all 100? (Spoilers: No!). Today, we explore Boundary Value Analysis (BVA)—the secret to testing the "edges" where bugs love to hide.

Let’s get into the "Edge" logic! 📐

🔍 The "Cheat Code" Definitions

In software, bugs rarely hide in the middle of a range. They almost always hide at the boundaries. Boundary Value Analysis (BVA) is a technique where we test the exact limits of an input field.

Think of BVA as the "Border Patrol" of testing. Instead of testing everything, we test:

The Minimum: The smallest allowed value.

Just Below Minimum: One step into the "Forbidden Zone."

The Maximum: The largest allowed value.

Just Above Maximum: One step past the limit.

🧠 Memory Hook: The "Simple Life" Table

Scenario: An age field that accepts users from 18 to 60 years old.

💡 The "Elevator" Analogy

Imagine an elevator with a limit of 10 people.

If 5 people get in, it works (The Middle—usually safe).

If 10 people get in, it should work (The Boundary).

If 11 people get in, the alarm should go off (The "Edge" bug).

Most developers write code like if (people < 10). They often forget the = sign, so the elevator fails at exactly 10. That is why we test the edges!

🚀 Pro-Tip for New Testers

Whenever you see a range (dates, price, age, character limits), your first thought should be: "What happens at the very start and the very end?" Using BVA allows you to find 80% of logic bugs with only 6 test cases instead of 100!

💬 Let’s Chat!

Can you think of a time an app crashed because you entered a number that was "too high" or "too low"? Maybe a shopping cart or a password length? Tell me your "edge case" story below! 👇