Sign-off

The last exams before Maple Grove are taken by people, and the final examiner does not work at Traversal.

The discipline behind all of it, the craft of asking is this actually ready, is quality assuranceConcept · lights on your mapquality assuranceQA: the discipline, and often the team, responsible for verifying software works before users meet it. Test plans, edge-case hunting, and ownership of the readiness question. In automation-heavy teams, QA increasingly builds the test machinery itself.. At Traversal, QA is one engineer and a culture rather than a department, and the culture’s job this week is the cheer feature’s readiness.

First comes acceptance testingConcept · lights on your mapacceptance testingVerifying a feature against its acceptance criteria: the ticket’s checklist, executed line by line. Done-ness, verified rather than declared., and you have already read the exam paper. It is Dana’s checklist from week one, executed line by line. One message, 140 characters, one runner. Sent after the finish: dropped, quietly. Each line was written, back then, precisely so that this week a person could sit down and check it, which is the long game of acceptance criteria and the reason vague ones cost so much.

The signature that matters

Then the race director arrives, three boroughs of scepticism in one person, for UATConcept · lights on your mapUATUser acceptance testing: the actual stakeholder trying the feature in a staging-like world and formally signing off. Acceptance testing checks the written criteria; UAT checks the stakeholder’s actual intent.. In the staging world, on a fake race, the race director sends cheers, receives them as a pretend runner, tries to break the character limit, fails, approves. The distinction is the point: acceptance testing checked the list, UAT checks the intent behind the list, and the sign-off email that follows is, in several organisational senses, the actual release artifact.

And underneath the whole week, silently, the oldest promise: regression testingConcept · lights on your mapregression testingRe-running the accumulated suite on every change to confirm nothing old broke, a regression being exactly such a backslide. Not a new kind of test: the pyramid, replayed forever.. Every night’s fake marathon re-runs every exam the codebase has ever earned, so that the cheer feature’s arrival cannot quietly break the results export, the migration, or anything else this act built. New features are easy to check. Not breaking eleven years of old ones is the pyramid’s real job.

Signed off. Now the feature has to reach production, and nothing carries it there but machinery.