> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.qa.army/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.qa.army/_mcp/server.

# Core Concepts

> Learn how QA.army's workspaces, projects, test groups, tests, runs, environments, triggers, and evidence fit together.

QA.army organizes your QA work into a simple hierarchy.

```text
User <-> Workspace -> Project -> Test Group -> Test -> Run
```

## Workspace

A Workspace is the home for one team's QA.army activity. It contains members, Projects, usage, billing, and access settings.

You can belong to more than one Workspace. Membership controls which tests, runs, and evidence you can access.

## Project

A Project represents one product surface, such as a website, Android app, iOS
app, or desktop application. Android and iOS are represented by the Mobile
Project type. It contains environments, Test Groups, Tests, test accounts,
files, integrations, and Run history.

Use separate Projects when products have different release cycles, access requirements, or target platforms.

## Environment

An Environment answers: **where should this Test run?** Common examples are Production, Staging, QA, and a pull-request preview.

The same saved Test can run against different configured environments without duplicating its steps.

## Test Group

A Test Group organizes related journeys such as Authentication, Checkout, Onboarding, Billing, or Account Management.

Keep each group focused on one product area so people can quickly understand its purpose and coverage.

## Test and step

A Test describes one customer journey as ordered actions and assertions.

```text
Open the sign-in page.
Sign in with the saved test account.
Open Billing from Settings.
Verify the current plan is visible.
Capture a screenshot.
```

Available step types include Act, Assert, Login, Files, Screenshot, JavaScript, and Microphone. Keep steps linear, concrete, and easy to review.

## Run

A Run is one requested execution of one saved Test in one Environment. It records the status, result, timing, and available evidence for that attempt.

| Result      | Meaning                                                |
| ----------- | ------------------------------------------------------ |
| `PASSED`    | Every required assertion succeeded.                    |
| `FAILED`    | The journey ran and a product assertion failed.        |
| `ERROR`     | QA.army could not determine a reliable product result. |
| `CANCELLED` | The Run was stopped before completion.                 |

An account, setup, or execution problem is `ERROR`, not `FAILED`.

## Evidence

Evidence explains what happened during a Run. Depending on availability, it can include step timing, assertions, screenshots, recordings, console messages, network activity, and reproduction steps.

Evidence is visible only to authorized Workspace members.

## Trigger

A Trigger answers: **why did this Run start?** Manual, scheduled, and
pull-request triggers are part of the product model. Authorized customers can
request explicit Web Runs through the CLI or API. Scheduled monitoring is
unavailable, and dynamic pull-request testing is an assisted pilot that is not
generally available.

## Core and dynamic coverage

| Coverage         | How it works                                | Best for                               |
| ---------------- | ------------------------------------------- | -------------------------------------- |
| Core Test Groups | Re-run saved, durable journeys              | Critical flows and regression coverage |
| Dynamic Tests    | Focus coverage on a specific product change | Gaps introduced by the current change  |

Core Test Groups are the foundation of saved coverage. Dynamic pull-request
testing is an assisted pilot and is not generally available.

## Customer interfaces

The SaaS app, `qa-army` CLI, Product API, QA.army MCP, and future chatbot are
presentations of the same Workspaces, Projects, Tests, Runs, permissions, and
results. The versioned CLI package and public API contract are available for
authorized operations. The SaaS app supports visual Web Test and Run workflows,
and the published local MCP package reuses CLI authorization. Hosted MCP, native Mobile and
Desktop execution, and chatbot access are not generally available.

The legacy `venkat` name remains only in compatibility identifiers. Use
`qa-army` as the primary CLI command.