QA execution and evidence
QA in QA Sync happens on staging work. When a task reaches Staging, QA Sync opens a QA run for it; a tester takes the run, tests the build against the task’s expected result, and records the outcome with evidence.
The QA run lifecycle
Section titled “The QA run lifecycle”| QA status | Meaning | Set by |
|---|---|---|
| Pending | A run exists and is waiting for a tester. | QA Sync, when the task enters Staging. |
| In Testing | A tester has started the run. | Tester selects Start QA Run. |
| Passed | The build behaved as expected. | Tester. |
| Failed | The build did not behave as expected. | Tester. |
| Blocked | The tester couldn’t complete testing. | Tester. |
| Needs Retest | A previous failed or blocked run must be checked again. | QA Sync, when the task returns to Staging. |
Passed, Failed and Blocked are final: a finished run can’t be edited. Each new trip through Staging creates a new run, so a task’s full QA history is preserved.
Who can run QA
Section titled “Who can run QA”A tester can start and submit a run when the task is in Staging, is assigned to one of the tester’s groups, and is in an app the tester can access. Admins can also start and submit runs.
Once a tester starts a run it’s theirs: another tester trying to start the same task is told QA is already in progress.
Record a result
Section titled “Record a result”The result form has:
| Field | Notes |
|---|---|
| QA Status | Passed, Failed or Blocked. |
| Severity | Critical, High, Medium, Low, or none. Cleared automatically for a pass. |
| Bug Count | Defaults to 0 for a pass and 1 otherwise. |
| Video Links | One or more URLs, separated by commas or new lines. |
| Tester Notes | Required for a failure. |
| Reproduction Steps | Required for a failure. |
| Expected Result | Pre-filled from the task. |
| Actual Result | What happened. |
| Screenshots | Image files, up to 8 MB each. Larger files are skipped with a warning. |
Environment is taken from the task’s context.
What each result does
Section titled “What each result does”| Result | Task | Notifications |
|---|---|---|
| Passed | Moves to Ready to Ship; required approvals are created and readiness is calculated. | QA passed |
| Failed | Returns to In Progress for the developer. | QA failed |
| Blocked | Stays in Staging until the blocker is cleared. | Blocked |
QA results roll up: each submodule, module and app shows the most significant QA status among its tasks, so a single failure is visible at every level.
Retests
Section titled “Retests”When a developer fixes a failed task and sends it back to Staging, QA Sync marks the previous failed or blocked run Needs Retest and opens a new run. The new run records that it’s a retest and when the retest was completed. Retest cycles appear in tester and admin analytics.
Evidence
Section titled “Evidence”| Evidence | Where | Limits |
|---|---|---|
| Screenshots | QA runs | Images, 8 MB each, several per run |
| Video links | QA runs | Any number of URLs |
| Screenshot | Task requests | One image, 6 MB |
| Screen recording | Task requests | One video, 25 MB |
| Screenshot | Feedback submissions | One image |
All uploaded files are stored privately. The app shows them through short-lived signed links to members allowed to see the related record.
Review QA results (admins)
Section titled “Review QA results (admins)”The admin QA tab lists every QA run. Filter by App, Module, Submodule, Tester, QA status, Severity, Environment and Retest (retest required or not). Open a run to read the expected result, actual result, tester notes, reproduction steps and evidence.
Task details also show a task’s tester submissions and attachments.
QA analytics
Section titled “QA analytics”- Testers: the Health tab shows queue load, pass and fail rates, average bugs, retest cycles, severity mix, hotspot modules, QA throughput and queue bottlenecks.
- Admins: the Overview shows passed, failed, in-testing and needs-retest counts, QA throughput, average retest count and average bug count by app and module.