Developer guide
As a Developer you deliver the tasks assigned to you, hand them to QA, and act on what QA sends back.
What you see
Section titled “What you see”Your workspace is the Developer Workspace at /app/developer. It shows only tasks assigned to you, in apps you have access to.
Summary cards
Section titled “Summary cards”| Card | Meaning |
|---|---|
| My Work | Your active tasks (anything not yet in Production or Deprecated). |
| Review Queue | New or triaged issue reports, plus tester suggestions. |
| QA Returns | Issue reports you’re working on, fixed, or waiting for retest. |
| Blocked Tasks | Your tasks with unresolved blockers. |
| Tab | Contents |
|---|---|
| My Work | Your active tasks with their workflow stage and the next actions available. |
| Review Queue | Tester suggestions and incoming issue reports (status New or Triaged), with filters. |
| QA Returns | Issue reports In Progress, Fixed or Needs Retest, with filters. |
| History | Closed and Won’t Fix issue reports, plus your personal analytics: throughput trend, status mix, risk areas, personal workload and actionable bottlenecks. |
Filters on the Review Queue and QA Returns tabs: search, app, status, module, submodule and severity.
A typical day
Section titled “A typical day”- My Work: pick up Planned work, move it along, send finished work to QA.
- Review Queue: triage new issue reports.
- QA Returns: fix returned issues, mark them Fixed, and send them for retest.
- Check notifications for QA failures and mentions.
Common tasks
Section titled “Common tasks”Move a task through delivery
Section titled “Move a task through delivery”On My Work, each task shows buttons for the moves you’re allowed to make:
| From | Button | To |
|---|---|---|
| Backlog | Commit to Plan | Planned |
| Planned | Start Work | In Progress |
| In Progress | Send to Review | In Review |
| In Review | Return to Build | In Progress |
| In Review | Send to QA | Staging |
| Staging | Resume Build | In Progress |
Send to QA puts the task into Staging, where it appears in the queue of every tester in its assigned groups and a pending QA run is created.
You can’t move tasks to Ready to Ship or Production. A passing QA result moves the task to Ready to Ship automatically, and only an admin can promote to Production.
When QA fails your task
Section titled “When QA fails your task”If a tester records a Failed QA run, the task moves back to In Progress automatically and you get a notification. Read the tester notes and reproduction steps (ask an admin if you need the full QA run and its evidence), fix the issue, then Send to Review and Send to QA again. The next QA run is marked as a retest.
A Blocked QA run leaves the task in Staging until the blocker is cleared.
Triage an issue report
Section titled “Triage an issue report”Issue reports move through their own status flow:
| Current status | Next |
|---|---|
| New | Triaged |
| Triaged | In Progress |
| In Progress | Fixed |
| Fixed | Needs Retest |
| Needs Retest | In Progress, or Closed |
- Open Review Queue and find the report.
- Select the report to open its details and read the issue title, severity, expected and actual result, steps to reproduce, device, OS version and screenshot.
- Change its status to the next step.
- Select Add Note to record internal notes for admins and other developers. Notes are not shown to testers.
Each status and note change is recorded in the audit log.
Escalate a tester suggestion
Section titled “Escalate a tester suggestion”When a tester passes a task and leaves a suggestion, it appears at the top of Review Queue.
- Select the suggestion card to open it.
- Under Admin Review, select Request Admin Review.
QA Sync creates a task request for admins to review. You can escalate each suggestion once; afterwards it shows as already submitted. See Task requests.
- Keep issue statuses current. Admins and testers rely on Needs Retest to know when to look again.
- Use notes for implementation detail, not for discussion. For discussion, comment on the task.
- If a task is blocked by another item, say so: ask an admin to record the dependency so release readiness reflects it.
What you can’t do, and who to ask
Section titled “What you can’t do, and who to ask”| You want to… | Ask |
|---|---|
| Reassign a task or an issue | An Admin. Developers don’t reassign work. |
| Create, edit or delete tasks | An Admin |
| Move a task to Ready to Ship or Production | Passing QA does the first; an Admin promotes to Production. |
| Approve your own task’s release | Not allowed unless an approval rule permits self-approval. |
| See a task in an app you don’t have | An Admin, to grant app access |