# Test case template with examples

QA Hub · Version 1 · 22 October 2026

Copy the blank template into your issue tracker or test management tool. Keep one primary behavior per case. Expected results must be observable, and a different tester should be able to reproduce the setup without asking the author.

## Blank template

| Field | Value |
| --- | --- |
| ID and title | |
| Requirement / acceptance criterion | |
| Risk and priority | Explain the business impact |
| Environment / build | |
| Preconditions | Account, role, state, dependencies |
| Test data | Exact values or a reproducible generator |
| Cleanup | Records to remove / state to restore |

| Step | Action | Expected result |
| --- | --- | --- |
| 1 | | |
| 2 | | |
| 3 | | |

Execution: date · tester · actual result · Pass/Fail/Blocked/Not run · evidence · defect link.

## Example 1 — Reject a quantity above the allowed maximum

**ID:** ORDER-BOUNDARY-02  
**Requirement:** The example product accepts integer quantities from 1 through 10 inclusive. Invalid input must not create an order or reserve stock.  
**Priority:** High: incorrect validation can reserve unintended inventory.  
**Environment:** Staging; record the deployed build.  
**Preconditions:** Authorized test buyer, test product in stock, no pending order for this test run. Record the initial stock and order count.  
**Data:** Quantity `11`; a unique test-run reference.  
**Cleanup:** Remove only records tagged with this test-run reference, if unexpectedly created; restore any affected test stock.

| Step | Action | Expected result |
| --- | --- | --- |
| 1 | Open the test product and enter quantity 11 | The entered value is visible |
| 2 | Submit the order | Validation explains the allowed range; no order confirmation appears |
| 3 | Inspect the order list and stock through the approved test interface | No new order or reservation exists for this test run |

Additional cases: `0`, `1`, `10`, fractional quantity, empty input. Create distinct cases where expected behavior differs. The range above is an example requirement, not a standard for every shop.

## Example 2 — Prevent access to another user's order

**ID:** ORDER-AUTH-01  
**Requirement:** A buyer may read only their own orders. The API specification for this example requires `403` for an authenticated non-owner.  
**Preconditions:** Test buyers A and B; an order owned by B. Both accounts and the order belong to the test environment.  
**Data:** B's order ID, A's valid access token. Do not save the token in evidence.  
**Cleanup:** Remove the prepared test order using the authorized cleanup account.

| Step | Action | Expected result |
| --- | --- | --- |
| 1 | As B, request B's order | The response contains the prepared order |
| 2 | As A, request the same order ID | Status 403, per this example's contract |
| 3 | Inspect the entire error response | No order details or private information are disclosed |

Some products deliberately return `404` to conceal object existence. Use the product's agreed contract for your real case.

## Review before execution

- Can the preconditions be reproduced?
- Do the steps identify exact actions and data?
- Do assertions cover the business effect, not just a message?
- Are the expected status and error text backed by a requirement?
- Does evidence avoid credentials and personal data?
- Is cleanup limited to the test's own data?

Read next: https://qahub.pro/en/documentation/test-case