Wanneer jij je testen uitvoert, denk je als een tester. Je denkt in testsoorten, testtechnieken en standaard testgevallen. Dit geeft natuurlijk een betrouwbare test. Maar je denkt vaak vanuit de functionaliteit die beschreven is, de paden die bekend zijn, de situaties die vaak fout gaan. Misschien heb je de test ook wel aangevuld met de meest voorkomende situaties in de praktijk, maar het blijft echt een IT test. Hoeveel je ook probeert, je hebt de domeinkennis niet opeens bij de hand, als je voor het eerst een onderdeel test. De persoon die het systeem gebruikt, heeft kennis die ook nodig is om goed te testen. Gaan alle situaties die in de praktijk voorkomen wel goed? Is er niet per ongeluk een situatie vergeten? Worden de gegevens in alle aansluitende systemen goed verwerkt? Er is niemand die dat beter kan beoordelen, dan de persoon die elke dag met het systeem werkt.
Maar deze persoon is geen tester. De kennis is in het hoofd aanwezig, maar komt niet zomaar op papier. Dus gewoon zeggen: "Jij hebt de kennis, dus test het maar" levert vaak geen betrouwbare test op. Waarmee de extra kennis geen extra waarde heeft in het testtraject. En juist door deze kennis goed in te zetten bij een acceptatietest, ontstaat een veel betrouwbaarder testtraject. Waarin zowel vanuit test- als domeinkennis een volledige test wordt uitgevoerd. Maar hoe kom je tot een acceptatietest?
Het belangrijkste is om eerst zelf een schakel om te zetten. Vergeet je testtechnieken, testmethodes, testgevallen. Probeer niet te denken in grensgevallen of andere voor jou logische testen. Waarom dit van belang is? De testen moeten geschreven gaan worden als praktijksituaties. Jij kan weten dat twee praktijksituaties in het systeem geen enkel verschil uitmaken, maar door dit uit te leggen bemoeilijk je het beschrijven voor de acceptatietester. Wanneer deze elke testsituatie door jou laat keuren, is de kans groot dat hij of zij zich niet meer vrij voelt om elke praktijksituatie op te noemen. En juist deze onbelemmerde vrijheid geeft een soort van brainstormsituatie. Waardoor ook de meer uitzonderlijke gevallen boven gaan komen. Die wil je horen. Daarvoor moet jij een volledige vrije omgeving creëren. En je opmerkingen over welke testen overgeslagen of samengevoegd of beter kunnen worden voor je houden.
Hoe kan je wel helpen? Maak gebruik van CRUD (Create, Read, Update, Delete). Begin met de meest simpele. In veel gevallen is dit de Update. Vraag aan de persoon in welke gevallen er sprake is van wijzigingen. En ga hierna voor elke letter (voor zover van toepassing) de situaties na. Wanneer worden er nieuwe zaken aangemaakt? Wanneer worden ze verwijderd of op inactief gezet? Hoe worden de gegevens weer opgevraagd en welke gegevens worden dan opgevraagd? Naast de CRUD kan je ook gebruik maken van de bekende gegevens. Stel dat een persoon een voornaam, tussenvoegsel en achternaam heeft. Vraag dan bijvoorbeeld welke van deze gegevens gewijzigd worden. En maak van elk van deze gegevens een testgeval. In veel gevallen zal dit leiden tot een wijziging in voornaam, een wijziging in tussenvoegsel en een wijziging in achternaam. Drie testcases. Of slechts een, namelijk tussenvoegsel en achternaam samen. Wat de uitkomst is, maakt niet uit. Als het maar een situatie uit de praktijk is.
Waar het dus om gaat, is dat je de persoon hulpmiddelen geeft om vrij praktijksituaties te bedenken, die getest moeten worden. Zonder sturing, maar met hulp. Zonder correcties, behalve de controle of het volledige systeem getest wordt. Maar let op: niet of het systeem volledig getest wordt, dat moet je in je eigen test opvangen. Door te praten in praktijksituaties, in plaats van testcases, ontstaat dan een situatie waarin iedereen testcases kan bedenken. En ze vervolgens ook kan uitvoeren. Waardoor beide testen elkaar echt gaan aanvullen.
