> 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.

# QA.army SaaS App

> Use QA.army's visual interface according to your role, decision, and product target.

The QA.army SaaS app is the visual interface for organizing coverage and
reviewing the product state your account can access.

## Choose the view by decision

Executive titles do not change permissions. Workspace membership controls
access; personas only change which questions and details matter most.

| Reader | Start with                                    | Look for                                | Typical cadence                |
| ------ | --------------------------------------------- | --------------------------------------- | ------------------------------ |
| CEO    | Workspace and Project summary                 | Business-critical journey risk          | Launches and executive reviews |
| CMO    | Conversion-focused Test Groups                | Signup, checkout, and campaign blockers | Before and after campaigns     |
| CTO    | Tests, Runs, and technical evidence           | Reproducibility and release risk        | Every release and incident     |
| CPO    | Coverage and recent results                   | Missing journeys and product impact     | Planning and triage            |
| CIO    | Members, settings, accounts, and integrations | Access and privacy controls             | Onboarding and audit           |
| COO    | Multi-Project operational summary             | Critical failures and ownership         | Daily and during escalation    |
| CFO    | Usage and high-impact results                 | Consumption and material business risk  | Budget and renewal             |

## Target preferences

Use one Project for one independently testable product surface:

* **Web** for browser-based customer or administrative journeys.
* **Android** for Android app coverage represented through a Mobile Project.
* **iOS** for iPhone or iPad coverage represented through a Mobile Project.
* **Desktop** for native desktop journeys when Project setup becomes available.

Do not combine unrelated surfaces merely to simplify reporting. Use a
cross-application Test only when the customer journey genuinely crosses them.

## Coverage preferences

Favor a small set of durable, high-value Test Groups before broad coverage:

1. Authentication and account recovery.
2. Activation and onboarding.
3. The primary money-moving or value-producing journey.
4. Permissions and role-sensitive actions.
5. Cross-application handoffs that are difficult to verify manually.

Write steps in customer language and make every assertion observable. A Test
should explain what matters even to a teammate who did not author it.

## Display preferences

Use the visual interface for the evidence density required by the decision:

* Executive readers need status, scope, impact, and the next owner.
* Product and operations readers need the failed step and reproduction path.
* Engineering readers need the complete timeline and available technical
  evidence.
* Security readers need access, account, and data-handling context.

These are reading recommendations, not saved per-role dashboard modes.

## Availability

Sign in at [app.qa.army](https://app.qa.army/) to organize authorized Workspaces
and Projects, save Web Tests, start an explicit Web Run, and review its result
and available evidence. Screenshots and recordings belong to their Run; their
availability does not by itself establish a passing result.

Mobile build registration is available, but native Android and iOS execution
and Desktop setup and execution are not generally available. See
[Android and iOS Testing](/platforms/mobile) for supported build uploads.

## Next

Read [Core Concepts](/get-started/core-concepts) for the product model or
[Results and Evidence](/results-and-evidence) for result meanings.