The Test Coordinator — also known as the UAT Manager, QA Lead, Test Lead, Release Validation Specialist, or simply “the guy who won’t sign off” — is a tall, lanky individual, mostly bald, who arrives late in the project, inherits a spreadsheet of 238 issues, and proceeds to do what twenty development teams, three project managers, and an Agile Transformation Lead could not: make the software work.
The Test Coordinator’s job title says “testing.” The Test Coordinator’s actual job is integration, discovery, diplomacy, and the specific kind of engineering that happens when you are the first person to run Feature A and Feature B on the same machine and discover that they cannot coexist because they were built by two teams who never spoke, using two databases that share a table name but not a schema, following two specifications that contradict each other on page 14 — a page that nobody read because it was after the executive summary.
The Test Coordinator does not test the software. The Test Coordinator finishes building it.
The Arrival
The Test Coordinator arrives at the project after the development phase is “complete.” The word “complete” here means: each team has delivered their component, each component passes its own unit tests, each component has been demonstrated in a sprint review to approving nods, and none of the components have ever been run together.
The Test Coordinator opens the test environment. The Test Coordinator attempts to log in. The login page crashes. The Test Coordinator adds row 1 to the spreadsheet.
The Test Coordinator attempts the first end-to-end workflow — the one the customer will attempt on day one, the one described in the first paragraph of the requirements document, the one that every Sprint Planning session marked as “done” three months ago. The workflow fails at step 3 of 12. The Test Coordinator adds rows 2 through 17.
By the end of the first day, the spreadsheet has 74 items. The project manager, who told the steering committee the project was 95% complete, discovers that 95% of the components are complete but 0% of the system works. The Test Coordinator does not say “I told you so.” The Test Coordinator has never said “I told you so.” The Test Coordinator opens row 75.
The Spreadsheet
The Test Coordinator’s spreadsheet is the only accurate document in the project. It is not a test plan. It is a map of reality.
| Column | Purpose |
|---|---|
| ID | Sequential, never reused, never reordered |
| Description | What fails, in language a developer can reproduce |
| Severity | Critical / High / Medium / Low (the Test Coordinator’s severity ratings are never wrong) |
| Status | Open / In Progress / Fixed / Retest / Failed Retest / Won’t Fix |
| Assigned To | The developer who broke it (the Test Coordinator always knows who) |
| Found In | Build number (because Build 43 fixed item 89 but broke item 112) |
| Notes | The handwritten marginalia of a person who has seen everything |
The spreadsheet grows. Every day the Test Coordinator checks 12 items off the list. Every day the developers’ fixes introduce 4 new items. The net progress is 8 items per day. The spreadsheet started at 238. The release is in 30 days. The arithmetic works. The arithmetic always works, because the Test Coordinator does not estimate — the Test Coordinator counts.
The Product Manager has a roadmap. The Engineering Manager has a JIRA board. The project manager has a Gantt chart. The Test Coordinator has a spreadsheet with 238 rows, and the spreadsheet is the only document that accurately describes what the software does, what the software does not do, and what the software does that it shouldn’t.
The Hours
The Test Coordinator works twenty-hour days during the release cycle. This is not heroism. This is physics. The software has 238 defects. Each defect requires approximately 30 minutes to verify, document, assign, and retest. The developers fix defects between 10 AM and 6 PM. The Test Coordinator retests fixes between 6 PM and 2 AM, so that the developers arrive the next morning to a fresh list of items that failed retest and new items that their fixes broke.
The Test Coordinator’s schedule:
06:00 Wake. Coffee. Check overnight build status.
07:00 Arrive. Review developer fixes committed after midnight.
08:00 Begin retesting yesterday's "fixed" items.
12:00 Lunch at desk. Spreadsheet open. Testing continues.
14:00 New build deployed. Three previously fixed items are broken again.
15:00 Meeting with project manager. "How many blockers?" "Fourteen."
15:30 Continue testing. Find two new issues nobody has seen before.
18:00 Developers leave. Test Coordinator stays.
19:00 Regression testing the workflows that haven't been touched.
22:00 Find a data corruption issue that only manifests after 200 records.
23:00 Document it. Assign it. Add it to the spreadsheet.
01:00 Final retest of today's critical fixes. Three pass. One fails.
02:00 Go home. Set alarm for 06:00.
The Test Coordinator does this for three to six weeks. During this period, the Test Coordinator loses weight, gains coffee tolerance, and develops the particular thousand-yard stare of a person who has seen Build 47.3 break in a way that Build 47.2 did not because the fix for item 189 interacted with the fix for item 203 in a way that neither developer anticipated because neither developer knew the other’s code existed.
The Test Coordinator’s hair — what remains of it — did not leave voluntarily. It was worn away by the friction of hands running across the scalp in the specific gesture that means “they fixed the login but broke the payment flow again.”
The Knowledge
Here is the Test Coordinator’s secret, the thing that makes them unfireable, the reason that every Reorg restructures departments around them like water flowing around a stone:
The Test Coordinator is the only person in the company who knows how the software actually works.
Not how it was designed to work — the architect knows that. Not how it was specified to work — the Product Manager knows that. Not how each component works — the developers know that. The Test Coordinator knows how the software actually works — all of it, together, on a real machine, with real data, in the specific configuration that the customer will use.
The Test Coordinator knows that Feature A works unless Feature C is enabled. The Test Coordinator knows that the payment module rounds differently than the invoicing module. The Test Coordinator knows that the export function fails silently when the filename contains a colon — because the Test Coordinator tried it, because the Test Coordinator tries everything, because trying everything is not a methodology, it is a personality trait.
This knowledge exists nowhere else. It is not in the architecture documents, which describe the system as designed. It is not in the code, which describes each component in isolation. It is not in the test automation, which covers the happy paths. It is in the Test Coordinator’s spreadsheet, in the Test Coordinator’s head, and in the specific weariness of a person who has found 238 ways the software doesn’t work and fixed them one row at a time.
The Real Project Manager
The project manager manages the project: the schedule, the budget, the status reports, the steering committee. The project manager’s deliverable is a green slide.
The Test Coordinator manages the software: what works, what doesn’t, what broke today, what will break tomorrow if the fix for item 156 is deployed before the fix for item 161. The Test Coordinator’s deliverable is a system that actually functions.
The Project Manager (the official one) presents a Gantt chart. The Test Coordinator presents a defect curve. The Gantt chart shows the project on track. The defect curve shows 238 items, 14 blockers, and a trajectory that will converge on zero in exactly 28 days if — and only if — the fix rate stays at 12 per day and the introduction rate drops below 4.
The steering committee looks at the Gantt chart and the defect curve. The Gantt chart is comforting. The defect curve is terrifying. The steering committee believes the Gantt chart. The Test Coordinator’s defect curve is correct. It is always correct. In four weeks, the steering committee will discover this.
The Test Coordinator is the real project manager in the same way that a ship’s navigator is the real captain: the person with the title gives the orders, but the person with the chart knows where the rocks are.
The Virtual Branch
In 1998, the largest bank in Portugal needed a Virtual Branch for the opening of Expo 98 in May. The project was failing. It had three development teams on three continents. riclib was assigned to fix it. It was the first time anyone called him a project manager.
The system was a masterpiece of late-nineties integration ambition:
- A custom-built scanner, controlled from the browser via an ActiveX component
- A JavaScript library that talked to the mainframe directly from the browser — riclib went to Finland for the training, and while the instructor was bragging about the security model, he recited her password back to her. She did not appreciate this.
- A Java applet for the mainframe component
- A video conferencing module that connected customers to one of two operators sitting at the head office
The system only worked on Sundays if there was a full moon.
riclib received two hours of project management training. The one thing he remembers: “make an issue spreadsheet and take it everywhere with you.”
He made the spreadsheet. It had 238 items. He carried it everywhere — to the meetings with three development teams who had never spoken, to the demos where the scanner crashed the browser which crashed the ActiveX which crashed the mainframe session, to the builds that worked on Tuesdays but not on Wednesdays for reasons that took three days to diagnose (a caching issue in the Java applet that was time-zone-dependent because one team was in Asia).
His weekly timesheets never dropped below 90 hours. His record was 120 — in a 168-hour week, that leaves 48 hours for sleep, commuting, and maintaining the illusion of having a life outside the spreadsheet.
By May, the spreadsheet was down to 70. The Virtual Branch went live for Expo 98. It worked. The bank was pleased.
Shortly after, riclib received an offer from a company in the Netherlands. They had heard what he did for the bank and had a similar problem to fix. The salary was 50% more. He hesitated — “but they only offer 50% more.” His wife asked how many hours per week the new job required. “Thirty-six,” he said. She did the math for him.
He moved to the Netherlands. His career went international. The spreadsheet stayed behind in Lisbon, but the instinct — make a list, check items off, open new ones for what they broke, trust the arithmetic — went with him everywhere.
His title said project manager. The spreadsheet said Test Coordinator. He just didn’t know the name yet.
The Unfireable
The Test Coordinator has survived every Reorg. The Test Coordinator has survived every budget cut. The Test Coordinator has survived the transition from Waterfall to Agile to SAFe to whatever came after SAFe. The Test Coordinator has survived because the Test Coordinator is the answer to a question that every methodology ignores: who makes sure it all works together?
Agile says: “the team is responsible for quality.” In practice, each team is responsible for their quality. Nobody is responsible for the quality of the system — the thing that emerges when twenty teams’ outputs are combined. The Test Coordinator is that nobody. The Test Coordinator fills the gap that every process leaves, the gap between “each component works” and “the software works.”
Attempts to replace the Test Coordinator with automation have been made. Test automation is valuable. Test automation catches regressions. Test automation does not catch the interaction between Feature A and Feature C that only manifests when Feature B is enabled and the user navigates from the dashboard to the settings page and back — because nobody wrote that test, because nobody imagined that path, because imagining that path requires having run the software end-to-end two hundred times, which only the Test Coordinator has done.
The Test Coordinator is not a role. The Test Coordinator is a person. When the Test Coordinator retires, the company discovers what the Test Coordinator was actually doing, the same way you discover what a load-bearing wall was doing when you remove it.
The Misleading Name
The title “Test Coordinator” is the most misleading job title in software.
“Test” implies checking — verifying that something works as specified. The Test Coordinator does not check. The Test Coordinator discovers. The Test Coordinator finds things that nobody specified, that nobody designed, that nobody imagined — because the software, when assembled from its twenty components, exhibits behaviours that no component contains.
“Coordinator” implies organising other people’s work. The Test Coordinator does not coordinate. The Test Coordinator does the work — personally, manually, row by row, build after build, twenty hours a day, until the spreadsheet converges on zero or the release date arrives, whichever comes first.
A more accurate title would be: System Integration Engineer Who Also Finds All the Bugs and Is the Only Person Who Can Tell You If the Software Actually Works. This title does not fit on a business card, which is why “Test Coordinator” persists — short, wrong, and universal.
Measured Characteristics
- Average spreadsheet size at project start: 200-300 issues
- Issues closed per day: 10-15
- Issues opened per day by retesting fixes: 3-6
- Net progress per day: 8-10 issues
- Working hours during release cycle: 90-120 per week (record: 120, in a 168-hour week)
- Builds tested per release: 40-60
- Builds that broke something previously working: ~30%
- Features that work in isolation: ~90%
- Features that work together on first integration: ~20%
- People in the company who understand all features: 1 (the Test Coordinator)
- Test Coordinators fired: data not available (sample size too small)
- Test Coordinators who have survived a reorg: all of them
- Hair remaining: variable (inversely correlated with project complexity)
- Coffee consumption during release week: measured in litres, not cups
- The spreadsheet’s accuracy vs. the Gantt chart’s accuracy: 97% vs. optimistic
