Negative Testing: Design Checks for Things That Should Fail
By Xusheng YangA purchase request should require approval before it becomes an order. The normal workflow works. The defect appears when someone opens an old confirmation link and creates the order while the request is still a draft.
Negative testing checks behavior under conditions the system should reject or handle as unsuccessful. A useful negative test establishes the intended refusal and verifies that the rejected operation did not quietly take effect.
This is part 6 of Testing Methods in Practice. The approval policy is a fictional example; the cases below are specifications, not recorded test results.
Start from a known valid operation
Define the reference flow: an employee creates a request with an amount and reason; a different authorized approver approves it; the employee converts that approved request into one order.
For this example, employees cannot approve their own requests. Rejected requests cannot become orders. Approval applies to a specific version of the amount and reason. Changing either after approval returns the request to review.
Now identify the prerequisites for conversion: authenticated user, access to this request, an approved current version, and no existing order. Negate or remove one prerequisite at a time. This makes the resulting failure easier to interpret.
Build cases around different kinds of invalidity
| Variation | Expected response | State that must be preserved |
|---|---|---|
| Submit a request without a reason | Explain the missing field | No submitted request is created |
| Approve your own request | Deny the action | Approval remains absent |
| Convert a draft directly | Explain approval is required | No order is created |
| Edit the amount after approval, then convert | Require approval of the changed version | Old approval cannot authorize the new amount |
| Convert another workspace's request | Deny access under the documented disclosure policy | No foreign request or order is changed |
| Convert the same approved request again | Return the documented existing-order or duplicate outcome | Exactly one order remains |
Some of these conditions require API or integration checks. A hidden button is useful interface behavior, but does not establish that the corresponding operation is enforced on the server.
Write more than an error-message assertion
For each rejection, check three things: the operation is refused for the intended reason, the user receives appropriate feedback, and protected state remains correct.
For the changed-amount case, inspect the order count and the version referenced by approval. If a forbidden order is briefly created and later deleted, the final count alone may miss a notification or payment side effect. Use audit or integration evidence where those effects matter.
Do not require detailed error text that leaks another workspace's existence. Define the disclosure rule with the product and security team before asserting a specific message or status code.
The OWASP guide on circumventing workflows recommends developing misuse cases around skipped, reordered, and repeated business steps. Those variations are useful alongside ordinary invalid form values.
Verify recovery after the rejection
An employee who submits an empty reason should be able to enter a reason and submit successfully without losing the amount. An employee whose session expires should understand whether reauthentication preserves the draft. A denied conversion should not leave the screen stuck in a loading state.
Keep recovery as an explicit continuation of the case. The error recovery guide expands this into failures before, during, and after a server operation.
For browser execution, use dedicated accounts and controlled fixtures. Write visible actions and results, then label server-state checks as external evidence when your browser tool cannot establish them. HiTest supports documenting browser steps and choosing an appropriate run type in manual test case creation.
Avoid combining every invalid condition
A signed-out employee with an invalid amount and a foreign request might be rejected by authentication before the other conditions are considered. That does not prove amount validation or workspace isolation.
Test those conditions independently first. Add selected combinations to check precedence and information disclosure after each basic rule has evidence. A decision table is useful when several invalid conditions compete for the displayed outcome.
A reusable exercise
Choose one operation that changes durable data. List its prerequisites and write one negative case for each. For every case, include the allowed recovery and the state or side effect that must not occur.
Then review the cases with someone who owns the rule. If the expected rejection is uncertain, resolve the policy before preserving it in automation. Negative tests are valuable when they protect agreed behavior, including what the system must refuse to do.
Next in the series: Error recovery testing.