How QA.army Works

QA.army brings AI into the full QA workflow while keeping coverage readable and under your team’s control.

1. Define what matters

Start with the journeys whose failure would hurt customers or block a release. Describe each journey as plain-language actions and observable outcomes.

Open the sign-in page.
Sign in with the test account.
Verify the account dashboard is visible.

Save related journeys in a Test Group so your team can review coverage by product area.

2. Choose where to test

Add environments such as Production, Staging, and QA to the Project. The same saved Test can target different approved environments without duplicating its steps.

3. Run with clear permissions

Choose the Test and Environment, then request a Run through an available customer interface. Workspace permissions control who can manage Tests, Runs, and evidence.

4. Understand the outcome

Every completed Run should answer one question: did the product journey work?

• PASSED means every required assertion succeeded.
• FAILED means the journey ran and a product assertion failed.
• ERROR means QA.army could not reach a reliable product conclusion.
• CANCELLED means the Run stopped before completion.

When evidence is available, use screenshots, recordings, activity, and reproduction steps to understand what happened.

Keep control

Review generated coverage before saving it. Use dedicated test accounts, avoid real customer data, and enable only the permissions required by the journey.

Availability

Use the SaaS app, published CLI, local MCP, or Product API for authorized saved Web Test and Run operations. Review the actual result and available screenshots and recordings; missing evidence is not a passing result. Native Android, iOS, and Desktop execution and scheduled monitoring are not generally available. Dynamic pull-request testing is an assisted pilot and is not generally available.