How to write QA test cases from a screen recording
A practical guide to turning a screen recording into a QA test case, with a template, worked example, common mistakes, and how to automate the result.
A screen recording is the most honest description of a flow you'll ever get. It shows the exact page, the exact button, the exact value typed and the exact result. A written test case is the opposite: a summary, often written from memory, that leaves out the detail that matters.
So if you need test cases, start from a video. This guide shows how to turn a recording into a good QA test case by hand, with a template you can copy, and then how to skip the manual part entirely.
What a good test case contains
Whatever tool you keep them in, a useful test case has the same parts:
| Field | What it holds |
|---|---|
| ID and title | A short name for the flow: "Guest checkout with express delivery" |
| Preconditions | What must be true first: signed out, cart empty, test account exists |
| Starting page | The exact URL the test begins on |
| Steps | One action per line, in order |
| Test data | Every value typed or chosen |
| Expected result | What proves the flow worked, written so anyone can check it |
The expected result is the field people skimp on most, and it's the one that makes a test case a test. "Checkout works" isn't checkable. "The page shows Order confirmed and an order number" is.
Step 1: Choose the right video
Not every recording makes a good test case. Look for videos that:
- Show one flow from start to finish. A product tour is several test cases, not one.
- Start somewhere identifiable, ideally with the browser's address bar visible.
- End on proof, such as a confirmation message, a new row in a table or an updated value.
- Use test data, so the test case can be shared safely.
Bug reports, release sign-off clips and onboarding walkthroughs are good sources. Sales demos usually aren't: they skip steps and wander.
Step 2: Watch once without writing
Watch the whole video before writing anything. You're looking for the outcome first, because everything else is the path to it. Write the expected result down before the steps. If you can't say what the video proves, the video isn't a test case yet.
Step 3: Write one action per step
Go through the video again and pause after every action. Write each step as a verb and a target, using the words on screen:
- Open the starting page.
- Click "Add to cart" on "Blue T-shirt".
- Click "Checkout".
- Type the test email into "Email".
- Choose "Express" in "Delivery".
- Click "Place order".
Use the label the user sees, in quotes. "Click the button at the bottom right" breaks the moment the layout changes; "Click Place order" doesn't.
Step 4: Pull out the test data
List every value typed or chosen as its own field, rather than burying it in the steps. It makes the test case easier to reuse with different data, and it makes it obvious which values are secrets. Passwords never belong in a test case document; refer to a named test account instead.
Step 5: Write the expected result precisely
Describe what's on screen at the end, not what happened in the database. "Order confirmed is shown with an order number" can be checked by anyone watching the screen. "The order is saved" can't.
A worked example
Title: Guest checkout with express delivery Preconditions: Signed out; cart empty Starting page: the shop's product page for Blue T-shirt
| # | Step | Data |
|---|---|---|
| 1 | Click "Add to cart" | |
| 2 | Click "Checkout" | |
| 3 | Type into "Email" | the test account's email |
| 4 | Choose in "Delivery" | Express |
| 5 | Type into "Delivery date" | a date next week |
| 6 | Click "Place order" |
Expected result: "Order confirmed" is shown with an order number.
Common mistakes
- Several flows in one test case. When it fails, you don't know which part broke. Split it.
- Positions instead of labels. "Third button" is fragile; "Save" isn't.
- Hard-coded dates. "Click the 14th" fails next month. Describe the date relative to today, like "a date next week".
- No expected result. Without one, a test case is a set of instructions, not a test.
Turning the test case into an automated test
A written test case still needs someone to run it before every release. That's where most manual suites stall: rewriting each case in a test framework takes an engineer, and the backlog never shrinks.
You can skip both the writing and the rewriting. ReplayQA reads the video directly: its AI writes the steps, values and expected result, then plays them back in a real browser to prove they work before saving the test. From then on you replay it with one click, with a screenshot of every step. See video to test cases for how it works, or the guide to turning a screen recording into a regression test for the reliability details.
Summary
- Start from a video of one flow that ends on proof.
- Write the expected result first, then one action per step using on-screen labels.
- Keep test data separate and never write down passwords.
- Automate the test case so it runs on every release, not just when someone has time.