Test Case Design
Positive and Negative Test Cases with Practical Examples
Understand positive and negative testing with practical login, registration and API test-case examples.
Introduction
Positive tests prove intended workflows succeed. Negative tests prove invalid or disallowed behaviour fails safely. Strong suites need both, but each case should verify a meaningful rule rather than inflate a count.
What is positive testing?
Positive testing uses valid data, a permitted role and the expected sequence. It confirms the primary business outcome and important variations of the happy path.
What is negative testing?
Negative testing uses invalid, missing, expired, duplicate, unauthorized or boundary-breaking input. It verifies safe rejection, no unintended side effects and a useful recovery path.
Key differences
| Aspect | Positive testing | Negative testing |
|---|---|---|
| Goal | Confirm valid behaviour succeeds | Confirm invalid behaviour is rejected safely |
| Typical data | Valid email and correct password | Invalid email, wrong password, missing fields |
| Success signal | Expected outcome is achieved | Error handling and unchanged state are correct |
| Risk focus | Core value delivery | Abuse, misuse and fragile edges |
Why both are required
A suite that only covers happy paths can miss validation gaps, permission failures and recovery behaviour. A suite that only covers failures can miss regressions in the primary workflow customers rely on.
Login-form examples
- Valid email and correct password → successful sign-in
- Valid email and incorrect password → generic rejection
- Missing required fields → accessible validation
- Maximum field length and malformed email → rejected according to rules
Registration-form examples
- Valid unique email and policy-compliant password → account created
- Duplicate email → blocked with a clear recovery path
- Password below minimum length → blocked with the applicable rule
- Unsupported characters in a required field → rejected safely
API examples
Expected HTTP status codes depend on the documented API contract. Use the values your service publishes rather than assuming every API behaves the same way.
| Scenario | Example focus | What to verify |
|---|---|---|
| Valid authorized request | Correct token and payload | Documented success response and side effects |
| Invalid API token | Expired or malformed token | Unauthorized response and no protected change |
| Missing authorization header | No auth header | Documented auth failure behaviour |
| Unsupported HTTP method | POST to a GET-only resource | Method-not-allowed or documented equivalent |
| Invalid request payload | Missing required field | Validation response without partial writes |
Boundary-value examples
- Empty, minimum, just below minimum, maximum and just above maximum lengths
- Zero, one and limit-plus-one for counters such as login attempts
- First and last valid characters in allowed character sets
Common mistakes
- Writing many near-duplicate cases with only wording changes
- Treating every AI suggestion as a confirmed requirement
- Checking only the error message and ignoring side effects
- Assuming identical API status codes across unrelated services
Test-design checklist
- Does each case map to a rule, boundary, permission or known risk?
- Is the expected result observable and specific?
- Does the negative case confirm that state did not change incorrectly?
- Are test data and cleanup requirements clear?
How AutomationTekAI can help
Provide the actual validation and permission rules, then ask AutomationTekAI for both positive and negative scenarios from the Generate workflow. Review every assumption before export.
Key takeaways
- Positive and negative testing answer different risk questions.
- Boundaries and equivalence classes keep suites efficient.
- API expectations belong to the published contract.
Frequently asked questions
What is a positive test case?
A positive case verifies that valid input and an allowed workflow produce the expected successful result.
What is a negative test case?
A negative case verifies that invalid, missing, unauthorized or unexpected input is rejected safely and explained clearly.
Do all APIs return the same status codes?
No. Expected status codes and messages depend on the documented API contract for that service.