Tester guide

As a Tester you verify work that has reached Staging, record what happened with enough detail for a developer to act on it, and flag scenarios that nobody has written a task for yet.

What you see

Your workspace is at /app/tester. The header welcomes you by name and shows your default device. It has a refresh control and a Device Defaults button.

Summary cards

Card	Meaning
Pending Tasks	Staging tasks in your queue that you haven’t finished.
Completed Tasks	Tasks where your QA run ended Passed, Failed or Blocked.
Issues Reported	Your QA runs that ended Failed or Blocked.
Suggestions	Improvement suggestions you sent.
Open Requests	Your task requests that are Draft, Pending or Reviewed.

Tabs

Tab	Contents
Queue	Tasks waiting for you, grouped by app. Search, and filter by app and module.
Health	Your QA analytics: Queue Load, Pass Rate %, Fail Rate %, Avg Bugs, Retest Cycles, Severity Mix, Hotspot Modules, QA Throughput and Queue Bottlenecks.
History	Your recent QA runs and submissions. Select one to see its details.
My Requests	Your task requests, their status and any admin note.

Which tasks reach your queue

A task appears in your Queue when all of these are true:

• it’s in Staging;
• it’s assigned to at least one of your tester groups;
• you have access to its app;
• you haven’t already finished a QA run on it.

If your queue is unexpectedly empty, ask an admin to check your app access and groups.

A typical day

1. Check Queue and notifications for new staging work and retests.
2. Run QA on each task and record the result.
3. If you find a scenario with no task, submit a task request.
4. Check My Requests for admin decisions.

Common tasks

Set your device defaults

Device defaults pre-fill device fields so you don’t type them every time.

1. Select Device Defaults in the header.
2. Set Platform (Web, iOS or Android), Environment, Device or Browser, Device Model and OS / Version.
3. Save.

Defaults are stored in this browser for your account. On a different computer or browser, set them again.

Run QA on a task

1. In Queue, find the task and select Start QA Run. QA Sync marks the run In Testing and assigns it to you, so another tester doesn’t start the same run.
2. Read the task details, build version and the Expected Result.
3. Test the feature by following the task’s instructions.
4. Fill in the result form:
   • QA Status: Passed, Failed or Blocked.
   • Severity: Critical, High, Medium, Low, or no severity.
   • Bug Count.
   • Video Links: separate multiple URLs with commas or new lines.
   • Tester Notes.
   • Reproduction Steps.
   • Actual Result.
   • Screenshots: images, up to 8 MB each.
5. Submit.

You submit	What happens next
Passed	The task moves to Ready to Ship and onto the release board.
Failed	The task returns to In Progress for the developer. Tester notes and reproduction steps are required.
Blocked	The task stays in Staging until the blocker is cleared.

Write results developers can act on

For a failure, write numbered reproduction steps from a clean start, state the actual result in one sentence, and attach a screenshot that shows it. Compare against the expected result, not your own expectation.

Your QA result also records the task’s QA Approved sign-off: Passed approves it, Failed rejects it with your notes as the reason. See Approvals and releases.

When a developer sends a failed task back to Staging, it returns to your queue and the new run is a retest.

Report an issue or suggest an improvement

Found a problem, or an idea, while testing? Send it to the developer without recording a QA result:

1. Select Report issue / Suggest on the task in Queue, or Report issue / Suggest improvement inside the QA run.
2. Choose Report an issue (summary, what went wrong, type, severity, actual result, steps, optional screenshot) or Suggest an improvement (describe it).
3. Select Preview, then Submit.

It lands in the developer’s Review Queue and the admin Feedback History, and counts in your Issues Reported or Suggestions card. The task stays in Staging: to send it back to development, submit a Failed QA run. From a QA run, Back to QA Run returns you to the run. See Feedback and suggestions.

Request missing coverage

When you find a scenario that no task covers:

1. In Queue, select Suggest New Task.
2. Fill in the four sections:
   • A. Context / Device Information: Platform, Environment, Device Name, Device Model, OS / Version (pre-filled from your device defaults).
   • B. Test Structure: Module, Submodule, Suggested Task Name. As you type, QA Sync shows similar existing tasks; check them first to avoid duplicates.
   • C. Feedback Details: Reason this task is missing, Severity, Feedback / Description, Expected Result, Actual Result, Steps to Reproduce.
   • D. Attachments: an optional screenshot (up to 6 MB) and screen recording (up to 25 MB).
3. Select Save Draft to keep it, or Preview to check it, then Submit for Admin Review.

See Task requests for what admins do next.

Track your requests

Open My Requests. Each request shows its status:

Status	Meaning
Draft	Saved by you, but not submitted yet.
Pending	Submitted and waiting for admin review.
Reviewed	Seen by admin, but not finalized yet.
Published	Converted into a new or existing task.
Rejected	Closed without becoming a task.

Select a request to see its full details and any Admin note.

Tips

• Start a QA run only when you’re ready to test; starting it claims the run.
• Use Blocked for “can’t test” (environment down, missing data), not for “it’s broken”. Broken is Failed.
• Keep device defaults current when you switch devices.

What you can’t do, and who to ask

You want to…	Ask
See tasks before they reach Staging	Not available; testers see Staging work only.
Change a task’s instructions or expected result	An Admin
Get access to another app or group	An Admin
Change a result after submitting it	Not available; finished QA runs can’t be edited. Ask an Admin if a result was recorded in error.
Edit a request after saving it as a draft	Not available yet; submit a new request instead.