Viewing screenshots

QAlity automatically captures and stores a screenshot for every test step in every run, whether the run is executed with Browser Execution or QAlity automation. These screenshots are saved in Execution History so you can inspect exactly what the application looked like at each step, with no extra setup.

How it works

• Screenshot capture is automatic for every step in a run.
• Capture happens as part of normal test execution.
• No configuration is required to enable screenshots.
• The behavior is consistent for Browser Execution runs and QAlity automation runs.
• Screenshots are attached to step results and stored in Execution History.

Run type	Screenshot behavior
Browser Execution	Captures screenshots for each executed step automatically
QAlity automation	Captures screenshots for each executed step automatically

note

Screenshot retention and availability depend on your workspace policies. Older execution records may be removed based on retention rules.

Viewing screenshots

1. Open Execution History.
2. Select the run you want to inspect.
3. Open the step list or timeline for that run.
4. Click any step to view its screenshot.
5. Move between steps to trace how the UI changed from one step to the next.

On failed runs, start with the failed step, then check the previous steps to understand what state led to the failure.

tip

Review screenshots in sequence instead of checking a single failed step in isolation. Context from earlier steps often explains the failure quickly.

Downloading screenshots

After opening a step screenshot in a run:

1. Use the available download action for that screenshot.
2. Save the image locally for investigation or sharing.

If your workspace supports sharing or exports, you can use downloaded images as evidence in bug reports and release validation.

Using screenshots to debug

Wrong page displayed

If a step screenshot shows an unexpected page, check navigation and prerequisite setup earlier in the run.

• Verify the previous step reached the expected destination.
• Confirm required test data existed before navigation.
• Compare with a known good run at the same step index.

Element not found

If a run reports that an element was not found, use the screenshot to confirm whether the element was actually visible.

• Check if overlays, dialogs, or loaders blocked the element.
• Confirm the element appears in the expected position and state.
• Look for layout shifts that move controls out of view.
• Compare nearby steps to determine whether the page was still loading.

Assertion failed

When an assertion fails, the screenshot helps validate what the test observed at that moment.

• Compare visible text and values with the assertion expectation.
• Check UI state indicators such as enabled or disabled controls, selected options, and status messages.
• Verify that the expected state was reached before the assertion step executed.

Flaky tests

For intermittent failures, compare screenshots for the same step across multiple runs.

• Identify timing differences such as delayed content rendering.
• Look for inconsistent data, pop-ups, or transient messages.
• Confirm whether UI order or state changes between passes and failures.
• Use this evidence to decide whether waits, retries, or data setup improvements are needed.

warning

Do not rely on screenshots alone for root-cause analysis. Always combine screenshot evidence with execution logs and error details.

Tips

• Start analysis from the first step that diverges from expected behavior, not only from the final failed step.
• Compare failing and passing runs side by side at the same step numbers.
• Use screenshots to validate assumptions about UI state before changing locators or assertions.
• Keep screenshots attached to bug reports so engineering and QA teams can review the same evidence.
• Re-run after fixes and confirm that screenshot progression matches expected behavior across critical steps.

Using screenshots together with logs and step results provides the fastest, most reliable debugging workflow.