Skip to content

updated docs as per new results UI #1095

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
bharathk-testsigma merged 1 commit into from
Oct 7, 2026
Merged

updated docs as per new results UI #1095

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 29 additions & 24 deletions src/pages/docs/ai-agents/analyzer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,44 +43,47 @@ The Analyzer Agent analyzes a failed test step and returns the error type, the r

2. Select the run that contains failed test steps.

3. Open the test case with failures and select the failed test step.
3. Click the test case with failures.

The step header shows the error message. Click **Read more** to see the full message. The **Analysis** tab shows the error code, such as **#NO_SUCH_ELEMENT**, along with the **Visual Evidence** section.
4. On the **Test Case Results** page, select the failed step.

4. Click **Analyze with Agent** in the action bar at the bottom of the page.
![](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Analyze_with_Agent_Results.png)
The **ANALYZER VERDICT** section on the step already shows a short analysis of the failure. Use the Analyzer Agent for suggested fixes you can apply, follow-up questions, and bug reports. For details on the verdict, refer to the [documentation on debugging test case failures](https://testsigma.com/docs/runs/debug-test-case-failures/).

5. Review the analysis, which displays:
<!-- Image Placeholder: Analysis -->
- **Error Type**: The category of failure identified during execution, such as ELEMENT_NOT_FOUND.
- **Root Cause**: An explanation of why the step failed, based on the error message and the captured evidence.
- **Visual Evidence**: The screenshot captured at the time of execution. Click **Expand Images** to view it at full size, or the download icon to save it.
- **Suggestions**: A numbered list of ways to resolve the failure.
5. Click **Analyze with Agent** in the action bar at the bottom of the page.
![Analyze with Agent](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Analyze_with_Agent_Results_2.png)

The **Analyzer with Atto** panel opens and reads "Analyzing step failure..." while it runs.

6. Review the analysis.
![Anayzer Analysis](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Anayzer_Analysis.png)

| **Section** | **What it shows** |
|---|---|
| **Error Type** | The failure type identified during execution |
| **Root Cause** | Why the step failed |
| **Visual Evidence** | Screenshots **At the time of Recording** and **At the time of Execution**. Only the execution screenshot appears when no recording screenshot exists. |
| **Suggestions** | Numbered fixes you can apply to the step |

[[info | **NOTE**:]]
| To ask a follow-up question about the failure, enter it in **Debug with Atto** and click **Analyze**.

**Additional Information**: Responses are generated by Atto AI. Review the analysis before acting on it. Use the feedback icons or **Give Feedback** to tell us how useful it was.

---

## **Apply Fix Using Analyzer Agent**

1. In the **Suggestions** list, select the suggestion you want to apply.
1. In the **Suggestions** list, select one suggestion. **Apply Fix** stays disabled until you select one.

[[info | **NOTE**:]]
| You can select only one suggestion at a time.
2. Click **Apply Fix**. Atto returns an **Add/Update Step** card.

2. Click **Apply Fix**.
![](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Analyze_with_Agent_Results.png)
3. Click **Add/Update Step**.
![Add Step](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Apply_Fix_Update_Step.png)
In the step list, the updated step appears as an extra row below the original steps, marked with the Analyzer icon. The current result still shows the original step as failed, because the change applies from the next run.

Atto generates the fix and returns an **Update Test Step** card explaining what it found, followed by the current version of the step and the proposed version.
4. Re-run the test to confirm the fix.
- For a test plan run, click the run number in the breadcrumb to return to **Run Results**, then click **Rerun**.
- For a dry run, click **Re-Run** in the page header.

3. Compare the two versions of the step.

4. Click **Update Step** to apply the change.

5. Rerun the test to validate the fix.
The next run uses the updated step.

---

Expand All @@ -98,6 +101,8 @@ The Analyzer Agent analyzes a failed test step and returns the error type, the r
[[info | **NOTE**:]]
| The fields displayed vary based on the selected bug tracking tool.

**Additional Information**: If the tool returns no projects, check that the credentials configured for it have access to the projects you expect. For Jira, the panel reads "For given JIRA Credentials, the projects list is empty. Please make sure it has the right access to required projects on JIRA".
> <p class="additional-info">Additional Information</p>
>
> If the tool returns no projects, check that the credentials configured for it have access to the projects you expect. For Jira, the panel reads "For given JIRA Credentials, the projects list is empty. Please make sure it has the right access to required projects on JIRA".

---
90 changes: 44 additions & 46 deletions src/pages/docs/auto-healing/auto-healing-insights.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,17 +13,11 @@ contextual_links:
name: "Prerequisites"
url: "#prerequisites"
- type: link
name: "Identify Healed Steps in a Run"
url: "#identify-healed-steps-in-a-run"
name: "Review a Healed Step in Run Results"
url: "#review-a-healed-step-in-run-results"
- type: link
name: "Review the Heal on the Analysis Tab"
url: "#review-the-heal-on-the-analysis-tab"
- type: link
name: "View Autoheal Details"
url: "#view-autoheal-details"
- type: link
name: "Read the Locator Trace"
url: "#read-the-locator-trace"
name: "Locators Tried"
url: "#locators-tried"
- type: link
name: "When a Heal Fails"
url: "#when-a-heal-fails"
Expand All @@ -46,73 +40,77 @@ Review how auto-healing behaved during a run to see which locator failed, what r

---

## **Identify Healed Steps in a Run**
## **Review a Healed Step in Run Results**

1. Open the test case results for the run.
When a saved locator fails during execution, Testsigma searches for the element and continues the run with a new locator. The step's status reads **Healed**, and the new locator is kept as a pending heal until you approve it.

2. Select the healed step.
![](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Auto_Healing_Insights_New.png)
1. On the **Test Case Results** page, select a step that shows the auto-heal icon.
![Auto_Healing_Insights_New](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Auto_Healing_Insights_New.png)

[[info | **NOTE**:]]
| A healed step reports **Passed**, because the step completed. The run itself carries a **Healed** status in the run list, which distinguishes it from a run that passed without intervention.
2. Review the **Healed this step** card below the step header.
![Review Healed Step](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Healed_this_step.png)

---
The **Locator change** section shows two values:
- **Previous · recorded**: The saved locator that failed, shown struck through.
- **Current · applied**: The locator Testsigma used to continue the run.

## **Review the Heal on the Analysis Tab**
The count at the bottom of the card shows how many linked artifacts use this element.


The **Analysis** tab shows a **Healed this step** card explaining what happened: "Existing locator failed during execution, and we've auto-healed it using AI. The element locator was updated with a new XPath to ensure your test continues to run smoothly."
3. Click **Locators tried** to see how Testsigma found the element. For details, refer to [Locators Tried](#locators-tried).

Choose one of the following:
![](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Healed_Details_in_Results.png)
- Click **Approve as Primary** to make the healed locator the locator the test uses from now on.
- Click **Ignore** to leave the original locator in place. The heal still applied to this run only.
4. Click **Approve as Primary**. This will open **Autoheal Details** panel, showing the element name and the locator type used for the heal, such as **Autohealed using CSS Selector**. The failed locator appears struck through above the new one.

[[info | **NOTE**:]]
| In the **Visual Evidence** section, the current run panel carries a **Healed** badge, and the **Element** field has an edit icon for correcting the locator directly.
5. Click **Update**. The **Update Element** dialog opens.
![Update Element](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Update_Locator_with_Autoheal_Details.png)

---
6. Review the test cases listed under **Linked to Test Cases**. Click the open icon next to a test case to view it in a new tab.

## **View Autoheal Details**
7. Click **Update** to update the element in all linked test cases.
![Update](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Update_with_New_Locator_Value.png)
The **Healed this step** card now shows **Approved**.

Open the **Autoheal Details** panel to see exactly which locator changed.

The panel shows:
![](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Auto_HeaL_Accept_Reject.png)
- The element that was healed, named at the top.
- The prompt "Do you want to update the autohealed element in all the linked test cases?" with **Update** and **Ignore** buttons.
- The healing method and how long it took, such as "Autohealed using CSS Selector" and "32s 912ms".
- The locator that failed, struck through, followed by the locator that replaced it.
---

Click **Update** to apply the healed locator across every test case linked to the element, or **Ignore** to leave those test cases unchanged.
## **Locators Tried**

**Additional Information**: Use the feedback icons under "Is this autoheal helpful?" to tell us whether the heal was correct. The same feedback icons appear on the auto-healed banner above the step list.
![Locators Tried](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Locators_tried.png)

---
The **Locators tried** panel lists each stage of the search in the order it runs. The panel header shows the step number, the number of stages, and how the element was found.

## **Read the Locator Trace**
| **Stage** | **What it does** |
|---|---|
| **Primary** | Tries the primary locator saved on the element. Every step starts here. |
| **Last Working** | Tries the locator that found the element in the previous run. It is kept on the element as a pending heal and is not part of the backup pool. |
| **Backup Pool** | Makes a single pass over the live screen to see which stored backup locators still resolve. No action is performed on the page at this stage. |
| **Relearn Screen** | Reads the screen as the app rendered it and writes new locators for the element. The result is kept as a pending heal and is tried first on the next run. |

Every auto-heal event records a locator trace: the full sequence the engine worked through to arrive at a heal, and whether that heal succeeded or failed.
![Locators Tried Panel](https://s3.amazonaws.com/static-docs.testsigma.com/new/projects/applications/Locators_Tried_Panel.png)

Use the trace to understand why a particular locator was chosen, or why no replacement could be found.
Each stage shows its outcome, such as **Did not match**, **Skipped**, or **Located**. Each locator in a stage shows:
- Its result, such as **NOT FOUND**, **AGREED**, or **NEW**.
- Its source and type, such as **smart-recorder · csspath**.
- Its role, such as **PRIMARY**, **LAST WORKING**, **ANCHOR**, or **CANDIDATE**.
- Its quality, **Good** or **Fragile**.

**Additional Information**: The locator trace is provided by the Auto Heal V2 architecture.
> <p class="additional-info">Additional Information</p>
>
> A pending heal is not the element's primary locator. Testsigma tries it before searching again on later runs, but the primary locator changes only when you click **Approve as Primary**.

---

## **When a Heal Fails**

A heal attempt that fails gets the same root cause treatment as a failed step. Open the **Root cause** block on the **Analysis** tab and click **Explain this failure** to see why the engine could not resolve the element.

[[info | **NOTE**:]]
| This requires Analyzer V2. Without it, a failed heal reports that it did not succeed, but no explanation is generated.
When auto-healing cannot find the element, the step fails. Select the failed step and review the **ERROR** and **ANALYZER VERDICT** sections to see why the element could not be resolved. For details, refer to the [documentation on debugging test case failures](https://testsigma.com/docs/runs/debug-test-case-failures/).

---

## **Fix the Locator Yourself**

If you would rather not accept the healed locator, you have two alternatives:

- **Update element** corrects the locator directly. In the **Visual Evidence** section, the **Element** field on the current run side carries an edit icon for this.
- **Update element** corrects the locator directly.
- **Relearn step** re-captures the step so a fresh locator is recorded.

---
Loading
Loading