Softwarebureau · Delivery
Softwareoplevering en klantacceptatie
Breng elke mijlpaal van afgesproken requirements naar een vastgelegd akkoord van de klant. De klant bevestigt de acceptatiecriteria en geeft akkoord via een openbare link, en geen enkele build bereikt de klant voordat QA en de engineering lead hem goedkeuren.
- Doorlooptijd: 4 tot 8 weken
- Hoe vaak: Voor elke mijlpaal
- Stappen: 11 stappen
- AI-agents: 2 AI-agents
- Goedkeuringen: 3 goedkeuringen
Gratis plan, geen creditcard nodig.
Wat er verandert met dit sjabloon
Zonder sjabloon
De klant herinnert zich tijdens de sprintdemo een onmisbare functie.
Een build staat de avond voor de klantdemo op staging, half getest.
Acceptatie is een duim omhoog in een call die een maand later niemand meer kan terugvinden.
QA schrijft elk testplan vanaf nul.
Met dit sjabloon
De klant bevestigt de acceptatiecriteria voordat de bouw begint, zodat het team tegen één lijst bouwt.
Het testen door de klant blijft vergrendeld tot QA en de engineering lead de release goedkeuren.
De klant geeft akkoord in de uitvoering, met de afgevinkte controles, de naam en het tijdstip.
Een AI-agent stelt het testplan op uit de criteria, en de QA-engineer beoordeelt het.
Het sjabloon, stap voor stap
Bij elke stap staat wie hem uitvoert: iemand in uw team, een AI-agent of de klant via een openbare link. Een goedkeuring houdt alle volgende stappen vergrendeld tot ze is gegeven.
- Uitgevoerd door uw team
- Uitgevoerd door een AI-agent
- Uitgevoerd door de klant, via een openbare link
Begint wanneer
Een mijlpaal uit de opdrachtomschrijving kan beginnen. De productmanager start een uitvoering met de klantnaam en de mijlpaal.
- 1
Schrijf de scope en de acceptatiecriteria
Week 1Productmanager · Team
Zet de mijlpaal uit de opdrachtomschrijving om in user stories met testbare acceptatiecriteria, noteer de vragen die de klant nog moet beantwoorden, en mail beide met de ontwerpen naar de product owner bij de klant.
Checklist
- Elke story heeft acceptatiecriteria
- Wat buiten de scope valt is benoemd
- Criteria en ontwerpen naar de klant gestuurd
In te vullen velden
- Mijlpaal (verplicht)
- Acceptatiecriteria (verplicht)
- Vragen aan de klant
- Link naar de ontwerpen (verplicht)
- 2
Klant bevestigt de requirements
Week 1Product owner bij de klant · Openbare link
De product owner bij de klant leest de acceptatiecriteria, ontwerpen en vragen die de productmanager heeft gemaild, en beantwoordt de vragen en bevestigt de scope via de openbare link. Het team bouwt en test tegen wat hier is bevestigd.
Checklist
- Acceptatiecriteria gelezen
- Ontwerpen bekeken
- Openstaande vragen beantwoord
In te vullen velden
- Antwoorden op de openstaande vragen
- Link naar bedrijfsregels of voorbeelden
- Ik bevestig de acceptatiecriteria (verplicht)
- 3
Stel het testplan op
Week 1Testplanschrijver · AI-agent
De testplanschrijver zet elk bevestigd acceptatiecriterium om in testcases met stappen en verwachte resultaten, en voegt regressiecontroles toe voor de functies die de mijlpaal raakt.
In te vullen velden
- Concepttestplan (verplicht)
Gecontroleerd door: De QA-engineer beoordeelt en vult het testplan aan in stap 4.
- 4
Beoordeel het testplan
Verborgen voor de openbare linkWeek 2QA-engineer · Team
Controleer of elk acceptatiecriterium een testcase heeft, voeg de randgevallen toe die het concept mist en link het definitieve testplan.
Checklist
- Elk criterium heeft een testcase
- Randgevallen toegevoegd
- Testdata klaar op staging
In te vullen velden
- Link naar het definitieve testplan (verplicht)
- 5
Bouw en review in sprints
Week 2 tot 5Engineering lead · Team
Bouw de stories in sprints en review elke wijziging voordat die wordt gemerged. Wacht het team op een antwoord van de klant, zet de uitvoering dan op geblokkeerd en noteer de vraag.
Checklist
- Elke wijziging gereviewd vóór de merge
- Sprintdemo's gehouden met de klant
- Geen openstaande vragen aan de klant
In te vullen velden
- Geplande releasedatum (verplicht)
- Sprintnotities (verplicht)
- Link naar het gemergede werk (verplicht)
- Waar het team op wacht
- 6
Test op staging tegen elk criterium
Verborgen voor de openbare linkWeek 6QA-engineer · Team
Voer het testplan uit op staging, registreer defecten in de issuetracker en test de fixes opnieuw tot er geen kritieke of grote bug meer openstaat.
Checklist
- Elk criterium getest
- Regressiecontroles uitgevoerd
- Geen openstaande kritieke of grote bugs
- Bekende kleine problemen genoteerd
In te vullen velden
- Link naar het testrapport (verplicht)
- Bekende problemen
Goedkeuring: De releasegoedkeuring blijft vergrendeld tot de QA-engineer de testresultaten goedkeurt.
- 7
Stel de releasenotes op
Week 6Releasenotesschrijver · AI-agent
De releasenotesschrijver stelt releasenotes voor de klant op uit de acceptatiecriteria, de sprintnotities en de bekende problemen: wat nieuw is, wat is veranderd en wat nog openstaat.
In te vullen velden
- Conceptreleasenotes (verplicht)
Gecontroleerd door: De engineering lead corrigeert de notes en keurt de release goed in stap 8.
- 8
Keur de release goed voor het testen door de klant
Week 6Engineering lead · Team
Lees het testrapport, corrigeer de releasenotes en controleer of staging de geteste build draait. Keur hem daarna goed en mail de product owner bij de klant de stagingslink en de releasenotes.
Checklist
- Testrapport gelezen
- Releasenotes gecorrigeerd
- Staging draait de geteste build
In te vullen velden
- Stagingslink gestuurd naar de klant (verplicht)
Goedkeuring: Het testen door de klant blijft vergrendeld tot de engineering lead de release goedkeurt.
- 9
Klant test op staging en geeft akkoord
Week 7Product owner bij de klant · Openbare link
De product owner bij de klant test de build op staging via de link die het team heeft gemaild, tegen de acceptatiecriteria, en vinkt daarna elke controle af en legt de beslissing vast via de openbare link. Problemen komen in het veld hieronder, met links naar schermafbeeldingen of opnames.
Checklist
- Elk acceptatiecriterium getest
- Releasenotes gelezen
In te vullen velden
- Beslissing (verplicht)
- Gevonden problemen
- Links naar schermafbeeldingen of opnames
- 10
Beslis over de bevindingen van de klant
Week 7Productmanager · Team
Loop de beslissing en elke bevinding door met de engineering lead. Blokkeert een bevinding de acceptatie, zet de uitvoering dan op geblokkeerd met de reden tot de fix is geverifieerd en de klant akkoord is, en keur daarna de productierelease goed.
Checklist
- Elke bevinding gemarkeerd als blokkerend of niet
- Blokkerende bevindingen opgelost en geverifieerd
- Overige bevindingen ingepland voor een latere mijlpaal
In te vullen velden
- Bevindingen verplaatst naar een latere mijlpaal
Goedkeuring: De productierelease blijft vergrendeld tot de productmanager hem goedkeurt.
- 11
Release naar productie en sluit de mijlpaal af
Week 7DevOps-engineer · Team
Zet de geaccepteerde build live met het terugvalplan paraat, voer de smoketests uit en noteer de vrijgegeven versie.
Checklist
- Terugvalplan paraat
- Smoketests geslaagd
- Monitoring gecontroleerd na de release
In te vullen velden
- Vrijgegeven versie (verplicht)
- Vrijgegeven op (verplicht)
Klaar wanneer
De klant heeft de mijlpaal geaccepteerd tegen de afgesproken criteria, en de release staat live met testrapport, goedkeuringen en akkoord in de uitvoering.
Pas het aan. Hernoem stappen, wijzig eigenaren en voeg checklistpunten, velden of goedkeuringen toe. Het sjabloon is een startpunt voor de manier waarop uw team werkt.
De AI-agents in dit sjabloon
Een agent werkt alleen aan zijn eigen stappen, en iemand in uw team controleert wat hij heeft gedaan. Alles wat een agent naar een gekoppelde app schrijft, wacht op goedkeuring tenzij u het toestaat.
Testplanschrijver
Maakt van de bevestigde acceptatiecriteria een concepttestplan.
Wat hij doet
- Leest de acceptatiecriteria en de antwoorden van de klant in de uitvoering
- Schrijft testcases met stappen en verwachte resultaten
- Voegt regressiecontroles toe voor de functies die de mijlpaal raakt
- Rondt zijn stap af, zodat de QA-engineer kan beoordelen
Gecontroleerd door: De QA-engineer beoordeelt en vult het testplan aan in stap 4.
Releasenotesschrijver
Schrijft releasenotes voor de klant bij de build die naar de klanttest gaat.
Wat hij doet
- Leest de acceptatiecriteria, sprintnotities en bekende problemen
- Schrijft wat nieuw is, wat is veranderd en wat nog openstaat
- Houdt de notes in begrijpelijke taal voor de klant
- Rondt zijn stap af, zodat de releasegoedkeuring kan beginnen
Gecontroleerd door: De engineering lead corrigeert de notes en keurt de release goed in stap 8.
Vragen die dit sjabloon beantwoordt
Vraag het akkoord aan tegen de acceptatiecriteria die de klant aan het begin heeft bevestigd, niet tegen een demo. In stap 9 test de product owner bij de klant op staging, vinkt daarna elke controle af en legt de beslissing vast via de openbare link, met naam en tijdstip in de uitvoering.
Spreek testbare acceptatiecriteria af voordat de bouw begint, en laat de klant ze aantoonbaar bevestigen. In stap 2 beantwoordt de product owner bij de klant de openstaande vragen en bevestigt de criteria via de openbare link, zodat het team bouwt en test tegen één afgesproken lijst.
Laat het testen door de klant afhangen van goedgekeurde testresultaten, niet van de demodatum. Stap 6 en stap 8 zijn goedkeuringscontroles: het testen door de klant blijft vergrendeld tot de QA-engineer en de engineering lead de release allebei hebben goedgekeurd.
Bewaar de acceptatiecriteria, de testresultaten en de beslissing van de klant in één vastlegging. De uitvoering toont de criteria die in stap 2 zijn bevestigd, de testresultaten en goedkeuringen uit stap 6 en 8, en het akkoord uit stap 9 met naam en tijdstip.
Laat AI het testplan en de releasenotes opstellen uit wat uw team al heeft geschreven, en houd de beoordeling bij mensen. In stap 3 schrijft de testplanschrijver testcases die de QA-engineer in stap 4 beoordeelt, en in stap 7 schrijft de releasenotesschrijver notes die de engineering lead in stap 8 corrigeert.
Scheid de bugs die acceptatie blokkeren van de punten die kunnen wachten, en laat een mens die keuze maken. In stap 10 markeert de productmanager elke bevinding als blokkerend of niet, houdt de uitvoering geblokkeerd tot blokkerende fixes zijn geverifieerd, en keurt pas dan de release goed.
Voer deze workflow uit in OKiDO
Richt de stappen, eigenaren en goedkeuringen één keer in en start daarna een uitvoering voor elke nieuwe zaak.