Je hebt weken besteed aan het ontwikkelen van software, maar dan komt de UAT-fase… en plotseling blijkt dat gebruikers het compleet anders gebruiken dan je dacht. Klinkt bekend? We hebben het allemaal weleens meegemaakt. Poeh, die frustratie wanneer je denkt dat alles perfect werkt, maar de gebruikers vragen zich af waar de ‘echte’ functionaliteit gebleven is. Die willen we graag vermijden!
Het probleem zit hem vaak in de UAT test cases zelf. Ze zijn te technisch geschreven, of zijn geen realistische gebruikersscenario’s of acceptatiecriteria die zo vaag zijn geformuleerd dat niemand precies weet wanneer iets nou eigenlijk ‘af’ is. En dan maar hopen dat het wel goed komt tijdens de UAT-fase. En nee, dat gebeurt meestal niet.
In dit artikel zetten we op een rij hoe je UAT test cases schrijft die wel werken in de praktijk. We gaan het hebben over de juiste structuur, praktische aanpak die je meteen kunt gebruiken en vooral: hoe je test cases schrijft waar de business users ook mee uit de voeten kunnen. Want UAT test cases zijn geen technische documenten, het is eigenlijk de unieke verbinding tussen IT en de business.
Wat maken UAT test cases anders?
UAT test cases vergen een andere kijk dan de technische test cases waar we als testers meestal mee werken. Waar technische test cases focussen op ‘werkt deze functie volgens de specificaties?’, gaan UAT test cases over ‘kan een echte gebruiker hiermee zijn werk doen?’. Dat verschil is belangrijk.
Bij technische test cases test je of een systeem doet wat het moet doen. Bij UAT test cases test je of het systeem doet wat gebruikers ervan verwachten. En ja, dat zijn vaak twee heel verschillende dingen! Een systeem kan technisch perfect functioneren, maar als een gebruiker er niet uit kan komen dan faalt de UAT alsnog.
UAT test cases zijn ook de laatste check voordat software live gaat. Dat maakt ze extra belangrijk (en ook extra spannend!). Het is letterlijk het moment waarop business users beslissen: ‘Ja, we kunnen hiermee werken’ of ‘Nee, dit gaat zo niet lukken’.
Waar het in de praktijk vaak niet goed gaat? Een voorbeeld is als er UAT test cases worden geschreven alsof het technische test cases zijn. En dan vol staan met systeem termen, database-IDs en technische details waar een business user weinig tot niets mee kan. Of we maken ze zo vaag dat iedereen er iets anders onder verstaat. “Test of de gebruiker kan inloggen” Ok, maar wat betekent dat precies? Met welke gegevens? Wat gebeurt er bij een fout wachtwoord? En wanneer is het dan wel gelukt?
De opzet van een effectieve UAT test case
Een goede UAT test case is als een goed recept: alle ingrediënten staan erin, de stappen zijn duidelijk, en iedereen die het volgt komt tot hetzelfde resultaat. Laten we de onderdelen eens op een rij zetten.
Test case ID en naam – dit klinkt simpel, maar is wel belangrijk. Gebruik namen die business users begrijpen. In plaats van “TC_LOGIN_001” kun je beter gebruiken “Inloggen met geldige klantgegevens” of “Bestelling plaatsen als nieuwe klant”. Zo weet iedereen meteen waar het over gaat.
Beschrijving – hier leg je uit wat er getest wordt en vooral waarom. “We testen of klanten hun bestelling kunnen afronden omdat dit cruciaal is voor onze omzet.” Zo simpel kan het zijn. Business users snappen meteen waarom deze test belangrijk is.
Voorwaarden (precondities) – wat moet er klaarstaan voordat de test kan beginnen? “Klant heeft een account aangemaakt”, “Er zijn producten beschikbaar in de webshop”, “Betaalsysteem is online”. Concrete, checkbare voorwaarden.
Test stappen – hier beschrijf je stap voor stap wat de gebruiker doet. Pro tip: schrijf dit vanuit het perspectief van de gebruiker, niet vanuit het systeem. Dus niet “Klik op button element ID ‘submit_btn'”, maar “Klik op de groene knop ‘Bestelling bevestigen'”.
Verwachte resultaten – wat moet er gebeuren na elke stap? Wees concreet. “Systeem toont bevestigingspagina” is te vaag. Beter: “Pagina toont ‘Bedankt voor je bestelling’ met ordernummer en verwachte leverdatum.”
Acceptatiecriteria – wanneer is de test geslaagd? Dit is vaak het lastigste onderdeel, maar ook het belangrijkste. “Klant kan bestelling plaatsen” is dus niet genoeg. “Klant ontvangt binnen 2 minuten een bevestigingsmail en ziet het juiste ordernummer op het scherm” dat is wel een bruikbaar acceptatiecriterium.
Het punt is dat een business user deze test case moet kunnen lezen en uitvoeren zonder dat er een tester naast hem staat om uit te leggen wat er bedoeld wordt. Als je twijfelt of je test case duidelijk genoeg is, leg hem dan eerst eens voor aan een collega die er nog nooit naar gekeken heeft. Komt hij er goed uit?
Van user story naar UAT test case
User stories zijn bruikbare uitgangspunten voor UAT test cases. Ze zijn al geschreven vanuit gebruikersperspectief en focussen op businesswaarde. Het is een perfecte start om deze uit te werken tot concrete en toetsbare scenario’s.
Laten we eens kijken naar een praktijkvoorbeeld. Stel je hebt deze user story: “Als klant wil ik mijn bestelling kunnen afronden zodat ik mijn producten ontvang.” Prima verhaal, maar dit is nog niet testbaar. Hier kun je beter 5-10 verschillende UAT test cases van maken.
Je happy path wordt bijvoorbeeld: “Succesvolle bestelling plaatsen met iDEAL”. De Given-When-Then structuur helpt je om dit uit te werken:
- Given: Klant heeft producten in winkelwagen en is ingelogd
- When: Klant kiest iDEAL als betaalmethode en rondt betaling af
- Then: Bestelling wordt bevestigd en klant ontvangt orderbevestiging
Maar vergeet zeker de edge cases niet! “Bestelling plaatsen wanneer product niet meer op voorraad is”, “Bestelling plaatsen met verlopen betaalkaart”, “Bestelling plaatsen zonder ingelogd te zijn”. Dit zijn de scenario’s die in de praktijk vaak voor problemen zorgen.
Een goede vuistregel: per user story kun je meestal 3-7 UAT test cases maken. Eén happy path, 2-3 alternatieve flows en 2-3 error scenarios. Meer dan dat en je story wordt waarschijnlijk te groot. Dat wordt het tijd om hem op te splitsen.
Prioritering: welke test cases eerst?
Je hebt nu een mooie lijst met UAT test cases, maar de realiteit is dat er waarschijnlijk niet genoeg tijd is om ze allemaal uit te voeren. Dus welke doe je eerst?
Start met een business criticality matrix. Zet alle test cases in een schema van ‘business impact’ versus ‘waarschijnlijkheid dat het gebruikt wordt’. De test cases die hoog scoren op beide vlakken, die doe je eerst. Een inlogfunctie heeft bijvoorbeeld hoge business impact én wordt door iedereen gebruikt, dus die komt bovenaan.
Kijk ook naar gebruikersrollen en -journeys. De primaire gebruikersgroepen krijgen voorrang boven edge cases. Als 80% van je klanten via de webshop bestelt en 20% via de mobiele app, dan test je eerst de webshop grondig voordat je naar de app gaat.
Praktische tip die echt werkt: gebruik de MoSCoW-methode voor je UAT test cases. Must have (kritieke business processen), Should have (belangrijke functionaliteit), Could have (nice to have features), Won’t have (uit scope voor deze release). Focus je UAT-tijd op de Must haves en Should haves.
En als laatste aandachtspunt: vergeet je stakeholders niet! Vraag business owners welke processen voor hen het belangrijkst zijn. Zij weten vaak het beste welke functionaliteit echt make-or-break is voor het bedrijf.
UAT Templates en checklists die echt werken
Een goed template maakt het verschil tussen UAT test cases die werken en test cases die iedereen frustreren. Hier is een format dat ik in de praktijk veel zie werken:
UAT test case template:
- Test case ID: UAT_[functionaliteit]_[volgnummer]
- Test case naam: [Duidelijke, herkenbare beschrijving]
- User story referentie: [Link naar oorspronkelijke user story]
- Beschrijving: [Wat wordt getest en waarom]
- Precondities: [Wat moet klaarstaan]
- Test data: [Welke gegevens gebruik je]
- Test stappen: [Genummerde lijst van acties]
- Verwachte resultaten: [Per stap wat er moet gebeuren]
- Acceptatiecriteria: [Wanneer is test geslaagd]
- Prioriteit: [must/should/could have]
Voor de review van je test cases gebruik je best een checklist. Vragen als: Is het scenario realistisch voor een echte gebruiker? Kan een business user alle stappen uitvoeren zonder technische kennis? Zijn de verwachte resultaten specifiek genoeg? Zou iemand anders deze test case kunnen uitvoeren en tot hetzelfde resultaat komen?
Over tools gesproken: Excel werkt prima voor kleinere projecten, maar voor grotere teams zijn test management tools zoals TestRail, Zephyr of Azure DevOps handiger. Ze bieden betere traceability en maken rapportage een stuk makkelijker. Kies wat bij je team en project past, maar maak wel een keuze want half Excel, half tool werkt niet.
Veelvoorkomende drempels en oplossingen
“Business users begrijpen de test cases niet” dit hoor je waarschijnlijk het meest. De oplossing? Gebruik de taal die zij goed begrijpen, niet altijd die van de techniek. Schrijf “klik op de knop Opslaan” in plaats van “activate submit function”.
Betrek business users ook bij het schrijven van test cases. Organiseer workshops waarin jullie samen test scenarios bedenken. Zij kennen de business processen immers beter dan wij.
“Te veel test cases, te weinig tijd” is een klassieke. Hier helpt risk-based testing. Focus op wat het meeste risico oplevert als het mis gaat. Een crash in het betaalproces is erger dan een spellingsfout in de footer. Maak bewuste keuzes en communiceer die ook naar stakeholders. “We testen deze 20 kritieke scenario’s grondig, deze 10 doen we als we tijd hebben.”
“Onduidelijke acceptatiecriteria” dit is een killer voor elke UAT. Maak je acceptatiecriteria SMART: Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden. “Systeem reageert snel” is niet SMART. “Pagina laadt binnen 3 seconden” wel.
En hier is een gouden tip uit de praktijk: laat business users zelf test cases reviewen voordat de UAT begint. Vaak komen dan de onduidelijkheden naar boven die je anders pas tijdens de test merkt. Een uur review-sessie kan dagen UAT-frustratie voorkomen.
Best UAT test practices uit de praktijk
Wat ik in de loop der jaren geleerd heb: samenwerking is cruciaal bij UAT test cases. Organiseer workshops met business users, product owners en testers om samen test scenario’s te bedenken. Zij brengen de business kennis in, wij zorgen voor de technische haalbaarheid en teststructuur. Die combinatie werkt geweldig.
Houd je testcase documentatie ook actief en constant up to date. UAT test cases die je één keer schrijft en dan niet meer inkijkt of archiveert, zijn nutteloos. Zorg voor goede versie chronologie, als requirements wijzigen moeten je test cases mee wijzigen. Bouw feedback loops in: na elke UAT-ronde evalueer je wat goed ging en wat beter kan.
Een andere praktijktip: start niet pas met UAT test cases als de development klaar is. Begin al tijdens de development fase met het uitwerken van je test scenario’s. Zo kun je vroeg feedback geven op requirements en voorkom je later verrassingen.
En tot slot: documenteer je lessons learned. Welke test cases werkten goed? Waar liep je tegenaan? Wat zou je anders doen? Die kennis is goud waard voor je volgende project. We maken allemaal fouten, maar slimme teams maken niet twee keer dezelfde fout.
Conclusie
Goede UAT test cases schrijven is een vaardigheid die je ontwikkelt. Het gaat niet alleen om de techniek – hoewel een goede structuur en duidelijke templates zeker helpen. Het gaat vooral om het begrijpen van je gebruikers en het vertalen van hun behoeften naar testbare scenario’s.
De kern is simpel: schrijf test cases alsof je ze aan je eigen moeder moet uitleggen (tenzij je moeder toevallig software tester is, dan mag je iets technischer). Gebruik de taal van de business, focus op echte gebruikersscenario’s, en zorg dat duidelijk is wanneer iets geslaagd is.
Begin deze week met het beoordelen van je huidige UAT test cases. Pak er een paar bij elkaar en vraag jezelf af: zou een business user hier iets mee kunnen? Zijn de stappen duidelijk? Weet iedereen wanneer de test geslaagd is? Kleine aanpassingen kunnen al een groot verschil maken.
Want uiteindelijk gaat het hierom: goede UAT test cases maken het verschil tussen software die technisch werkt en software waar mensen écht blij mee zijn. En dat laatste is toch waar we het allemaal voor doen!
Wil je meer weten over UAT best practices? Check dan ook ons artikel over best practices in user acceptance testing en ontdek hoe je stakeholdermanagement kunt inzetten voor betere testresultaten.
