Workspace and Environment

In BearQ, a workspace and an environment describe two different levels of your setup, and understanding the distinction helps you organize your testing without duplicating work. A workspace is where your application model, test cases, and settings live. An environment is a specific deployed instance of that application that your tests run against. You define your tests once in the workspace, then run them against any environment you have configured, because every environment represents the same application at a different deployment stage.

A workspace is your team's home base for a single application. It holds everything BearQ needs to test that application:

Because a workspace is scoped to one application, each application your team tests has its own workspace. Everything sits at this project level, so anything you create or configure in a workspace applies only to that application.

An environment is a specific deployed instance of that application. Common examples are development, integration, and production. Each environment has its own URL and its own login credentials, but all of them represent the same underlying application, so the same tests apply across every environment.

Within a single workspace, you can store several environment configurations side by side and set one as the default. When you start a run, you can use the default environment or override it to target a different environment for that run. BearQ stores each environment's credentials securely, so you can point the same test suite at development one day and production the next without editing your tests.

The separation lets you write your tests once and reuse them everywhere the application is deployed. A typical flow looks like this:

Because the tests, model, and settings stay in the workspace, adding a new environment does not require you to recreate anything. You only provide the new environment's URL and credentials.