Fix failed tests

Analyze test failures and get suggested code fixes for failing or intermittent app tests without leaving the IDE.

Test Companion connects to BrowserStack Test Reporting and Analytics and pulls failure data directly into your IDE. It fetches the root cause analysis for each failure and suggests a code fix. You can also start from the BrowserStack Automate dashboard if you spot a failure while reviewing builds on the web. If you do not have a Test Reporting subscription, paste failure details manually in the chat.

Fix from the Test Reporting panel

Use this method if you have a BrowserStack Test Reporting and Analytics subscription. The process starts in the Failure Analysis panel in the IDE.

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. In the Actions column, click the Fix:
   • Test Companion: Sends the failure context to the Test Companion chat.

   

5. Select Test Companion.

The system fetches the Root Cause Analysis (RCA) for the selected test. A loading indicator shows Fetching RCA while the analysis is retrieved.

When the RCA is ready, Test Companion switches to the chat panel and pre-populates the chat input with a structured prompt that includes the test name, suite path, error logs, failure type classification, root cause description, log evidence, evidence strength rating, impact assessment, and a suggested fix. Review the pre-populated prompt and press Enter to start the analysis.

Test Companion reads the RCA, identifies the likely cause, and suggests a code fix in the chat. Review the suggestion, apply it, and run the build again.

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. The method works for failures captured in Test Reporting and for failures you encountered locally.

1. Open the Test Companion panel in the IDE.
2. Switch to App mode and connect the app under test, if Test Companion needs to inspect it.

3. In the chat box, paste either of the following:

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

   

4. For more accuracy, type @ and attach the relevant test file, source file, or terminal output.
5. 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.

Review and apply fixes

Regardless of which method you use, Test Companion delivers the fix as a code suggestion in the chat. The suggestion includes:

• Root cause analysis: A brief explanation of why the test is failing.
• Suggested code change: The specific lines to modify, with before-and-after context.
• Confidence notes: If the fix involves assumptions (for example, an inferred accessibility ID change or a guessed timing threshold), Test Companion flags them.

After you apply the fix, run your test suite again to confirm the issue is resolved.

Example prompts

With error context:

Fix this test failure:
NoSuchElementException: Unable to locate element with accessibility id "login_button"
The test file is @tests/app/login_test.py
Device: Pixel 8, Android 14

Describing the failure:

My iOS checkout test is failing on Apple Pay. The test taps the Apple Pay button,
but the system prompt for biometric auth never appears in the test session.
Update the test to handle the system prompt.

Broad failure analysis:

6 of my tests are failing after the latest build. They all fail with
"View not found in the hierarchy." What is likely wrong and how do I fix it?

• From a Test Reporting session URL or ID:

https://observability.browserstack.com/projects/<PROJECT>/builds/<BUILD>/sessions/<SESSION_ID>

Or paste the ID alone on its own line:

<SESSION_ID>

Common failure types

Following are some common failure types that Test Companion can help fix:

• Locator drift: An accessibility ID, resource ID, or test identifier changed after a rebuild. Test Companion compares the failing locator to the current UI hierarchy and updates it.
• Permission and system prompts: A native dialog (camera, location, notifications, biometric, App Tracking Transparency on iOS) blocks the test. Test Companion adds the missing handler or capability.
• Timing and animation issues: A test acts before an element is visible, before an animation completes, or before async data loads. Test Companion replaces fragile waits with explicit conditions.
• Platform divergence: A test passes on iOS but fails on Android, or vice versa. Test Companion identifies the platform-specific behavior and suggests a conditional path or two separate test methods.
• Flaky behavior: A test passes intermittently due to a race condition or device-state issue. Test Companion identifies the race and adds stabilization logic.
• Genuine app bugs: The app behavior is wrong. Test Companion confirms the bug and explains what is broken, rather than patching around it.

Example scenarios

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

App rebuild regenerates accessibility IDs

A rebuild assigned new accessibility IDs to widgets. 18 Appium tests now fail with “element not found” errors. Paste the error output and reference the test files with @. Test Companion maps each broken locator to the current widget in the UI hierarchy and generates a patch with the updated IDs.

Permission prompt breaks the test in CI

Your camera-scan test passes when the iOS permission was granted manually before the run, but fails in CI where the permission prompt appears for the first time. Test Companion detects the missing handler and adds either an autoAcceptAlerts capability or an explicit prompt-acceptance step.

Animation timing flakiness

A test passes 70% of the time on the slide-in tutorial. The other 30%, it fails because the tap fires before the animation finishes. Test Companion identifies the race condition, replaces the implicit wait with an explicit wait for the element’s animation state, and adds a fallback retry on the assertion.

Test passes on iOS, fails on Android

A signup test works on iPhone but fails on Pixel because the soft keyboard covers the Submit button. Test Companion adds a scroll-to-element step before the tap, applied only on the Android branch of the test.

Test fails only in CI, passes locally

Your purchase-flow test passes on your local emulator but times out in Automate dashboard. Test Companion identifies that the test relies on a local environment variable for the test 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 with a clear error when the variable is missing.

Best practices

Following are some best practices to get the most accurate and effective fixes from Test Companion:

• Provide full error output. The more context you give (stack trace, error message, device logs), the more accurate the diagnosis.
• Reference the test file with @. Including the failing test file gives Test Companion access to the actual code, not only the error message.
• Fix one issue at a time. If multiple tests are failing for different reasons, address them individually for cleaner, more targeted fixes.

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.