The template
| Field | Example |
|---|---|
| ID | TC-LOGIN-003 |
| Title | Login fails with wrong password |
| Priority | High |
| Preconditions | User account exists; user is logged out |
| Test data | Email: test@example.com; Password: wrong123 |
| Steps | 1. Open the login page. 2. Enter email and wrong password. 3. Press Log in. |
| Expected result | An error message ‘Incorrect email or password’ appears; the user stays on the login page; no session is created. |
| Actual result / status | Filled in at execution: Pass / Fail |
Writing rules
- One behaviour per test case
- Steps that anyone on the team can follow
- Expected results that are specific and observable
- Include test data, not ‘valid email’
- Keep titles searchable: feature, condition, result
What to cover for each feature
- Happy path: the normal successful flow.
- Negative cases: invalid, missing or forbidden input.
- Boundary values: minimum, maximum, empty, very long.
- Permissions: who can and cannot do this.
- Interruptions: network loss, double-click, back button.
- Cross-device: key browsers and phone sizes.
Example: checkout set
- Successful card payment
- Declined card message and retry
- Coupon applied and removed
- Out-of-stock item at checkout
- Double-click on ‘Pay’ does not charge twice
- Receipt email received
Get your app tested QA from $20/h
Tell us your app, platforms and release date. We scope the hours and quote.
Frequently asked questions
How many test cases do I need?
Enough to cover the risks of each feature; start with critical journeys and grow as the product grows.
Should test cases be automated?
Automate stable, repeated ones; keep new and exploratory cases manual. See manual vs automation testing.
Can you write test cases for my product?
Yes. Test design is part of our QA service.
Get a free quote in 24 hours
Tell us what you need. We reply with scope, timeline and a fixed price.