Optimize non-SDK tests in Test Observability

Learn how you can maximize the features and benefits of Test Observability if you are not using the SDK.

You can use Test Observability even if you are not using the BrowserStack SDK. However, you need to make a few changes in your tests to optimize the benefits and features of Test Observability.

Improve the Test Observability experience with non-SDK tests

Although you can opt for the SDK to get the best experience in Test Observability, you can access Test Observability even if you don’t use the SDK.

You can improve the Test Observability experience with non-SDK tests by these steps:

• Marking the test status and reason
• Adding build name and test name

Some of the benefits of adding test status, reason, build name, and test name are listed in the following table:

Marking the test status using the JavascriptExecutor

You can mark the test status and failure reason in the session using the JavascriptExecutor. This is the recommended approach to optimize the non-SDK experience.

In case, you don’t send the test status in the session, you can use the REST API to mark the status and reason. If the test status is not marked in the session, Test Observability waits for five minutes for the status to be updated, after which the test status is marked as ‘Unknown’.

In case of failure, consider sending the stack trace in the REST API reason. You can also send customized error information, exception information, etc. in the REST API reason.

Refer to Automate JavascriptExecutors and App Automate JavascriptExecutors for the complete list.

Adding build and test name

For non-SDK tests, add a unique build name and test name for better reporting in Automate and App Automate.

A unique build name can be added for each builds by many techniques. You can use the buildIdentifier parameter for this purpose. You can also use other techniques like adding a date-time variable along with the build name.

You can also add build tags and project names to organize your builds.

Differences in the Test Observability experience if you don’t use the SDK

If you prefer to use the non-SDK version, the following are a few differences in the Test Observability experience:

• Features that work only with the SDK.
• Limited advanced project settings

Features that work only with the SDK

The following features in Test Observability work only with the SDK:

• Build Details: CI Job, Commit ID, Branch, Host name, Framework, Framework Version
• Build Insights - Failure by Folders
• Build Filters - Folder, Test Tags, Include all hooks, Host name
• Test Details - Test file path, Test file name, Test Code, Automatic Test name and status, Failure stack trace auto detection

Project settings applicable for non-SDK tests

The following table summarizes the project settings applicable for SDK and non-SDK tests.

Opt for BrowserStack SDK for the best experience in Test Observability

BrowserStack SDK is a powerful tool that you can use to set the different browser/device combinations and parallelization. You can get the complete features and benefits of Test Observability by integrating your test suite with BrowserStack SDK.

Integrate your test suite with Automate or App Automate using the framework-specific BrowserStack SDK.

Troubleshooting SDK

Follow these steps to troubleshoot if Test Observability is not working for you even after using the SDK:

1. Check if you have the minimum stable version of the framework-specific BrowserStack SDK from this table.
2. If you have the minimum version, and still your tests are not visible in Test Observability, set the testObservability capability as true in your browserstack.yml file.

If you can’t see your tests in Test Observability even after following the above steps, you can contact support for help.