Debug

When a step fails, the results page carries everything needed to work out why: the error, the screenshots either side of the failure, the logs, and what else depends on the element. This is the order to work through it in.

Open the failing step

1. Go to Run Results and click the test plan.

2. Click the test case you want to investigate.

3. Select the failed step from the step list on the left.

The list is headed by the step count and the number of failed steps, and each step carries an icon showing whether it passed, failed, or was not executed. Drag the divider between the list and the details pane to resize either side.

The step header shows the step status, start time, duration, step number, and step action. Its icons open the Logs, Step Settings, and Metadata panels, plus Locators on a healed step. See Step details panels.

Note

The step that reports a failure is not always the step that caused it. See When the failure started at an earlier step.

Read the error and the verdict

A failed step shows 2 sections below the step header: ERROR and ANALYZER VERDICT.

ERROR shows the error code and the error message, with Read more for the full text. When the page has iframes or shadow DOM hosts that were not searched, the message says so. If the element sits inside one of them, add a step that switches into it before the failed step.

Testsigma analyzes the failure as soon as you open the step, and the ANALYZER VERDICT carries the result:

Part	What it shows
Category	The type of failure as a badge, such as Flow divergence
Summary	One line naming the failed step and the cause, then a short explanation
REASON	Why the step failed, compared against the passing baseline. Read more expands it
Recommendation	What to change, and how to confirm the fix
Evidence	What the screenshots show for this run and the baseline
Fix	A named fix with a one-line description. When Testsigma can make the change, it lists options and an Apply fix button

To fix the step from here, select a fix option and click Apply fix. For suggestions you can apply, follow-up questions, or a bug report, click Analyze with Agent at the bottom of the page. See Analyzer.

Steps after the failed step do not run when the step is set to stop the test case on failure. They show the not executed icon.

When the failure started at an earlier step

A step can fail because the run left the recorded path before it. An earlier step opened a different page from the one recorded, or did not finish loading it, so the element the failed step needs never appeared. The verdict category says which of these happened.

Category	What happened	Fix
Flow divergence	The run reached a different page from the one recorded, so the element the step targets is not on the current page	Re-record the steps from where the run left the recorded path, or add the missing navigation before the failed step
Prerequisite not completed	An earlier step did not finish as recorded, such as a page that was still loading, so the next step could not find its element	Select the fix option in the verdict, such as Add a wait for the page to settle, and click Apply fix

1. Select the failed step and read the ANALYZER VERDICT. The summary names what was on the page instead, such as a product page where a search page was expected. REASON explains how the run left the recorded path, and whether earlier failures caused it. The recommendation names the step to re-record from, or what to add before the failed step.

2. Select the steps before the failed step, and check their screenshots in THIS RUN to find where the run left the recorded path.

3. Fix the test case. For Flow divergence, re-record the steps from where the run diverged, or add the missing navigation step. For Prerequisite not completed, select the fix option and click Apply fix.

4. Rerun the test to confirm the fix.

Not every verdict has an Apply fix button. When the fix means re-recording steps, the verdict names and describes it, and you make the change in the test case.

Check the logs

1. Click the Logs icon in the step header. The Logs panel opens on the right.

2. Click Console or Network.

3. Select This step from the scope list to see only the logs captured during the step.

4. Click the download icon to save the logs.

The Network tab shows the number of failed requests, the time window the requests started in, and a table of requests with their status, method, URL, size, and time. The total request count sits below the table.

Some logs have no step markers. The log then shows every entry for the run, with the message Not scoped to this step: this log has no step markers, so the whole run is shown.

Network logs are captured only when they are switched on for the test machine, and they arrive once the upload from the test machine finishes. Until then the Network tab reads No network log was recorded for this run.

Check whether the step was healed

When auto-healing resolves a locator mid-run, the step’s status reads Healed and the step shows the auto-heal icon in the step list. A banner above the list reports how many steps were healed.

Select the healed step to see the Healed this step card, with the locator change and Approve as Primary. See Healer.

Compare against an earlier run

Comparing a failing step against a run that worked shows what changed. Two entry points:

• Compare Runs in the page header compares the whole test case across 2 runs, step by step
• Compare Steps in the THIS RUN section compares the current step alone, with the screenshot and element source modes

Comparison spans the steps either side of the failure as well. See Results.

Check what else the element affects

When an element causes a failure, check which other tests depend on it before you fix it.

1. Click Affected tests in the step header.

2. Review each tab in the Affected Instances panel: Test Cases, Step Groups, Test Suites, and Test Plans, each with a count.

Where nothing else uses the element, the panel reads There are no Test Cases associated with the element.

Tip

The same view is available from Elements, through View Affected Test Cases on the element.

Act on the failure

All from the results page:

• Apply fix in the ANALYZER VERDICT, where the verdict lists fix options. When the run left the recorded path, re-record the affected steps instead
• Analyze with Agent in the action bar returns the error type, the root cause, and suggestions you can apply as a step update
• Run using Copilot in the action bar reruns the test case interactively
• Update element corrects a locator yourself
• Relearn step re-captures the step

Where auto-healing fired, approve the new locator from the Healed this step card.

Common causes of failure

• The element or UI identifier changed in the application
• The application does not load
• The local internet connection fails
• The element is unchanged, but navigation to it changed
• Addon code does not perform as expected
• The application under test contains a defect
• The result is a false positive or false negative
• An API is down
• The element locator is incorrect