How to Document QA Test Steps with Screenshots

This guide shows how to collect screenshot evidence for a QA test run. You will define the test objective, record the prerequisites and test data, write verifiable steps, capture evidence, assign a result, and complete the execution record.

TL;DR: A QA record connects each planned action to an expected result and supports the final pass, fail, or blocked status with evidence from that exact run.

Define one test objective

The test objective states the behavior under review and the condition for success. Keep one record focused on one outcome so a failure points to a clear area of the product.

For example, "Verify that a Free user can export an Action Capture document as PNG" is testable. "Test Action Capture exports" combines several formats, plan states, and failure paths that should be separate cases.

Assign a stable test case ID when the test will be repeated. The ID connects future runs, regressions, and defect reports without relying on a title that may be edited later.

Record prerequisites and test data

Prerequisites make the run repeatable. List the product version, operating system, plan or account state, permissions, feature flags, prepared document, and any data required before step one.

Use exact test data instead of a vague instruction to "enter valid information." If the value may expose a credential or customer record, create a safe fixture and note where the tester can obtain it.

A compact setup can look like this:

Environment: macOS 15.5, Shotomatic 1.8.2
Account state: Free
Permissions: Screen Recording allowed
Test data: Action Capture document with three pages
Starting screen: Document editor, first page selected

Write steps with expected checkpoints

Each step should pair one action with the result the tester must inspect. This prevents a long action list from postponing every assertion until the end.

Use direct instructions:

1. Open the Export menu. Expected: PNG and JPG are available.
2. Select PNG. Expected: the save dialog opens.
3. Choose the test folder and save. Expected: one PNG file is created for each page.
4. Open the exported files. Expected: pages are in document order and match the editor.

Avoid combining several interactions in one step. A failed combined step makes it unclear which action caused the result.

Capture evidence at useful checkpoints

Useful evidence proves a state that matters to the test decision. Capture the starting configuration, plan-dependent options, final output, and any unexpected result.

You do not need a screenshot for every click. Opening a menu may need evidence when the test checks available formats, while selecting an ordinary folder may not add anything.

Action Capture can collect a click-by-click sequence when the test itself follows a UI path. Review the pages afterward and keep only the states that support the test result. Free sessions support 5 saved steps and every document export format. Pro removes the step limit and adds Blur, Click Marker, and Step Numbers.

Record actual results without rewriting history

The actual result should describe what happened in this execution. Do not change the expected result to match a failure, and do not edit the planned steps midway without recording the deviation.

Use one of three clear outcomes:

• Pass: every required result matched.
• Fail: at least one required result did not match.
• Blocked: the test could not reach a decision because a prerequisite or separate defect prevented execution.

When the test fails, state the first mismatched checkpoint and link a separate bug report. The bug report can contain the minimized reproduction path, environment, frequency, and diagnostic evidence without overloading the reusable test case.

Use this QA execution record

The following structure keeps the reusable test definition separate from the result of one run:

Test case ID:
Objective:

Environment:
Prerequisites:
Test data:

Steps and expected results:
1. Action:
   Expected:
2. Action:
   Expected:

Execution date:
Tester:
Build tested:

Actual result:
Status: Pass / Fail / Blocked
Evidence:
Linked defect:
Notes or deviations:

This is a documentation structure you can copy into the QA system you already use. Shotomatic does not import it as a project template.

Review the evidence and sign off

The final review checks that the evidence belongs to the stated run. Confirm the build, account state, date, page order, and exported result before another person uses the record for release approval.

Remove duplicate screenshots and protect any private test data. Keep filenames or page titles tied to the test case ID when the files will be stored separately from the test management system. Before sharing the record, run the review and reader-walkthrough checks in the Screenshot Tutorial Checklist.

A QA record is complete when a reviewer can see what was tested, repeat the setup, compare expected and actual results, and understand the final status. Use Action Capture to collect a click-driven test sequence. For evidence that starts with an observed problem rather than a planned test, use How to Document a Bug with Step-by-Step Screenshots on Mac.