For any feature you test, your cases will fall into three buckets: positive, negative, and edge. Inexperienced testers write mostly positive cases. Decent testers write a mix of positive and negative. Experienced testers cover all three deliberately and know which bucket each case belongs to.
The three buckets, with a login form
Test types for a login form
| Example | Purpose | |
|---|---|---|
| Positive | Valid email + correct password | Confirm the happy path works |
| Negative | Valid email + wrong password | Verify error handling |
| Edge case | Email with 255 characters | Test boundary limits |
Take a simple login form with email and password fields. Here is how cases distribute across the three buckets.
Positive cases verify the happy path. The system should accept valid input and produce the expected outcome:
- Login with a valid email and the correct password → redirected to dashboard.
- Login with an email that has been recently changed → still accepted with the new email.
- Login with case-insensitive email (
User@Example.comvsuser@example.com) → accepted. - Login from a known device → no extra verification.
Negative cases verify that the system rejects invalid input gracefully:
- Login with a valid email and the wrong password → "incorrect email or password" error, no login.
- Login with an email that does not exist → same error (do not reveal which is wrong, for security).
- Login with an empty email field → "email is required" error.
- Login with a malformed email (
notanemail) → format validation error. - Login with the password missing → password validation error.
- Login attempt while the account is locked → "account locked" message with appeal link.
Edge cases probe the corners — input that is technically valid but unusual:
- Email with the maximum allowed length.
- Email with international characters or emojis (
你好@example.com). - Email with multiple plus signs (
user+a+b+c@example.com). - Password at exactly the minimum and maximum lengths.
- Login attempted exactly at midnight on the day the account was created.
- Login attempted simultaneously from two devices.
- Login while the user is mid-password-reset on another device.
- Browser back-button after a successful login.
The edge bucket is where the most surprising bugs hide and where unprepared testers leave gaps.
Why each bucket matters
Positive cases prove the feature works for real users. They are essential, but they are not enough — a system can pass all positive cases and still be deeply broken. An attacker only needs one negative case the developer forgot.
Negative cases prove the feature fails safely. The system should reject bad input clearly, without crashing, exposing internals, or corrupting state. Negative cases are the meat of security and reliability testing.
Edge cases prove the feature works at the borders, where developer assumptions are most likely to be wrong. Most production bugs are edge cases that nobody considered until a real user hit them.
A complete test plan for a feature has cases in all three buckets. The ratio depends on the feature: a public-facing form needs heavy negative coverage; an internal admin tool needs lighter negative but careful edge coverage of the data it manipulates.
How to generate negative and edge cases
Positive cases are easy — they fall out of the spec. Negative and edge cases require deliberate technique:
- For each input field, list the invalid forms. Empty, too long, wrong type, special characters, malformed.
- Apply boundary value analysis. For any range, test min-1, min, max, max+1.
- Apply equivalence partitioning. Make sure you have at least one case from each invalid class.
- Use heuristics like SFDPOT. For each axis (Structure, Function, Data, Platform, Operations, Time), what could go wrong?
- Imagine an adversary. What would a user trying to abuse this feature attempt?
Combine these and you will rarely have a feature with thin negative or edge coverage.
A common ratio
For a typical feature, a healthy distribution of test cases might look like:
- ~30% positive (the feature works)
- ~50% negative (the feature rejects bad input correctly)
- ~20% edge (the feature handles unusual valid input)
The exact ratio matters less than the principle: a test plan that is 90% positive cases is a leaky test plan, regardless of how many cases it contains.
What you should walk away with
Positive cases prove the feature works. Negative cases prove it fails safely. Edge cases prove it handles the corners. A serious test plan has all three, in deliberate proportions. The next lesson is the bookkeeping side of test cases: the traceability matrix that maps cases back to requirements.