Core Concepts | QA.army | Documentation

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

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.

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.