Should You Screenshot Every QA Test Step?

A QA record has two readers: the reviewer who signs off today and the person who investigates a regression months later. Both need to see what was tested, with what data, and what happened. Neither needs a screenshot of every click.

This post covers how to structure a manual test record and where screenshots add evidence, with the Temposhot workflow on a Mac.

Define one test objective

Each test case should verify one behavior. "User can reset a password with a valid email link" is one objective. "Account settings work" is a test plan, not a test case.

Write the objective as a sentence that can be true or false. The final screenshot will show which.

Record prerequisites and test data

List what must exist before step one, so anyone can repeat the test:

Item	Example
Test case ID	TC-142
Build or version	The build number under test
Environment	Staging URL, macOS version, browser and version
Account	Role and test account name, never a real customer
Test data	The order, file or record the test uses
Preconditions	Feature flag on, cart empty, user signed out

Use synthetic data. Test records are shared widely and kept for a long time.

Write steps with expected checkpoints

Each step gets an action and, where something observable should happen, an expected result.

1. Open the sign-in page. Expected: "Forgot password" link visible.
2. Select Forgot password and enter the test email. Expected: confirmation message.
3. Open the reset link from the test inbox. Expected: new password form.
4. Enter a valid new password and submit. Expected: signed in, dashboard shown.

Steps without an expected result are setup. Steps with one are checkpoints, and checkpoints are where screenshots belong.

Should you screenshot every QA test step?

No. Capture these moments:

• Starting state: proves the preconditions were met.
• Each checkpoint: shows the expected or unexpected result.
• Final result: shows the objective was met or not.
• Any failure: the screen at the moment it diverged, plus the step before it.

Screenshots of plain navigation clicks add pages without adding evidence. They make the record slower to review.

With Temposhot, you can capture only checkpoints. Open Action Capture (Command+3), select Configure, and set Mouse click capture to capture only clicks with a modifier key, or to never capture clicks. Then press Shift+Command+2 (the manual capture shortcut) at each checkpoint. Select Start Action Capture, choose Specific Window, run the test and select Finish capture. The Document opens with one page per checkpoint.

If you want every step for a failing test, set mouse clicks back to every click. Each accepted click saves the window just before the click. The Action Capture guide lists the capture modes.

Record actual results without rewriting history

The record must show what happened, not what should have happened. In the Document editor:

• Title each page with the step ID and action, such as "TC-142 step 4: Submit new password".
• In the Page description, write expected and actual results on separate lines.
• On a failed checkpoint, draw a Rectangle (R) around the wrong value and add a Text label (T) with "Fail".

Do not crop away context that a reviewer needs, such as the URL or build label. Use Framing only to remove unrelated windows. Blur personal data with Blur (B, Pro), and never edit a value to make a result look correct.

Use this QA execution record

• Test case ID, objective, build, environment, tester, date.
• Preconditions and test data.
• Steps with expected results.
• Screenshots of start, checkpoints, end and failures.
• Actual result per checkpoint.
• Status: Pass, Fail or Blocked.
• Linked bug report for each failure.

Export from the Document with Export PDF for an attachment to the test management tool, or PNG pages from More export formats for inline evidence. Name files with the case ID and build, such as TC-142_build-2026-08-27.pdf. The export guide lists formats. To compare two screenshots of the same screen across builds, the browser tool Compare Images highlights differences locally.

Review the evidence and sign off

A reviewer should confirm three things without running the test: the preconditions were met, each checkpoint shows the stated result, and the final status matches the screenshots. If a reviewer has to guess, the record needs another checkpoint.

Temposhot stores Documents locally and does not provide sign-off workflows. Attach the exported files to the test management tool or ticket where approvals are tracked.

Frequently Asked Questions

Are screenshots enough as test evidence?

For manual UI tests they are a core part. Add logs, console output or network data as text when the failure is not visible on screen. See screenshot evidence.

Should automated tests also produce screenshots?

Automated suites usually capture screenshots on failure. For comparing screenshots automatically across builds, see visual regression testing.

How do I report a failure found during QA?

Write a separate bug report linked to the test case. See how to document a bug with step-by-step screenshots.

Turn your clicks into a clear step-by-step guide

Action Capture records checkpoints on a shortcut or every click, depending on the run. Download Temposhot and attach your next test record as an ordered PDF.