Organize test runs in Automated tests

Learn how to organize your test runs into projects and builds to derive the maximum value out of the product.

Organizing structures

In Automated tests, the following are the organizing structures that are available:

• Project
• Build name (a.k.a. your CI job name e.g. Nightly Regression)
• Build number (a.k.a. the sequential job run identifier that is used in conjuction with job name to uniquely identify a run)

How to use Projects in Automated tests?

Automated tests uses a Project hierarchy to organize all test executions into projects and different runs within those projects. Here are some important points to keep in mind when using the Project hierarchy:

1. Project is used as a namespace, meaning that when you’re inside a project, you only see runs and analysis related to that project.
2. You should specify a static name for your project using the projectName key in the browserstack.yml config file of the SDK.
3. It is recommended to create unique projects for each of your pipelines or applications under test.

Here’s where the current selected project appears and how you can switch projects:

How to use build names within projects in Automated tests?

Every time you invoke a CI job, the build name should remain the same. We have a logic of automatically identifying different runs of the same job and hence you need not pass a different buildName every time.

To configure buildName in your browserstack.yml:

• Use a static name for buildName when running the same test suite across multiple browsers in your nightly regression job.

How to uniquely identify build runs within each static build name?

Automated tests automatically increments the build run number whenever it identifies a different run of the same build name. Hence you see the auto-incrementing numbers against your build name e.g. #14.