Test Results

Monitor a ContextQA test, inspect results and evidence, identify the mobile app build used by a run, and download a retained build for reproduction.

Quick answer

Use the execution screen for live step progress and the completed run result for durable evidence. The result contains status, configuration, steps, screenshots, video, console, network, trace, and recent-run context when those artifacts are enabled. For a mobile run, the header shows the saved app-build name and provides Download build while the artifact remains available.

What this page covers

Who is this for? QA engineers, developers, technical writers, and release owners who need to monitor a run or investigate its evidence.

ContextQA separates a test run into two views:

• The execution screen shows live progress while the browser is running.
• The run result screen preserves the outcome, configuration, logs, and visual evidence after the run finishes.

This guide follows one standalone web test from execution to its passed result. Controls and artifacts can vary by test type, permissions, workspace configuration, and whether recording was enabled.

Interactive demo: execution to evidence

Use this four-screen tour to follow a test from launch through live progress, completion, and retained visual evidence. The walkthrough is designed for a quick release-readiness review rather than a full product tour.

What to notice

• Run configuration establishes what was tested before execution starts.
• Live progress identifies the active step and current application state.
• The completed result and visual artifacts help another authorized reviewer understand the outcome without recreating the run.

---

Open the execution screen

1. Select Test Cases in the left sidebar.
2. Open the test case you want to run.
3. Select Run.
4. Choose the required browser, environment, and execution settings.
5. Start the run.

ContextQA opens the execution screen and updates it as each prerequisite and test step runs.

Live ContextQA execution showing the step timeline and browser stream

Monitor a live execution

Run header

Use the header to confirm that you are watching the intended run:

Item	What it tells you
Status	Whether the run is running, passed, failed, or stopped
Duration	Elapsed run time, anchored to the server-recorded execution start
Executed count	Completed steps compared with total steps
Platform and browser	For example, Web and Chrome
Run type	For example, Manual
Version	The workspace or test version used for the run
Bug	Creates a defect from available run evidence; availability can depend on run state and integrations
Stop	Stops an active run

Steps tab

The Steps tab is the primary execution timeline. It can show:

• prerequisites separately from the test's own steps;
• the active, passed, or failed state of each step;
• the time spent on each step;
• locator search and element-found events;
• click or input actions;
• auto-heal activity; and
• AI verification output.

Expand a step when you need its detailed event sequence. A prerequisite contributes to the total executed-step count, even though the result page can summarize the test's own steps separately.

API Data for REST API steps

When the selected step is a REST API call, open its API Data view to inspect the captured response status, body, and headers available for that run. In the JSON response viewer, select a property or value to copy or choose its generated JSON path when the control is available. Use that path in a payload validation or to capture a value for a later request.

For example, selecting userId in the first object of an array can produce a path such as $[0].userId. Review the generated path against the actual response shape; for dynamic arrays or unsupported structures, enter and test the path manually in the API step's validation settings. Do not infer a path from a screenshot when the retained response body is unavailable.

Console tab

Select Console to inspect browser messages captured during execution. Early in a run, this tab can report that execution is still in progress and no logs are available yet.

Console errors do not automatically mean the test failed. A test can pass its configured assertions while the application logs unrelated 403, 500, warning, or diagnostic messages. Review console evidence independently when it matters to release quality.

Network tab

Select Network to inspect requests captured during execution. The live view includes a search field for URL, method, or status. It can be empty until the browser has made and uploaded requests.

Live browser area

The browser area identifies the platform, browser, and viewport, and displays the live session stream. Use it to confirm that the automation is on the expected page and is not blocked by a dialog, loading state, or authentication screen.

Do not treat the live stream as the durable evidence record. Open the completed result and review the generated artifacts before sharing or publishing them.

---

Actions available after completion

When execution finishes, the screen displays the final status and exposes the next actions.

Completed ContextQA execution showing pass status and evidence controls

