Positive tests prove that intended workflows succeed. Negative tests prove that invalid or disallowed behavior fails safely. Strong coverage needs both, but each case should test a meaningful rule rather than inflate a count.
What is a positive test case?
A positive test 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 a negative test case?
A negative test uses invalid, missing, expired, duplicate, unauthorized, or boundary-breaking input. It verifies safe rejection, no unintended side effects, and a useful error or recovery path.
Positive and negative examples
| Feature | Positive example | Negative example |
|---|---|---|
| Login | Valid active account signs in. | Wrong password is rejected without revealing whether an account exists. |
| Checkout | Available item and valid payment complete the order. | Expired payment method is declined without creating an order. |
| API | Valid authorized payload returns the documented success response. | Missing required field returns the documented validation response. |
| File upload | Supported file within the size limit uploads. | Unsupported or oversized file is blocked with guidance. |
Use a simple design pattern
Given: the user, data, permissions, and system state
When: the user performs one focused action
Then: verify the result, message, state change, and side effectsAvoid duplicate cases
Do not create separate cases when the only difference is wording. Use equivalence classes and boundaries: empty, minimum, just below minimum, maximum, just above maximum, malformed, and unauthorized where those rules exist.
Using AI responsibly
Give AutomationTekAI the actual validation and permission rules, request both types, and review every result. AI may suggest useful risks, but suggestions are not requirements until the product owner or source documentation confirms them.
Review checklist
- Does each case trace to a requirement, boundary, permission, or known risk?
- Is the expected result observable and specific?
- Does the negative case verify that state was not changed?
- Are security-sensitive errors neutral and free from unnecessary disclosure?
- Are test data and cleanup requirements clear?