Core Concepts

View as Markdown

TesterArmy organizes testing around a small set of reusable objects.

Project -> Environment -> Test -> Group -> Run -> Trigger

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:

Log in with the saved admin account.
Open Billing from Settings.
Verify the current plan is shown as Pro.

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.
  • 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 two complementary approaches:

ApproachHow it worksBest for
Saved testsRuns the steps you define each timeCritical flows and repeatable regression coverage
Exploration agentCreates a plan from each GitHub pull requestFinding change-specific issues without authoring steps first

Most teams use saved tests for known critical flows and add the exploration agent for broader pull request coverage.