Action	Use it to
View Run Results	Open the persistent result and all captured evidence
Re Run	Execute the same test again
Bug	Open the destination chooser and create a Jira or Azure DevOps defect when an integration is available
Debug log	Download the retained engine log when the run was produced by an on-premises deployment and the log is available
Screenshots / Video	Preview captured visual evidence
Copy run link	Copy a link for another authorized ContextQA user
Back To Test Case	Return to the test editor
Close	Leave the completed execution view

Use View Run Results for the complete investigation workflow.

---

Read the run result screen

ContextQA run results showing summary, network evidence, and a generated screenshot

Result header and metadata

The result header identifies the test name, final status, run ID, execution time, and duration. It can also break duration into application, tool, and AI time.

Metadata badges describe the execution context, including platform, browser, run type, environment, standalone or plan execution, viewport, and labels. Use these values before comparing two runs; unlike configurations can produce misleading comparisons.

For a mobile run, the header identifies the application build captured when that run was dispatched—not whichever build the device or test case uses today. If that retained artifact is still available, select the adjacent Download build action to retrieve the same package for reproduction. Older results created before build snapshots were recorded can fall back to the current device or test configuration. Treat the package as an internal artifact and distribute it only through an approved channel.

When Bug is available, select it to choose the configured defect tracker. ContextQA can send the failure to Jira or Azure DevOps and returns the destination reference so the team knows where the defect was created.

On an on-premises deployment, Debug log appears only when the result has a retained engine log. Download it for an authorized support investigation, then review the file for credentials, tokens, personal data, and internal URLs before sharing. The action is not expected on ContextQA Cloud results.

Analysis

The Analysis view summarizes status and counts such as total, passed, failed, and self-healed steps.

Treat percentages as telemetry that still needs a reasonableness check. During the documented pilot, a passed two-step run displayed a self-healed value of 150%. Values outside the expected range should be reported to the workspace administrator or ContextQA support and should not be copied into release metrics without validation.

Configuration

Open Configuration to reconstruct how the run was executed. Depending on the test, this view can include:

• environment, platform, browser, and viewport;
• AI metadata, smartness, and default AI action;
• wait and test-case timeouts;
• auto-wait, auto-heal, and recording flags; and
• API mocking state.

Record configuration with the outcome when diagnosing a failure or documenting a reproducible example.

Recent Runs

Open Recent Runs to review earlier executions of the same test. Each row can show run ID, outcome, execution type, timestamp, duration, platform, and standalone or plan context.

Select Compare Runs to choose a base run and a comparison run. The dialog includes passed, failed, and aborted status indicators and reports how many steps are being compared. Compare runs with similar configuration for the most useful result.

---

Inspect step and diagnostic evidence

Steps

The result separates prerequisites from the test's own steps. Open a step to review its description, status, duration, locator or action events, and AI verification response.

For a failed run, begin with the first failed step rather than the last recorded event. Then correlate that step with its screenshot, console messages, network calls, video time, and trace.

Console

The completed Console tab contains captured browser output such as errors, warnings, autocomplete messages, and application logs. Use it to answer questions such as:

• Did the page log a JavaScript or resource-loading error?
• Did an authorization request return 403?
• Did an application service return 500 even though the assertion passed?

The test result reflects configured test assertions; the console reflects application behavior. Review both.

Use the download action in the Console section to save the captured output as a text file for offline investigation or an approved defect report. Review the file for credentials, tokens, personal data, and customer information before sharing it outside the workspace.

Network

The completed Network tab provides search, filters, and a request table. Available controls can include:

• search by URL, method, or status;
• evidence-source filters such as mocked, recorded, live, fetch, or XHR;
• method filters such as GET, POST, PUT, and DELETE;
• method, URL, status, duration, and size columns; and
• pagination for longer request lists.

Use network evidence to confirm that an expected request occurred, inspect failing status codes, and identify slow calls. A successful UI assertion does not guarantee that every background request succeeded.

