Fix failed tests

Analyze failed web tests and apply suggested code fixes for one test, a selection, or a whole build, without leaving the IDE.

Test Companion connects to BrowserStack Test Reporting and Analytics and pulls failure data into your IDE. The tool reads the root cause of each failure and suggests a code fix. You can fix one failing test, a selection of them, or every failure in a build. The Failure Analysis panel is the main entry point. You can also start from the BrowserStack Automate dashboard, or paste failure details into the chat when you do not have a Test Reporting subscription.

Fix tests from the Failure Analysis panel

The Failure Analysis panel lists every test in a build run. Set up the view once, then fix one test, a selection, or all the failures in the build. This flow requires a BrowserStack Test Reporting and Analytics subscription.

To get started, open the build you want to work on:

1. Click the Failure Analysis icon in the Test Companion panel.

   

2. From the project dropdown, select the project that contains your build.

   

3. From the Build dropdown, select the build run that contains your failures.
4. Click All, Web, or App to filter the list by platform.
5. Click Failed to show only the failed tests.

After the failed tests are listed, choose how many you want to fix.

Fix one test

1. In the test row you want to fix, under Actions, click Fix.

   

2. Select Test Companion.

A Fetching RCA indicator appears while Test Companion retrieves the root cause analysis. Test Companion then switches to the chat and pre-fills a prompt. The prompt includes the test name, suite path, error logs, failure type, root cause, evidence, and a suggested fix. Review the generated details, then press Enter.

Fix selected tests

1. Select the checkbox next to each test you want to fix. To select all of the listed tests, select the checkbox in the header row of the list table.

   

2. Click the Fix button that shows your count, for example, Fix 3 tests. The selected tests appear as chips in the chat. The prompt box pre-fills with each test’s failure details.

   

3. Optional: To drop a test from the batch, click the X on its chip.
4. Press Enter.

Fix all failed tests in the build

1. Without selecting any test, click Fix failures. Test Companion pre-fills a prompt that lists every failing test and groups the failures by shared root cause.

   

2. Review the prompt, then press Enter.
3. When Test Companion presents the consolidated fix plan, review and approve it. Test Companion then fixes each group, re-runs that group’s tests, and ends with one full test run.

How Test Companion fixes the tests

Test Companion turns your request into a single action plan. For an individual test, it analyzes the root cause and generates a fix. For a batch, the tool groups the tests by a shared root cause so that one fix covers every test that failed for the same reason. The tool flags product and environment bugs rather than patching them. Test Companion does not edit a test to mask a real defect.

As the plan runs, the panel shows each stage: loading the workflow, reading the failing test files, and diagnosing each root cause. Before modifying any files, Test Companion creates a checkpoint of your workspace. You can use Changes to review the edits or Restore to revert them.

Review and apply fixes

After the action plan completes, Test Companion posts a summary in the chat. The summary states the root cause for each test, for example, an automation bug, and the fix that was applied. The chat lists each changed file with a count of added and removed lines.

Review the changes, then choose one of the following actions:

• Click Keep to accept the changes.
• Click Undo to revert them.

Run the build again to confirm that the fixed tests pass.

Fix from the Automate dashboard

Use this method when you review build results in the Automate dashboard and want to fix a failure without switching context manually. This method also requires a BrowserStack Test Reporting and Analytics subscription.

1. Open the Automate dashboard in your browser.
2. Select the build that contains the failed test.
3. Click the Tests tab to view the test list.
4. Select the failed test. The test detail panel opens.
5. Click the AI Analysis tab.

The AI Analysis tab shows a root cause analysis. This analysis includes a failure summary, a failure type such as an automation bug or a product bug, and a detailed breakdown.

To fix the failure in your IDE, click Fix in VS Code. Test Companion opens with the failure context loaded. It reads the root cause analysis, locates the test file in your project, and suggests a code fix.

If the same root cause affects several tests, click Bulk Apply to similar failures. Test Companion applies the failure type classification across all matching tests. Then fix the shared root cause once in your test code.

Fix from the chat

Use this method to start failure analysis from the Test Companion chat box. The chat accepts several input types, alone or in combination. This method works for failures captured in Test Reporting and for failures you hit locally.

1. Open the Test Companion panel in the IDE.

2. In the chat box, paste any of the following:

   • A Test Reporting session URL or ID, to pull the full failure context, including the test name, error, stack trace, and metadata.
   • An error message or stack trace from your test output.
   • A description of the failure in plain language.

   

3. For more accuracy, type @ and attach the relevant test file, source file, or terminal output.
4. Press Enter.

Test Companion analyzes the failure context, identifies the likely cause, and suggests a code fix in the chat. When you provide a Test Reporting session URL or ID, Test Companion fetches the same structured failure data the panel flow uses.

Example prompts

The chat accepts several kinds of input. The following examples show common ways to start a fix.

• From a Test Reporting session URL or ID:

https://automation.browserstack.com/builds/<BUILD_ID>/sessions/<SESSION_ID>

Or paste the ID alone on its own line:

<SESSION_ID>

• With pasted error context:

Fix this test failure:
Error: expect(received).toBe(expected) // Object.is equality
Expected: 200
Received: 401
The test file is @tests/api/auth.spec.ts

• Describing the failure:

My login test is failing because the redirect URL changed from /home to /dashboard
after our last release. Update the test assertion.

Common failure types

Test Companion helps fix the following common failure types:

• Stale selectors: An element ID or class changed after a UI redesign. Test Companion updates the selector to match the new element.
• Timing issues: A test runs before an element is visible or clickable. Test Companion adds an explicit wait or adjusts the wait strategy.
• Flaky behavior: A test passes intermittently because of a race condition. Test Companion identifies the race and adds stabilization logic.
• Genuine application bugs: The application behavior is broken. Test Companion confirms the bug and explains what is wrong, rather than patching around it.

Example scenarios

These scenarios show how Test Companion handles real-world failure patterns.

UI redesign breaks selectors

Your navigation header was redesigned. Now 23 Selenium tests fail with element-not-found errors because the button IDs changed. Paste the error output and reference the test files with @. Test Companion maps each old selector to its new equivalent and generates a patch with all the updated selectors.

Intermittent flaky failure

A test passes 70% of the time. It fails the other 30% with an element-not-visible error. Test Companion finds a race condition where the test clicks a button before an API call completes. It replaces the fixed wait with an explicit wait for network idle and adds a retry on the assertion.

API contract change breaks assertions

The backend team split the full_name field into first_name and last_name. Three test files that assert full_name now fail. Reference the test files with @ and describe the API change. Test Companion updates every affected assertion across the three files and adjusts the test data fixtures.

Test fails only in CI, passes locally

Your checkout test passes locally. In CI, it times out. Test Companion finds that the test relies on a local environment variable for the API base URL that is not set in CI. It suggests adding the variable to the CI configuration and updating the test to fail fast when the variable is missing.

Best practices

Use these practices to get the most accurate fixes from Test Companion:

• Provide full error output: The more context you give, including the stack trace, error message, and logs, the more accurate the diagnosis.
• Prefer a Test Reporting session URL or ID over typed error text: A session link or ID gives Test Companion the full structured failure context in one paste. Typed or summarized errors often drop detail that affects the diagnosis.
• Reference the test file with @: The failing test file gives Test Companion the actual code, not only the error message.
• Let bulk fix group related failures: When many tests fail together, fix them as a batch. Test Companion clusters failures by shared root cause and fixes each cluster once.

Next steps

• Automate tests: If the failed test needs to be rewritten, regenerate the automation script.
• AI settings: Configure auto-approve to let Test Companion apply fixes automatically.