Guide
How to write a test case
How to write test cases with example: practical rules, sample login test case, Excel column format, and steps that import cleanly into the runner.
Updated 5 min read
Start from the user goal
Name the case after what you are proving: "Valid login redirects to dashboard" beats "Test login page". The title is what you scan when a run fails at 6pm. Compare this with test case vs test scenario so you know where each one fits.
Test case format in Excel
QA Workspace expects TC_ID, Step, and Expected_Result at minimum. Add Module, Title, Step_No, and Priority for a smoother list view.
- TC_ID: groups rows into one case
- Module: feature area (Auth, Checkout, Reports)
- Title: short scenario name
- Step_No: order within the case
- Step: action the tester performs
- Expected_Result: what should happen
- Priority: HIGH, MEDIUM, LOW
Required and optional columns for import
| Column | Required | Purpose |
|---|---|---|
| TC_ID | Yes | Groups multiple rows into one executable case |
| Step | Yes | Single user action for the tester |
| Expected_Result | Yes | Observable outcome to mark pass or fail |
| Module | Recommended | Groups cases in the list view |
| Title | Recommended | Human-readable case name in reports |
| Step_No | Recommended | Keeps step order stable on import |
| Priority | Optional | Sorts execution when time is limited |
Sample test case for login page
Below is a complete LOGIN-01 case you can paste into Excel or CSV and import. Each row shares the same TC_ID.
LOGIN-01 — Valid login redirects to dashboard
| TC_ID | Module | Title | Step_No | Step | Expected_Result | Priority |
|---|---|---|---|---|---|---|
| LOGIN-01 | Auth | Valid login redirects to dashboard | 1 | Open the login page at /login | Email and password fields and Sign in button are visible | HIGH |
| LOGIN-01 | Auth | Valid login redirects to dashboard | 2 | Enter valid email test.user@example.com and password Test1234! | Fields accept input with no validation errors | HIGH |
| LOGIN-01 | Auth | Valid login redirects to dashboard | 3 | Click Sign in | User lands on /dashboard with welcome message visible | HIGH |
Test case quality checklist
Run a new case past this list before you commit it. Most quality issues come from the same handful of mistakes.
Before you save a test case
- Title states the user outcome, not the page name
- Stable TC_ID follows the MODULE-NN convention
- One user action per step, no hidden sub-steps
- Expected result is observable — message, URL, count, or state
- Test data is included in the step that needs it
- Module and Priority are set so the runner can sort
Common mistakes
Vague expectations like "works correctly" force the tester to guess. Combined steps make it unclear which action failed. Duplicate IDs across unrelated cases merge them into one monster case on import.
Download the free template if you want a head start. It uses the exact headers the importer recognizes.
Step-by-step
- 1
Pick a stable ID
Use a short TC_ID like LOGIN-01. Every row with the same ID becomes one test case on import.
- 2
Write one action per step
Each Step cell should be a single user action. "Enter email, enter password, click Login" is three steps, not one.
- 3
Make expected results observable
Expected_Result should describe something you can see or measure: a message, a URL, a count, a disabled button.
- 4
Add module and priority
Module groups cases in the list. Priority helps you sort when time is short.
- 5
Import and run
Drop the .xlsx or .csv into QA Workspace, confirm column mapping, and execute in the side panel.