Testing guide
Everything a tester needs to run the tester checklists, record results and report bugs — and everything the lead needs to coordinate the round. It is written for people who have not done structured software testing before, so it starts from the beginning.
| Round | Round 1 (R1), started 2 September 2026 |
| Scope | 39 suites, 556 steps |
| Testers | tester1 to tester4 |
| Checklists | Tester checklists — the steps themselves |
| Tracker | AfriAnnotateTestingTracker_v2.xlsx — the coordination workbook |
Boxes like this one are for the lead, not the testers. They hold the words to say, the decisions you own, and the traps to watch. Everything outside these boxes can be read aloud or shared as it stands.
What we are doing, in plain words​
AfriAnnotate is a tool for labelling data: text, images, audio, video and documents. Before other people rely on it, we want to know which parts work and which do not. Testing is simply using the tool on purpose, in a fixed order, and writing down what happened.
The people who built AfriAnnotate have written 556 small instructions, called steps. Each step says what to do and what should happen. A tester does the thing, looks at what actually happened, and records one of a handful of results: it worked, it did not work, it could not be tried, and so on. When something does not work, the tester writes a short bug report so a developer can find and fix it.
All of this is done once through as a round. At the end of the round we count the results and decide whether the tool is ready to release, and if it is not, which fixes come first. That decision is only as good as the records behind it, which is why this guide spends so much time on how to record things.
"You are not being tested. The software is. A step that fails is a good result: it found something before a real user did. The only bad outcomes are a step nobody ran, or a failure nobody wrote down."
How to read this guide​
Read in this order the first time; come back to individual pages later.
| Page | Who | What it covers |
|---|---|---|
| Terms you will hear | everyone | Step, suite, tier, the seven result statuses, severity vs priority, builds and environments |
| The team and accounts | everyone | Who owns which suites, which account to sign in with, how steps depend on each other |
| App checklist and workbook | everyone | The two places results live and which one wins |
| The workbook, tab by tab | everyone | What every column means and who fills it |
| Running a step | testers | The seven-step routine, and a quick table for deciding the status |
| Reporting a bug | testers | The defect fields, a weak report next to a strong one, rules that save time |
| Daily rhythm | testers and lead | A tester's day, the lead's day, and the judgement calls the lead will face |
| Rounds, criteria and sign-off | lead | Entry and exit criteria, retests, Round 2, and what is already known about each build |
| Kick-off meeting plan | lead | A 45-minute plan and a per-tester onboarding checklist |
| Questions testers ask | everyone | The situations that come up in the first week |
Before Round 1 starts, every tester should have read Terms, Running a step and Reporting a bug. Everything else can wait until it is needed.
Where things are​
- The steps — Tester checklists, one page per suite. The same list is in the app under account menu → My testing checklist, and in the PDF handbook for offline reading.
- Recording a tick — the in-app checklist (Pass / Fail / Skip on each step). See App checklist and workbook.
- Filing a bug — the in-app Fail button, or avatar menu → Report a test step (keyboard: Alt+Shift+R). See Reporting a bug and the testing programme page for what the form pre-fills.
- Coordination — the workbook, and the live suite-by-tester matrix under Platform → Testing (lead only).
- Test accounts —
accounts/testers.ymlin the repository. See The team and accounts.