Viewing screenshots

QAlity captures screenshots during test runs for both Browser Execution and Cloud Execution. Screenshots are attached to step results and stored in Execution History, so you can see what the application looked like at each captured step.

In Run Configuration → Advanced Settings, Capture Screenshots controls when images are taken — for example All Steps or Failed Steps.

Run→Capture→Execution History→Open step

After a failure, see Re-running failed tests, PDF reports, and Dashboard overview.

How it works

During the run

Screenshots are captured as part of normal test execution.

Capture setting

Use Capture Screenshots in Advanced Settings to choose All Steps or Failed Steps.

Same for both modes

The setting applies to Browser Execution and Cloud Execution runs.

Where they live

Captured screenshots are attached to step results and stored in Execution History.

Browser Execution

Cloud Execution

Screenshots

Based on Capture Screenshots in Advanced Settings

Based on Capture Screenshots in Advanced Settings

Retention

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

Viewing screenshots

1

Open Execution History

Open the Execution History tab for the test case, suite, or plan.

2

Select a run

Select the run you want to inspect.

3

Open the step list

Open the step list for that run.

4

Click a step

Click any step to view its screenshot when one was captured for that step.

5

Move between steps

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 download action

Use the available download action for that screenshot.

2

Save locally

Save the image locally for investigation or sharing. Downloaded images are useful 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.

Previous step

Verify the previous step reached the expected destination.

Test data

Confirm required test data existed before navigation.

Known good run

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.

Overlays

Check if overlays, dialogs, or loaders blocked the element.

Position

Confirm the element appears in the expected position and state.

Layout shifts

Look for layout shifts that move controls out of view.

Loading

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.

Visible values

Compare visible text and values with the assertion expectation.

UI state

Check enabled or disabled controls, selected options, and status messages.

Timing

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.

Timing

Identify timing differences such as delayed content rendering.

Transient UI

Look for inconsistent data, pop-ups, or transient messages.

Pass vs fail

Confirm whether UI order or state changes between passes and failures.

Next fix

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 early

Begin at the first step that diverges from expected behavior, not only the final failed step.

Side by side

Compare failing and passing runs at the same step numbers.

Before edits

Validate UI state assumptions before changing locators or assertions.

Bug reports

Keep screenshots attached so engineering and QA review the same evidence.

After fixes

Re-run and confirm screenshot progression matches expected behavior on critical steps.

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