Builds and Environments

For testing and for reproducing defects, it is important to specify the context:

  • the build or version used for testing;
  • the server, browser, operating system, and other environment on which testing is performed.

Testing on different environments reveals the application's dependencies on installed components or on the specifics of supporting software.

Builds can be added manually, before testing begins. It is better, however, to integrate the build release system (a build server, for example Jenkins or TeamCity) with ALM. In that case, builds (their numbers and the paths to their location) are registered automatically when they are released. This is done with simple REST API commands, examples of which are given in the context help for the "Builds" module.

For each build you can see which requirements were implemented in it, which defects were found, and which test reports were filled in. A build can be discussed, for example on the subject of its readiness to be passed to the next quality control stage.

Environments can also be added manually, or by means of the REST API. For example, if your test environment is dynamic, that is, virtual machines or Docker containers are used, environments can be registered when such environments are created, before automated tests are started.

Search results