Prerequisites
-> +> > Before you begin, ensure that: -> 1. At least one test plan has been executed. -> 2. The test plan contains failed test cases. - +> 1. At least one test plan or dry run has been executed. +> 2. The run contains a failed test step. --- ## **Steps to Analyze Step Failures** 1. From the left navigation bar, click **Run Results**. -  -2. Select the test plan that contains failed test steps. +2. Select the run that contains failed test steps. 3. Open the test case with failures and select the failed test step. -4. In the **Step Details** panel, click **Analyze with Agent**. This will open the **Analyzer Agent** overlay. -  + 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. Click **Analyze with Agent** in the action bar at the bottom of the page. +  -5. Wait for the **Analyzer Agent** to complete the analysis. +5. Review the analysis, which displays: + + - **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. -6. Review the analysis in **Analyzer Agent** overlay, which displays: -  - - **Error Type**: Displays the category of failure identified during test execution. - - **Root Cause**: Describes the underlying reason for the failure based on execution analysis. - - **Visual Evidence**: Displays screenshots captured during recording and execution to support failure analysis. - - **Suggested Fixes**: Displays recommended actions to resolve the failed test 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. From the **Analyzer Agent** overlay, select the fix you want to apply. -  +1. In the **Suggestions** list, select the suggestion you want to apply. + + [[info | **NOTE**:]] + | You can select only one suggestion at a time. 2. Click **Apply Fix**. -  +  -3. Wait for the **Analyzer Agent** to generate the required fix. + 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. Click **Add Step**, **Update Step**, or **Update Step Settings**, as suggested by the **Analyzer Agent**. -  +3. Compare the two versions of the step. -5. Verify that the changes are applied to the test step. -  +4. Click **Update Step** to apply the change. -6. Rerun the test plan to validate the fix. +5. Rerun the test to validate the fix. --- ## **Report a Bug Using Analyzer Agent** -1. From the **Analyzer Agent** overlay, click **Report Bug**. -  +1. In the **Analyzer with Atto** panel, click **Report Bug**. The **QA Agent** panel opens. -2. Select the bug tracking application from **QA Agent** overlay. -  +2. Select your bug tracking tool from the dropdown at the top right. +  -3. Review the prefilled bug details, such as **Team**, **Project**, and **Title**. -  - - > The fields displayed vary based on the selected bug tracking tool. - -4. Click **Report Bug**. -  +3. Do one of the following: + - To raise a new issue, open the **Create New** tab, review the prefilled details, and click **Report Bug**. + - To attach the failure to an issue that already exists, open the **Link To Issue** tab, search for the issue, and click **Link To Ticket**. [[info | **NOTE**:]] -| To link the failure to an existing issue, click **Link to Issue**, search for the issue in the selected bug tracking application, and then click **Link to Ticket**. +| The fields displayed vary based on the selected bug tracking tool. ---- \ No newline at end of file +**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". + +--- diff --git a/src/pages/docs/auto-healing/auto-healing-insights.md b/src/pages/docs/auto-healing/auto-healing-insights.md index 84f10ffe..91355acc 100644 --- a/src/pages/docs/auto-healing/auto-healing-insights.md +++ b/src/pages/docs/auto-healing/auto-healing-insights.md @@ -1,7 +1,7 @@ --- title: "Auto-Healing Insights" page_title: "Auto-Healing Insights" -metadesc: "Review Auto-Heal Insights in Testsigma to see which elements were healed, how locators were updated, and decide if the changes should be made permanent." +metadesc: "Review how auto-healing behaved during a run in Testsigma | See which locator failed, what replaced it, and decide whether to keep the change." noindex: false order: 4.918 page_id: "auto-healing-insights" @@ -10,32 +10,109 @@ contextual_links: - type: section name: "Contents" - type: link - name: "Steps to View Auto-Heal Insights" - url: "#steps-to-view-auto-heal-insights" + name: "Prerequisites" + url: "#prerequisites" +- type: link + name: "Identify Healed Steps in a Run" + url: "#identify-healed-steps-in-a-run" +- 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" +- type: link + name: "When a Heal Fails" + url: "#when-a-heal-fails" +- type: link + name: "Fix the Locator Yourself" + url: "#fix-the-locator-yourself" +--- + +--- + +Review how auto-healing behaved during a run to see which locator failed, what replaced it, and whether to keep the change. Insights open from the healed step on the results page. + +--- + +>Prerequisites
+> +> Before you begin, ensure that: +> 1. Auto-healing is enabled for the project. +> 2. A run has been completed in which at least one step was healed. + +--- + +## **Identify Healed Steps in a Run** + +1. Open the test case results for the run. + +2. Select the healed step. +  + +[[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. + --- +## **Review the Heal on the Analysis Tab** + +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." + +Choose one of the following: + +- 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. + +[[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. + +--- + +## **View Autoheal Details** + +Open the **Autoheal Details** panel to see exactly which locator changed. + +The panel shows: + +- 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. + +**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. + --- -Once you’ve executed your tests using Auto-Heal, you can review detailed insights to understand how the feature worked during execution. The Auto-Heal Insights section helps you identify which elements were healed, how their locators were updated, and whether any of those updates should be made permanent. +## **Read the Locator Trace** + +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. -This article discusses how to view and manage Auto-Heal insights after test execution. +Use the trace to understand why a particular locator was chosen, or why no replacement could be found. + +**Additional Information**: The locator trace is provided by the Auto Heal V2 architecture. --- -## **Steps to View Auto-Heal Insights** +## **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. -1. Click the test step where the element was auto-healed to view insights. +[[info | **NOTE**:]] +| This requires Analyzer V2. Without it, a failed heal reports that it did not succeed, but no explanation is generated. -2. Go to the **Step Result** and click **Auto-Heal Details**. This opens the **Auto-Heal Details** overlay. -  +--- -3. Review the **Auto-Heal Insights**. -  +## **Fix the Locator Yourself** -4. To update the element value permanently, click **Update**. -  +If you would rather not accept the healed locator, you have two alternatives: -5. On the **Update Element** dialog, click **Update** again to confirm. -  +- **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. +- **Relearn step** re-captures the step so a fresh locator is recorded. ---- \ No newline at end of file +--- diff --git a/src/pages/docs/reports/runs/drill-down-reports.md b/src/pages/docs/reports/runs/drill-down-reports.md index f8d89ac3..d2a2b69f 100644 --- a/src/pages/docs/reports/runs/drill-down-reports.md +++ b/src/pages/docs/reports/runs/drill-down-reports.md @@ -1,6 +1,6 @@ --- title: "Test Plan Run Results in Testsigma" -metadesc: "View and download reports from the Run Results page in Testsigma | This page provides detailed results at the test cases, suites, and machines levels." +metadesc: "View and download reports from the Run Results page in Testsigma | Drill into results at the test case, suite, and machine level, read step analysis, and compare runs." noindex: false order: 14.23 page_id: "Test Plan Run Results" @@ -17,12 +17,21 @@ contextual_links: - type: link name: "Steps to View Test Case Results" url: "#steps-to-view-test-case-results" +- type: link + name: "Step Details Tabs" + url: "#step-details-tabs" - type: link name: "Steps to View Test Machine Results" url: "#steps-to-view-test-machine-results" - type: link name: "Test Runs in Run Results" url: "#test-runs-in-run-results" +- type: link + name: "Compare Runs" + url: "#compare-runs" +- type: link + name: "Compare a Single Step" + url: "#compare-a-single-step" - type: link name: "Overview of Tests in Run Results" url: "#overview-of-tests-in-run-results" @@ -39,124 +48,204 @@ contextual_links: --- -In Testsigma, you can view and download reports from the Run Results page. This page provides results at the test cases, test suites, and test machine level and also helps you check test runs, view the run overview, and see the count of passed/failed tests along with the reasons for failure. This article provides an overview of the Run Results page in Testsigma. - +View and download reports from the **Run Results** page. The page presents results at the test case, test suite, and test machine level, and shows the count of passed and failed tests along with the reason for each failure. Drill into a single step to read its analysis, check its logs, and compare it against an earlier run. --- >Prerequisites
> -> Before you begin, ensure that you have referred to: -> 1. [Documentation on creating test plans](https://testsigma.com/docs/test-plans/overview/). +> Before you begin, ensure that: +> 1. You have referred to the [documentation on creating test plans](https://testsigma.com/docs/test-plans/overview/). +> 2. A test plan has completed at least one run. --- ## **Steps to View Test Suite Results** -1. From the left navigation bar, go to **Run Results** and click on the test plan for which you want to check the results. -  +1. From the left navigation bar, go to **Run Results** and click the test plan for which you want to check the results. + -2. By default, you’ll see the results at test suite level. -  +2. Results open at test suite level by default. +  -3. You can expand the test suite to check test case results inside the suite. -  +3. Expand a test suite to check the test case results inside it. -4. The symbols shown with the arrow in the image below indicate the number of test suites running in parallel and the number of test cases running in parallel within each test suite. -  ---- +4. The parallel indicators on each row show how many test suites run in parallel, and how many test cases run in parallel within each suite. + +--- ## **Steps to View Test Case Results** 1. On the **Run Results** page, select **Test Cases** from the dropdown menu. -  + 2. The page displays all test cases from all test suites. -  -3. You can hover over a failed test case to view a brief description of the reason for failure. -  + +3. Hover over a failed test case to view a brief description of the reason for failure. + 4. Click a test case to view its detailed results. -5. On the **Test Case Results** page, you can view all the test steps along with the **Element Information, Test Data, Settings, Metadata**, and **Step Details**. -  +5. On the **Test Case Results** page, the step list appears on the left, headed by the step count and the number of failed steps. Select a step to open its details on the right. Drag the divider between the two panes to resize either side. +  + + +6. Review the step header, which shows the step number, its duration, its status, and the result message. On a failed step, the header shows the error message with a **Read more** link. + +7. Click **Affected tests** to see what else depends on the element this step uses. The **Affected Instances** panel opens with counts across **Test Cases**, **Step Groups**, **Test Suites**, and **Test Plans**. + +8. Click **More details** to open **Test Case Overview**, which shows the step breakdown across **Passed**, **Failed**, **Not Executed**, and **Stopped**, along with the run message and **Machine Details**. + +--- + +## **Step Details Tabs** + +Each step presents its details across five tabs. + +| **Tab** | **What it contains** | +|---|---| +| **Analysis** | The step result summary, the **Root cause** block on a failed step, and the **Visual Evidence** section comparing the authoring screenshot against this run | +| **Locators** | The locators used for the step | +| **Logs** | Selenium, console, and network logs for the step or for the whole run | +| **Step Settings** | Maximum wait time, prerequisite, whether the step result is ignored in the test case result, and whether visual testing is enabled for the step | +| **Metadata** | Test data and its type, along with the step ID and action | -6. Click **More details** to access additional information. -  + + +Below the two panels, the **Analysis** tab lists the element, element name, run type, action, start time, duration, step level timeout, plan level timeout, error code, error message, test data type, and test data for each side of the comparison. The **Page source** section at the bottom holds the captured HTML for each side as a downloadable file. + +On a failed step, the tab opens with the error code for the failure, such as **#NO\_SUCH\_ELEMENT**. + +[[info | **NOTE**:]] +| For details on reading the logs and investigating a failure, refer to the [documentation on debugging test case failures](https://testsigma.com/docs/runs/debug-test-case-failures/). For a root cause explanation and suggested fixes, refer to the [documentation on the Analyzer Agent](https://testsigma.com/docs/ai-agents/analyzer/). --- ## **Steps to View Test Machine Results** 1. On the **Run Results** page, select **Test Machines** from the dropdown menu. -  + 2. The page displays all test machines included in the test plan. -  - - [[info | **NOTE**:]] - | To view the test cases part of the test machine, navigate to the **Test Suites** view and apply a **Test Machine** filter. This provides a view of all test cases in the selected test suite and test machine. + 3. Click a test machine to expand and view the test suites it contains. -  + + +[[info | **NOTE**:]] +| To view the test cases that are part of a test machine, go to the **Test Suites** view and apply a **Test Machine** filter. This shows all test cases in the selected test suite and test machine. --- ## **Test Runs in Run Results** 1. From the **Test Runs** panel, select a different run to view its corresponding test run results. -  + 2. Click **Rerun** in the top-right corner to rerun the test plan by selecting the appropriate rerun options. -  + [[info | **NOTE**:]] -| 1. Each run ID has a maximum rerun limit of 10. We recommend using reruns wisely. -|  +| 1. Each run ID has a maximum rerun limit of 10. We recommend using reruns wisely. | -| 2. Once you click **Rerun**, you'll see the following options. -| - **All Test Cases:** This will rerun all the test cases in the selected run. -| - **All Failed Test Cases:** This will rerun all the failed test cases in the selected run. -| - **Select Cases for Re-Run:** This will allow you to select the test cases you want to rerun. +| 2. After you click **Rerun**, the following options appear: +| - **All Test Cases**: Reruns all the test cases in the selected run. +| - **All Failed Test Cases**: Reruns all the failed test cases in the selected run. +| - **Select Cases for Re-Run**: Lets you select the test cases you want to rerun. | | 3. Click **Start execution** to rerun the test plan. +--- + +## **Compare Runs** + +Compare two runs of the same test case side by side. + +1. On the **Test Case Results** page, click **Compare Runs**. +  + +2. Select a run from the list at the top of either panel. +  +Each panel shows the run's duration, date, step count, and failed count, followed by every step with its own duration. + +Comparison also spans the steps on either side of the failure, because the step that reports an error is often not the step that caused it. + +[[info | **NOTE**:]] +| The run list includes **Authoring Run**, which holds the values captured when the test case was authored, along with each earlier run identified by its run ID. Every entry shows its run type and its status as **Passed**, **Failed**, or **Healed**, so you can pick the last run that behaved as expected without opening runs one by one. + +--- + +## **Compare a Single Step** + +Compare one step against the same step in another run. + +1. On the **Analysis** tab, in the **Visual Evidence** section, click **Compare Steps**. The step comparison overlay opens. The step under comparison appears in the breadcrumb. + +  + +2. From the **View** list, select a comparison mode. + +  -1. To compare the current rerun result with the previous result, click **Compare Run**. -  + | **Mode** | **What it shows** | + |---|---| + | **Compare with Baseline** | The baseline run and the current run side by side | + | **Overlay Wipe** | Both screenshots in one frame, with a divider to wipe between them | + | **Current Step Only** | The current run's screenshot on its own | + | **Element Source** | A diff of the captured page source across the two runs, alongside the locator value for each | -2. This opens the **Rerun** overlay, where you can view a detailed comparison at all levels. -  + In **Overlay Wipe**, the capture recorded at authoring time and the capture taken during execution load into a single frame separated by a vertical divider. Drag the handle on the divider to wipe between them. Stacking the two makes a shifted control, a modal that did not close, or a reflowed layout visible at once, rather than something to find by comparing two panels. + +  + +3. Click **Screens** to compare screenshots only, or **Screens + Details** to show the step details beneath each screenshot. + + **Screens + Details** lists the run type, start time, duration, step level timeout, plan level timeout, error code, error message, element name, and locator for each run. Where a value was not captured, the field shows a dash. + + [[info | **NOTE**:]] + | **Screens + Details** is disabled in **Overlay Wipe**, because that mode renders a single combined frame rather than two panels. + +4. To compare a different step, select a step from the **Change Step** list. + +  + + Each entry shows the step number, the step name, its duration, and its status, including **Not Executed** for steps the run never reached. + +5. Click the download icon to download the comparison artifacts. + +[[info | **NOTE**:]] +| The baseline panel defaults to **Authoring Time** and is marked **Recorded**. When a step targets no element, the panel reads "No recorded evidence captured for this step". --- ## **Overview of Tests in Run Results** 1. The **Run Overview** section of the **Run Results** page is dynamic and provides a summary of tests at all levels for the selected run. -  + -2. This section displays the **Last Run, Test Plan Settings**, and **Accessibility Test Overview**. -  +2. This section displays the **Last Run**, **Test Plan Settings**, and **Accessibility Test Overview**. + 3. Click **View Runs** to view all runs, **More Settings** to access additional settings, and **View Report** to check the **Accessibility Testing Report**. -  + --- ## **Exporting the Test Reports** -1. Click the **Export** icon and select the desired download format from the dropdown menu. -  +1. Click the **Export** icon and select the download format from the dropdown menu. + -2. For **PDF format**, the **Export PDF** dialog appears. Select the appropriate options and click **Export**. -  +2. For **PDF** format, the **Export PDF** dialog appears. Select the appropriate options and click **Export**. + +  -3. For **JUnit format**, the report is downloaded instantly as an **XML file**. +3. For **JUnit** format, the report is downloaded instantly as an XML file. -4. For **XLSX format**, a downloadable link of the report is sent to your email. +4. For **XLSX** format, a downloadable link of the report is sent to your email. --- diff --git a/src/pages/docs/runs/debug-test-case-failures.md b/src/pages/docs/runs/debug-test-case-failures.md index 7c8f7fde..c645bebb 100644 --- a/src/pages/docs/runs/debug-test-case-failures.md +++ b/src/pages/docs/runs/debug-test-case-failures.md @@ -1,87 +1,198 @@ --- -title: "Debug Test Case Failures " -metadesc: " How to debug a failed test case to identify the issue in Testsigma." +title: "Debug Test Case Failures" +metadesc: "How to debug a failed test case in Testsigma | Open the failing step, read its analysis, check its logs, and compare it against an earlier run." noindex: false order: 9.71 page_id: "debug-test-case-failures" warning: false +contextual_links: +- type: section + name: "Contents" +- type: link + name: "Prerequisites" + url: "#prerequisites" +- type: link + name: "Open the Failing Step" + url: "#open-the-failing-step" +- type: link + name: "Read the Analysis" + url: "#read-the-analysis" +- type: link + name: "Explain the Failure" + url: "#explain-the-failure" +- type: link + name: "Check the Logs" + url: "#check-the-logs" +- type: link + name: "Check Whether a Step Was Healed" + url: "#check-whether-a-step-was-healed" +- type: link + name: "Compare Against an Earlier Run" + url: "#compare-against-an-earlier-run" +- type: link + name: "Check What Else the Element Affects" + url: "#check-what-else-the-element-affects" +- type: link + name: "Act on the Failure" + url: "#act-on-the-failure" +- type: link + name: "Common Causes of Failure" + url: "#common-causes-of-failure" --- --- -Sometimes, your tests may fail for any one or more of the following reasons: - -* Elements / UI Identifiers fail due to change in application. - -* The application does not load. - -* Local internet connection fails. - -* Element hasn’t changed but navigation to the Element has changed. - -* Your add-on code is not performing as expected. - -* Actual bugs in Application under test. - -* False positives / false negatives. - -* API down. - -* Bad Element locator. - - -This is not an exhaustive list, but it contains the most common causes. Debugging these issues is a simple process of moving from discovery to finding the root cause. Let's see how. - - -### Step 1: Discovery - -View the test results to understand where the test case has failed. Testsigma highlights the step that failed and caused the execution to stop. - - -### Step 2: Identify proof at Point of Failure - -At the step that has failed, find visual proof. Here’s how: -1. Verify Screenshot. - -2. Verify Video at the specific time (if available). - -3. Verify the Logs (Selenium Logs, Network logs, console logs) at the specified time. The Network logs are available for web apps. The Network logs are also available for native apps when they are executed via Browserstack Test Lab. +Investigate a failed test case from the **Run Results** page. Open the failing step, read its analysis, check its logs, and compare it against an earlier run. Testsigma captures a screenshot, the element details, and the logs for the step. + +--- + +>Prerequisites
+> +> Before you begin, ensure that: +> 1. A test plan run or dry run has completed. +> 2. The run contains at least one failed step. + +--- + +## **Open the Failing Step** + +1. From the left navigation bar, go to **Run Results** and click the test plan for which you want to check the results. + +2. Click the test case you want to investigate. + +3. Select the failed step from the step list on the left. -4. Verify error message. +  + + The list is headed by the step count and the number of failed steps. Each step carries an icon showing whether it passed, failed, or was not executed. Drag the divider between the step list and the details pane to resize either side. + + The step header shows the step number, its duration, its status, and the error message. Click **Read more** to see the full message. + + The details pane on the right carries the **Analysis**, **Locators**, **Logs**, **Step Settings**, and **Metadata** tabs. + +[[info | **NOTE**:]] +| The step that reports a failure is not always the step that caused it. Check the steps immediately before it as well. + +--- + +## **Read the Analysis** + +The **Analysis** tab opens with the error code for the failure, such as **#NO\_SUCH\_ELEMENT**. Below it, the **Visual Evidence** section places the screenshot captured at authoring time next to the one captured in this run. + + + +Below the two panels, the tab lists the element, element name, run type, action, start time, duration, step level timeout, plan level timeout, error code, error message, test data type, and test data for each side. Use the icons on a screenshot to expand it or download it. + +At the bottom of the tab, the **Page source** section holds the captured HTML for each side. Click the file name to open it, or the download icon to save it. + +[[info | **NOTE**:]] +| The authoring panel is marked **Recorded**. When no screenshot exists for a side, the panel reads "No screenshot captured". When a step targets no element, it reads "This step targets no element, so nothing was captured when it was authored". + +**Additional Information**: For a root cause explanation and suggested fixes, click **Analyze with Agent** in the action bar at the bottom of the page. Refer to the [documentation on the Analyzer Agent](https://testsigma.com/docs/ai-agents/analyzer/). + +--- + +## **Explain the Failure** + +Testsigma can read the step's error, screenshot, page source, and heal attempts, and explain what broke. + +1. On the **Analysis** tab, find the **Root cause** card. + +2. Click **Explain this failure**. -This should give you a good idea of proof at the point of failure. +  - -### Step 3: Analyze proof + The explanation opens with a one-line summary of what failed, such as "Step failed: no Shop Back to School link on Google homepage", followed by the reasoning and a recommended change. -The proof that has been collected in step 2 now has to be analyzed to find the root cause of the issue. The 4 points mentioned in Step 2 should be enough to identify the exact root cause. +3. Click **Read less** to collapse the explanation, or **Read more** to expand it again. - -### Step 4: Deploy a solution +[[info | **NOTE**:]] +| The **Root cause** card requires Analyzer V2. Without it, the page works as described everywhere else, but the card does not appear and failure analysis is available through **Analyze with Agent** in the action bar instead. -* If the issue is with Elements, change the element or add it to the Auto Healing list. +--- + +## **Check the Logs** + +1. Open the **Logs** tab. + +2. Select **Selenium**, **Console**, or **Network**. + +3. Use the scope list to switch between **This step** and the whole run. + +4. Click **Jump to error** to move to the first error in the log. + +5. Click the download icon to save the log. + +[[info | **NOTE**:]] +| Some logs have no step markers. When that happens, the log shows every entry for the run and displays the message "Not scoped to this step: this log has no step markers, so the whole run is shown". + +**Additional Information**: Network logs are captured only when they are switched on for the test machine, and they arrive once the lab finishes uploading them. Until then, the **Network** tab reads "No network log was recorded for this run". + +--- + +## **Check Whether a Step Was Healed** + +When auto-healing resolves a locator mid-run, a banner above the step list reports how many steps were healed, and the **Analysis** tab shows a **Healed this step** card with **Approve as Primary** and **Ignore**. + +A healed step reports **Passed**, because the step completed. For the full workflow, refer to the [documentation on auto-healing insights](https://testsigma.com/docs/auto-healing/auto-healing-insights/). + +--- + +## **Compare Against an Earlier Run** + +Comparing a failing step against an earlier run shows what changed between them. There are two entry points: + +- Click **Compare Runs** in the page header to compare the whole test case across two runs, step by step. +- Click **Compare Steps** in the **Visual Evidence** section to compare the current step alone, using the screenshot and element source comparison modes. -* If the issue is with navigation, update the navigation +Comparison also spans the steps on either side of the failure, because the step that reports an error is often not the step that caused it. -* If the issue is with the network, rectify the points of network failure - - -### Step 5: Proactive Damage Control +For both workflows, refer to the [documentation on test plan run results](https://testsigma.com/docs/reports/runs/drill-down-reports/). -If an Element has failed, navigate to the Elements page +--- + +## **Check What Else the Element Affects** -* Click on the “View Affected Test Cases” button for the specific Element. +When an element causes a failure, check which other tests depend on it before you fix it. -* This should show you a list of test cases that are at risk of failure. +1. Click **Affected tests** in the step header. -* Make necessary amends. + The **Affected Instances** panel opens, showing the **Test Cases**, **Step Groups**, **Test Suites**, and **Test Plans** that use the same element, each with a count. +  +2. Review each tab to see what is at risk of the same failure. - + When no test uses the element, the panel reads "There are no Test Cases associated with the element". + +[[info | **NOTE**:]] +| You can also reach this from the left navigation bar by going to **Elements** and clicking **View Affected Test Cases** for the element. --- -##**Support** -If you’re unable to resolve the test failure, you can connect with our Support team on Discord or send us a mail at **[support@testsigma.com](mailto:support@testsigma.com)** describing the issue. +## **Act on the Failure** + +Resolve the failure without leaving the results page. ---- \ No newline at end of file +- Click **Analyze with Agent** in the action bar to get the error type, the root cause, and a set of suggestions you can apply as a step update. +- Click **Run using Copilot** in the action bar to rerun the test case interactively. +- Use **Update element** to correct a locator yourself. On the current run side of **Visual Evidence**, the **Element** field carries an edit icon for this. +- Use **Relearn step** to re-capture the step. +- Where auto-healing fired, approve or reject the healed element directly on the first screen. + +--- + +## **Common Causes of Failure** + +Test cases commonly fail for these reasons: + +- 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. +- Add-on 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. + +---