How to Write Test Cases
Learn what a test case is, what goes into one, and how to write clear, useful test cases — with a full worked example for a mobile banking sign-in screen.
Picture this: you’ve just joined a team building a banking app. Your lead says, “Can you write test cases for the new sign-in screen?” You nod confidently — and then quietly wonder what exactly that means.
By the end of this lesson, you’ll know. You’ll be able to take a requirement, turn it into a set of clear test cases, and write them so well that anyone on the team could pick them up and run them.
What is a test case?
A test caseTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → is a written set of instructions for checking one specific thing in an app. It says what you need before you start, exactly what to do, and what should happen.
Why bother writing them down instead of just “trying the app”?
- Repeatability — the same checks can be run on every new buildBuildA specific compiled version of the app or website that is ready to be installed or tested.Open in glossary →, by anyone.
- Clarity — developers and product owners can see exactly what was tested.
- Coverage — writing cases forces you to think about what could go wrong, not just the happy path.
- Evidence — when something breaks, you can show precisely which check failed and how.
The essentials
What goes into a test case
Every test case needs, at minimum:
- ID and a title that says what is being checked
- PreconditionsPreconditionSomething that must already be true before you can start a test.Open in glossary → — what must be true before you start
- Steps — numbered, specific actions
- Test dataTest dataThe input values, accounts and records you use while testing.Open in glossary → — the exact values you’ll use
- Expected resultExpected resultWhat should happen when you perform a test step, according to the requirements.Open in glossary → — what should happen, written so it can only pass or fail
- Priority — how important the check is (for a test case, this means how important it is to run, not the bug priority from Severity vs Priority)
When you run the test, you also record the actual resultActual resultWhat really happened when you performed the test.Open in glossary → and a status (Pass, Fail, Blocked).
A compact template
| Field | Example |
|---|---|
| ID | TC-001 |
| Title | Sign in with valid email and password |
| Preconditions | App installed; user has an active account |
| Steps | 1. Open the app 2. Enter email 3. Enter password 4. Tap Sign in |
| Test data | anna@test.com / Secret123! |
| Expected result | Home screen opens and shows “Hi, Anna” |
| Priority | High |
The process in one line
Read the requirementRequirementA statement of what the software must do or how well it must do it.Open in glossary → → list what could happen (good inputs, bad inputs, limits) → write precise steps → write a clear expected result → review.
Three example cases
Here are three cases for a mobile banking app’s Sign in screen (password must be at least 8 characters; the account locks after 5 failed attempts):
TC-001Sign in with valid email and passwordpositivehigh
Preconditions
- App is installed
- An active account exists for anna@test.com
Steps
- Open the app
- Enter the email in the Email field
- Enter the password in the Password field
- Tap 'Sign in'
Test data
email: anna@test.com / password: Secret123!
Expected result
The Home screen opens and shows the account overview with the greeting 'Hi, Anna'.
TC-002Error message is shown for a wrong passwordnegativehigh
Preconditions
- An active account exists for anna@test.com
Steps
- Open the app
- Enter the email
- Enter a wrong password
- Tap 'Sign in'
Test data
email: anna@test.com / password: WrongPass1
Expected result
The user stays on the Sign in screen and sees 'Incorrect email or password'.
TC-003Account locks after the 5th failed sign-in attemptedgehigh
Preconditions
- An active account exists for anna@test.com with 0 failed attempts
Steps
- Open the app
- Enter the email and a wrong password, tap 'Sign in'
- Repeat step 2 four more times (5 failed attempts in total)
Test data
email: anna@test.com / password: WrongPass1
Expected result
After the 5th attempt the app shows 'Your account is locked. Reset your password to continue.' Signing in with the correct password is still refused.
Tip: click a test case to expand it.
Switch to Detailed at the top of the page for the full walkthrough: test scenarios vs test cases, the step-by-step process, ten worked cases, good vs bad examples, and mobile-specific tips.
Anatomy of a test case
Different companies use different tools — a spreadsheet, JiraJiraA popular tool for tracking bugs, user stories and tasks.Open in glossary → with a test plugin, or a dedicated test management tool — but almost all test cases contain the same fields.
| Field | What it means | Example |
|---|---|---|
| ID | A unique reference so people can talk about the case | TC-LOGIN-004 |
| Title | A short summary of what is being checked. Start with the behavior, not “Test…” | Password shorter than 8 characters is rejected |
| PreconditionsPreconditionSomething that must already be true before you can start a test.Open in glossary → | Everything that must be true before step 1 | App installed; user is signed out; account exists |
| Steps | Numbered, specific actions, one action per step | 1. Open the app 2. Tap the Email field… |
| Test dataTest dataThe input values, accounts and records you use while testing.Open in glossary → | The exact values to use | Email: anna@test.com, Password: Abc1234 (7 chars) |
| Expected resultExpected resultWhat should happen when you perform a test step, according to the requirements.Open in glossary → | What should happen, stated clearly enough that the result is obviously Pass or Fail | Message “Password must be at least 8 characters” appears under the field |
| Priority | How important the case is to run (not the same as a bug’s priority) | High / Medium / Low |
| Type | What kind of check it is | PositivePositive testingTesting with valid input to confirm the software works as expected.Open in glossary →, negativeNegative testingTesting with invalid or unexpected input to check the software handles it gracefully.Open in glossary →, edgeEdge caseAn unusual situation at the extreme of what the software should handle.Open in glossary → |
| Actual resultActual resultWhat really happened when you performed the test.Open in glossary → | What really happened when you ran it (filled in during execution) | Message appeared as expected |
| Status | The outcome of the run | Pass / Fail / Blocked / Not run |
Test scenario vs test case
These two are easy to confuse.
- A test scenarioTest scenarioA high-level idea of what to test, such as 'User resets a forgotten password'.Open in glossary → is a high-level idea of what to test. It answers “what should we check?”
- A test caseTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → is the detailed instructions for one check. It answers “how exactly do we check it?”
One scenario usually turns into several test cases. (There’s a third artifact, the checklist, and Test Scenarios vs Test Cases vs Checklists explains when to use each.)
| Test scenario | Test cases it might produce |
|---|---|
| Check that a user can sign in | Valid email and password · Email with uppercase letters · Password exactly 8 characters |
| Check that invalid sign-ins are handled | Wrong password · Unregistered email · Empty fields · Invalid email format |
| Check the account lock rule | Lock on 5th failed attempt · No lock after 4 failed attempts |
A group of related test cases is called a test suiteTest suiteA group of related test cases that are run together.Open in glossary →. For example, all the cases above could live in a “Sign in” suite.
How to write test cases, step by step
- Read the requirement carefully. Read the requirementRequirementA statement of what the software must do or how well it must do it.Open in glossary →, user story or acceptance criteriaAcceptance criteriaConditions a user story must meet to be considered done and accepted.Open in glossary → at least twice. Underline every rule, number and message. Write down anything unclear and ask about it before writing cases — this is verificationVerificationChecking that we built the product right, according to its specification.Open in glossary → at its cheapest.
- Identify the scenarios. List the big things a user can do or experience on this screen: sign in successfully, fail to sign in, get locked out, reveal the password, reset a forgotten password.
- Think positive, negative and edge. For each scenario, ask three questions. What happens with valid input (positive testingPositive testingTesting with valid input to confirm the software works as expected.Open in glossary →)? What happens with invalid input (negative testingNegative testingTesting with invalid or unexpected input to check the software handles it gracefully.Open in glossary →)? What happens at the limits — exactly 8 characters, exactly 5 attempts (edge casesEdge caseAn unusual situation at the extreme of what the software should handle.Open in glossary → and boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary →, covered in depth in Boundary Value Analysis)?
- Write clear, specific steps. One action per step. Name the exact button or field. Assume the reader has never seen the app.
- Define the expected result. Say exactly what should be on the screen: which screen opens, which message appears (word for word if the requirement gives it), what is enabled or disabled. If you can’t write an expected result, the requirement probably needs clarifying.
- Review. Re-read each case as if you were someone else. Better still, ask a teammate to review. Check that every rule in the requirement is covered by at least one case (test coverageTest coverageHow much of the product, requirements or risks your tests actually check.Open in glossary →).
Worked example: a banking app sign-in screen
Let’s put it all together. Here is the requirement for the sign-in screen of a mobile banking app called PocketBank.
The test cases
TC-SIGNIN-001Sign in with valid email and passwordpositivehigh
Preconditions
- PocketBank is installed and the user is signed out
- An active account exists for anna@test.com
Steps
- Open PocketBank
- Tap the Email field and enter the email
- Tap the Password field and enter the password
- Tap 'Sign in'
Test data
email: anna@test.com / password: Secret123!
Expected result
The Home screen opens and shows the account overview with the greeting 'Hi, Anna'.
TC-SIGNIN-002Wrong password shows an error and keeps the user on Sign innegativehigh
Preconditions
- User is signed out
- An active account exists for anna@test.com with 0 failed attempts
Steps
- Open PocketBank
- Enter the email
- Enter the wrong password
- Tap 'Sign in'
Test data
email: anna@test.com / password: WrongPass1
Expected result
The message 'Incorrect email or password' appears. The user stays on the Sign in screen.
TC-SIGNIN-003Unregistered email shows the same generic errornegativemedium
Preconditions
- User is signed out
- No account exists for nobody@test.com
Steps
- Open PocketBank
- Enter the unregistered email
- Enter any valid-length password
- Tap 'Sign in'
Test data
email: nobody@test.com / password: Secret123!
Expected result
The message 'Incorrect email or password' appears. The app does not reveal whether the email is registered.
TC-SIGNIN-004Password with 7 characters is rejected before sign-inedgehigh
Preconditions
- User is signed out
Steps
- Open PocketBank
- Enter the email
- Enter a 7-character password
- Tap 'Sign in'
Test data
email: anna@test.com / password: Abc1234 (7 characters)
Expected result
The message 'Password must be at least 8 characters' appears under the Password field. No sign-in attempt is made and the failed-attempt counter does not increase.
TC-SIGNIN-005Password with exactly 8 characters is acceptededgehigh
Preconditions
- User is signed out
- An active account exists for ben@test.com whose password is exactly 8 characters
Steps
- Open PocketBank
- Enter the email
- Enter the 8-character password
- Tap 'Sign in'
Test data
email: ben@test.com / password: Abcd1234 (8 characters)
Expected result
No length message appears. The Home screen opens.
TC-SIGNIN-006Account locks on the 5th consecutive failed attemptedgehigh
Preconditions
- User is signed out
- An active account exists for anna@test.com with 0 failed attempts
Steps
- Open PocketBank
- Enter the email and the wrong password, then tap 'Sign in'
- Repeat step 2 until 5 failed attempts have been made
- Enter the correct password and tap 'Sign in'
Test data
email: anna@test.com / wrong: WrongPass1 / correct: Secret123!
Expected result
After the 5th failed attempt the message 'Your account is locked. Reset your password to continue.' appears. In step 4 the user still cannot sign in, even with the correct password.
TC-SIGNIN-007Account does not lock after 4 failed attempts followed by a correct oneedgemedium
Preconditions
- User is signed out
- An active account exists for anna@test.com with 0 failed attempts
Steps
- Open PocketBank
- Enter the email and the wrong password, then tap 'Sign in'
- Repeat step 2 until 4 failed attempts have been made
- Enter the correct password and tap 'Sign in'
Test data
email: anna@test.com / wrong: WrongPass1 / correct: Secret123!
Expected result
The Home screen opens. The account is not locked.
TC-SIGNIN-008Show password toggle reveals and hides the passwordpositivemedium
Preconditions
- User is on the Sign in screen
Steps
- Enter the password in the Password field
- Tap the eye icon
- Tap the eye icon again
Test data
password: Secret123!
Expected result
Before step 2 the password is masked (dots). After step 2 it shows as plain text 'Secret123!'. After step 3 it is masked again. The typed text is unchanged throughout.
TC-SIGNIN-009Forgot password link opens the Reset password screenpositivemedium
Preconditions
- User is on the Sign in screen
Steps
- Tap 'Forgot password?'
Expected result
The Reset password screen opens. Tapping the back button returns to the Sign in screen.
TC-SIGNIN-010Sign in button is disabled while a field is emptynegativelow
Preconditions
- User is on the Sign in screen with both fields empty
Steps
- Look at the 'Sign in' button
- Enter the email only
- Clear the email and enter the password only
Test data
email: anna@test.com / password: Secret123!
Expected result
The 'Sign in' button is disabled (greyed out and not tappable) in all three steps.
Tip: click a test case to expand it.
Good vs bad test cases
Most weak test cases fail in one of three ways.
Vague steps vs specific steps
Specific
- Open PocketBank.
- Enter
anna@test.comin the Email field. - Enter
Abc1234(7 characters) in the Password field. - Tap Sign in.
Vague
- Open the app.
- Log in with a short password.
- Check it.
“A short password” could mean 1 character or 7. “Check it” tells the reader nothing. Two testers would run this case two different ways.
Multiple checks in one case
One case, one purpose
TC-SIGNIN-008: Show password toggle reveals and hides the password.
TC-SIGNIN-009: Forgot password link opens the Reset password screen.
Everything at once
TC-01: Check the sign-in screen works, the eye icon works, forgot password works, and the account locks.
If the giant case fails, which part failed? You can’t mark it “half passed”, and the bug report becomes a guessing game.
Missing or fuzzy expected result
Clear expected result
The message “Password must be at least 8 characters” appears under the Password field. No sign-in attempt is made.
Fuzzy or missing
Error is shown. (Or nothing at all.)
“Error is shown” would pass even if the app displayed “Something went wrong” — which would actually be a bug. A good expected result leaves no room for argument.
Common mistakes
Tips for mobile-specific test cases
Mobile apps live in a messy world. A sign-in screen that works perfectly on a desk can break on a bus. Add cases (or at least checklist items) for these situations:
Rotation
- Enter the email and password, then rotate the phone to landscape. Is the typed text still there?
- Is the Sign in button still visible and tappable in landscape?
Keyboard
- Does the email field open the email keyboard (with
@and.)? - Does the keyboard cover the Sign in button on a small screen? Can the user scroll to it?
- Does the Next key move from Email to Password, and does Done or Go submit?
- Does the app accept the password from a password manager or autofill?
Interruptions
- Receive a phone call or notification mid-typing. When you return, is the screen the same?
- Send the app to the background for a few minutes and reopen it. Is the user still on Sign in, and is the password safely cleared if the team expects that?
- Lock and unlock the screen during sign-in.
Network
- Tap Sign in in airplane mode. Does a clear “No internet connection” message appear, instead of a spinner forever?
- Switch from Wi-Fi to mobile data while signing in.
- Try on a slow connection. Can the user tap Sign in twice and send two requests? (That’s a classic race conditionRace conditionA bug that depends on the timing or order of events, so it only happens sometimes.Open in glossary →.)
Before you submit a test case
Use this quick checklist every time you finish writing a case.
Before you submit a test case
0 of 10 checked
Check your understanding
Quick quiz
0/5 answered · 0 correct
1.Which of these is a test scenario rather than a test case?
2.The requirement says passwords must be at least 8 characters. Which pair of inputs best tests the boundary?
3.What is wrong with the expected result 'It works'?
4.Which field describes what must be true before you start the test?
5.You're writing mobile-specific cases for a sign-in screen. Which is the best example?
Key takeaways
- A test case is a precise, repeatable set of instructions for checking one thing.
- The core fields are ID, title, preconditions, steps, test data, expected result and priority; actual result and status are filled in when you run it.
- A test scenario says what to test; test cases say how.
- Cover positive, negative and edge cases — and test limits from both sides.
- Specific steps and a crystal-clear expected result are what separate useful cases from useless ones.
- For mobile apps, think about rotation, the keyboard, interruptions and network changes.
Next: run your cases. See how test cases are organized into runs, executed and tracked in Test Runs and Test Management Tools.
Finished this page?Nice work, this page is complete!
Mark it as done to track your progress. It's saved in this browser, no account needed.
Its review cards are now in Bites ⚡