Testing programme (in-app reports)

A retirable module for structured testing rounds. While it is on, every signed-in user can report a test step from anywhere in the app; each report is filed as an issue in your testing repository on GitHub, with the same fields as the repo's issue form, so it is triaged and tracked like any other report. Testers never need a GitHub account.

For testers

Open the form from any page:

• avatar menu → Report a test step;
• the floating Report button (bottom-left; platform staff can hide it);
• keyboard: Alt+Shift+R.

The form is pre-filled with the page you are on (it becomes part of the title, e.g. Members: role dropdown shows Annotator), the page link, which client you use (web, desktop, Android, iPhone/iPad), the build, your browser and screen size. You add:

Field	What to put
What is this?	Something did not work or Suggestion or question
Step ID (optional)	the ID from your checklist, e.g. AN-NER-07
Title	a few words
Module, Where, How bad is it?	pre-guessed from the page; change if wrong
What I did / expected / happened	the clicks in order, the "You should see" text, what you saw instead
Screenshot	pick a file or paste an image (Ctrl/Cmd+V) into the form

My reports (top of the form) lists what you have sent with the issue number each one became.

Your checklist, tracked live

The explicit per-role TODO lists live in the app: avatar menu → My testing checklist (/testing-checklist). Pick your suite (the same suites as Tester checklists in the docs and the PDF handbook) and press Pass, Fail, or Skip on each step — every press is recorded the moment you make it, so the coordinator sees progress live; there is nothing to save or hand in. Fail opens the report form pre-filled with the step id, and the filed issue is linked back to the step. Press an active button again to undo. Your ticks belong to the current testing round — a new round starts everyone fresh while keeping the history.

How a round is run — statuses, defect fields, the coordination workbook, the lead's daily routine — is in the Testing guide.

For platform staff — Platform → Testing

• Checklist progress: a suite-by-tester matrix at the top of the page fills in live as testers tick steps (it refreshes every 30 seconds on its own), with failed counts in red and a "latest activity" feed underneath — each failed tick links to its GitHub issue. Progress is per round; changing the round label in Settings starts a fresh matrix.
• Open programme / Retire programme: one toggle. When retired, the menu entry, button and hotkey disappear and the submit endpoint refuses; existing reports stay listed here.
• Settings: round label (becomes the round:N label), GitHub repository (owner/repo), GitHub token (write-only; a fine-grained token with Issues: write and Contents: write on that repo — Contents lets the screenshot be committed into the repo and shown inline in the issue; without it the issue links to the app-hosted copy), extra labels, an optional note shown at the top of the form, and whether to show the floating button.
• The list shows every report with reporter, client/build, the GitHub issue number and whether it is Open or Closed there — closing the issue on GitHub is what closes it here (states are pulled every couple of minutes when the page or a tester's My reports is opened; Sync with GitHub pulls now). Filters: open / closed / send failed / saved. Send again re-forwards a report whose GitHub call failed (token missing, network). Click a title for the full detail and the screenshot.

Issues carry the labels source:manual (same as reports made through the repo's issue form; only the automated Playwright runs carry source:automation), module:*, surface:*, severity:* (or type:suggestion), round:N, status:needs-triage; the testing repo's triage workflow adds them to the project board.

Giving testers access to real projects

A tester only sees projects in organisations they are a member of. The simplest, safest way to let someone test end to end is to add them to a dedicated testing organisation (with seeded projects) at the role they should exercise — not to grant them platform-wide data access. Platform staff can additionally be granted Full data access (Platform → Users) to open any org's data, but prefer org membership for routine testing; see Security model.

Removing the module entirely

It is isolated on purpose: see label_studio/test_reports/README.md for the five-line delete procedure (one Django app, one frontend folder, a few imports).