---

Review screenshots, video, and trace

Screenshots

Open Screenshots to view images generated during the run. Select a screenshot to inspect the captured page state at full size.

ContextQA-generated screenshot of the Test Cases list

Before publishing a screenshot:

1. Confirm it belongs to the correct run and step.
2. Check that the expected UI state is visible.
3. Crop only when the surrounding interface adds no useful context.
4. Redact credentials, tokens, personal data, internal URLs, customer data, and unrelated test names.
5. Add descriptive alternative text and a caption that explains what the reader should notice.

Video

Open Video to play the recorded browser session. The observed player provided a video count, step markers, playback speed, duration, and an expanded-player control.

Use video when motion or timing is important—for example, a loading transition, menu expansion, hover interaction, or failure that is unclear from a still image. Link readers to the authenticated run result instead of embedding a temporary signed media URL.

Trace

Open Trace for the interactive execution trace when it is available. Trace evidence is useful when screenshots and video do not explain a locator, timing, DOM, or request problem.

Artifact availability depends on the run configuration and retention policy for your workspace. Verify access before relying on a run link as long-term documentation evidence.

---

Documentation evidence workflow

Use a disposable, documentation-specific test so evidence collection does not change a valuable regression test.

1. Create or duplicate a suitable test and give it a clear DOC- prefix.
2. Remove destructive actions and use fictional, non-sensitive data.
3. Keep verifications within the visible viewport when the evidence needs to show several controls at once.
4. Run the test and wait for a final status.
5. Review Steps, Console, and Network, even when the run passes.
6. Open View Run Results and review Analysis, Configuration, and Recent Runs.
7. Review Screenshots, Video, and Trace.
8. Download only approved evidence, redact it if necessary, and add meaningful alt text.
9. Record the test ID and run ID in the documentation work item for auditability.
10. Delete the disposable test from the active list after the documentation is published. Use permanent deletion only when your retention policy requires it.

Troubleshooting

The run passed, but Console contains errors

A passing status means the configured test assertions passed. It does not certify that every browser resource or background request succeeded. Review whether the errors affect the user journey, then create a defect or a separate assertion when appropriate.

No network requests appear during execution

Wait for the browser to navigate and for evidence to upload. If the completed result remains empty, confirm that recording was enabled and rerun with the required execution configuration.

The screenshot or video control is missing

Confirm that recording was enabled for the run and that the artifact is still retained and accessible in your workspace. Permissions and test type can also affect availability.

Why is Debug log missing?

The action is limited to on-premises results that contain a retained engine log. It is not shown for ContextQA Cloud runs or when the log URL is absent.

A shared run link does not open for another person

Run results can require an authenticated ContextQA session and access to the same workspace. Share exported, reviewed evidence through your approved documentation channel when the reader should not have platform access.

Report retries and skips without hiding risk

Use one release readout that preserves every attempt:

Test	First result	Retry result	Final interpretation	Coverage status	Owner
Checkout	Failed: assertion	Passed	Intermittent until cause is proven	At risk	Payments QA
Export	Skipped: dependency	Not run	No verdict	Missing	Data team
Login	Passed	—	Passed	Covered	Identity QA

Rules for a defensible summary:

• a passing retry does not erase the original failure;
• a skipped or cancelled test has no verdict, not a pass;
• report attempts and unique tests separately;
• include denominators: passed / executed, skipped / selected, and unresolved / failed;
• link every conclusion to the original result IDs;
• name the owner and expiry for accepted risk or temporary quarantine.

Example: “96 of 100 selected tests executed; 92 passed on the first attempt, 2 passed only on retry, 2 remained failed, and 4 were skipped because the billing sandbox was unavailable.” This is more useful than “98% passed.”

Related pages

• Create test cases
• Running tests
• Video and screenshots
• Failure analysis
• Flaky test detection