Skip to main content
TesterArmy organizes testing around a small set of reusable objects.

​
Project

A project represents one web or mobile application. It owns the application’s tests, environments, test accounts, integrations, and run history. For web projects, the project URL is the default Production target. For mobile projects, runs use an uploaded application build.

​
Environment

An environment answers where should this run happen? Production, PR Preview, Staging, and QA can use the same tests with different URLs and credential overrides. Use a saved environment for a stable target. Use a one-off target URL for an individual preview deployment.

​
Test and step

A test describes one user flow. Each test contains ordered steps such as:
Steps can perform actions, verify results, log in, upload files, or capture screenshots. See Write Reliable Test Steps.

​
Group

A group is a reusable collection of tests. Groups are the unit used for pull request regression testing, CI webhooks, and scheduled monitoring. For example, a Critical flows group might contain login, checkout, and account-management tests. See Organize Tests into Groups.

​
Run

A run is one execution of one test against a specific target. A group run creates one run for each enabled test in the group. Run execution and test outcome are separate:
  • completed with PASSED means the test ran normally and found no issue.
  • completed with FAILED means the test ran normally and found a product, configuration, or step issue.
  • completed with BLOCKED means an environment or setup problem (environment down, missing credentials, missing seed data) stopped the test before it could produce a product verdict. This is not a product failure. Fix the environment, then retry.
  • failed means the worker could not complete normal test execution.
  • cancelled means execution was stopped or skipped.
See Understand Results for the evidence available after a run.

​
Trigger

A trigger decides when should a group or exploration run start? Supported paths include:
  • Manual dashboard or CLI runs.
  • Native GitHub pull request testing.
  • GitLab CI or another deployment pipeline calling TesterArmy.
  • Scheduled production monitoring.
See Automate Testing to choose the right trigger.

​
Saved tests and exploration

TesterArmy supports three complementary approaches: Most teams use saved tests for known critical flows and add the exploration agent for broader pull request coverage. Discovery runs hunt for bugs outside any pull request, and every finding lands in Issues.