Tasks that require QA (the default) can't reach Done without passing through a testing cycle.
The QA flow
- Ready for QA — development is complete and the task is queued for testing.
- Starting QA — a tester picks it up, recording the environment they're testing in.
- Testing — the tester works through the task's acceptance criteria and records what they tested.
- Changes Requested — if something's wrong, the tester records notes and (where relevant) defects found; the task returns to In Progress for the assignee to address.
- Passed — the task is cleared to move toward Ready for Release.
Starting QA
Starting a QA cycle requires the tasks.perform_qa permission (Testers by default) and records the environment being tested in, so it's clear later exactly what was verified and where.
Retesting
If changes are requested, fixing them and moving the task back to Ready for QA starts a new QA cycle — it doesn't reopen or overwrite the previous one.
QA history is permanent
Every QA cycle — passed or not — stays on the task's record once it's completed. A task that needed three attempts before passing keeps all three cycles visible, not just the final Passed result. This is deliberate: it's an honest record of how much rework a task actually took, useful for spotting patterns in Reporting without erasing history.