In this guide
A good test case lets someone else repeat your test and get the same result. That needs a known starting point, exact steps and a clear expected result. Use it for flows that must not break: sign-up, purchase, restore, anything on your regression list.
Template (copy and paste)
ID: TC-<number>
Title: <what is checked, in one line>
Area / flow: <e.g. sign-up>
Priority: <high / medium / low>
Preconditions: <app version, account state, device state, data needed>
Test data: <exact values to enter>
Steps:
1. <action>
2. <action>
3. <action>
Expected result:
- <observable outcome, one line each>
Actual result: <fill when run>
Status: <pass / fail / blocked>
Device / OS / build: <fill when run>
Notes / bug link: <optional>
Three examples (illustrative, app-agnostic)
Example 1: sign-up with a valid email
ID: TC-001 Title: New user can sign up with email and password
Area: sign-up Priority: high
Preconditions: fresh install, no account for test@example.com, network on
Test data: email test@example.com, password Tr1al-Pass!
Steps:
1. Open the app and tap "Create account".
2. Enter the email and password.
3. Tap "Continue".
Expected result:
- The home screen opens.
- The email appears in Settings > Account.
Example 2: invalid input is rejected clearly
ID: TC-002 Title: Sign-up rejects an invalid email
Area: sign-up Priority: medium
Preconditions: fresh install, network on
Test data: email "test@", password Tr1al-Pass!
Steps:
1. Open "Create account".
2. Enter the email and password.
3. Tap "Continue".
Expected result:
- No account is created.
- A message next to the email field says what is wrong.
- The entered password is kept.
Example 3: data survives a restart
ID: TC-003 Title: A saved item is still there after force-closing the app
Area: data Priority: high
Preconditions: logged in, list is empty
Test data: item name "Test item 1"
Steps:
1. Add the item.
2. Force-close the app.
3. Reopen the app.
Expected result:
- "Test item 1" is listed once.
How to adapt it
- Cut fields you never use. Minimum useful set: title, preconditions, steps, expected result.
- One test case, one purpose. If a title needs "and", split it.
- Write expected results you can see. "Works correctly" can't fail; "the list shows one item" can.
- Name the data. Say which account, which values; "a valid email" leaves room for doubt.
- Link bugs both ways. When a case fails, file it with the bug report template and note the link in the case.
Related
- Hub: Mobile app testing checklist hub
- Test report template for beta tests
- Regression test checklist template
Start free to have other developers run your flows and report what they find.