Systeem voor een afdeling quality assurance (QA)

Vóór elke release wordt een “Plan”-kaart opgebouwd die de testomvang bepaalt: de nieuwe features, de risicovolste gebieden en de te dekken apparaten en browsers. Zodra de releasekandidaat gereed is, gaat de kaart naar “Uitvoering”, waar de testers de scenario's doorlopen en de uitkomst van elke case vastleggen. Elk ontdekt defect wordt een “Melding”-kaart met de stappen om te reproduceren, het verwachte en het werkelijke resultaat en de ernstgraad; een developer neemt die over en fixt hem. De gefixte melding keert terug naar “Verificatie”, waar een andere tester dan de indiener controleert dat de fix niets anders heeft gebroken. Wanneer de kritieke meldingen op nul staan, gaat de moederkaart naar “Uitrol” met een officiële aanbeveling, en de cijfers worden overgebracht naar “Rapport”: hoeveel cases zijn uitgevoerd, hoeveel meldingen zijn gevonden en in welke gebieden de defecten zich concentreren.

De chat is de controlekamer tijdens het testen: een kritieke melding die de release stopt wordt er direct aangekondigd, en een vraag of een gedrag bedoeld is of een bug wordt in een minuut met de developer beslecht in plaats van met een afgewezen kaart. Maar de regel is strikt: wat in de chat aan besluiten wordt genomen, wordt op de meldingskaart zelf vastgelegd — het bord is het register, niet het geheugen.

De QA-manager schrijft het “Plan”, verdeelt de uitvoering en bezit het besluit om uitrol aan te bevelen — hij is degene die de release stopt als er kritieke meldingen resteren. De testers voeren uit en schrijven de meldingen volgens een uniforme standaard; de developers ontvangen de meldingen, fixen ze en sturen ze terug naar “Verificatie”. Het principe van het systeem: de tester verifieert niet de fix van een melding die hij zelf heeft geschreven, en de uitrol is een gedocumenteerd besluit met cijfers, geen algemeen gevoel dat het er wel goed uitziet.