Kamp je ook wel eens met de vraag: “Hoe weet ik of ik geen testgevallen mis?” Of krijg je de vraag: “Wat is onze testdekking?” Vaak worden deze antwoorden toevertrouwd aan het onderbuikgevoel van de tester. Er wordt immers van de tester verwacht dat deze de kwaliteiten heeft om in te schatten en te bepalen waar de productrisico’s liggen. Maar wat als je die (testers) intuïtie moet communiceren naar teamgenoten of stakeholders? Zoals een Product Owner die de kwaliteit van zijn product wil weten, of een collega die jou komt vervangen?
Al deze vragen richten zich op twee belangrijke pijlers binnen het testen: traceability en coverage. Het idee is om een link te leggen tussen een feature aanvraag (de documentatie) en de test resultaten (het resultaat). Graag vertel ik je wat ik heb geleerd over de balans tussen intuïtie en absolute waarheden
Toen ik een jaar bezig was bij mijn opdracht, kreeg ik die vraag: “Geef een cijfer van 1 tot 5 over hoe goed onze testdekking is.” In een domein met zeven verschillende applicaties, waar ik door de waan van de dag zeker nog niet alles van had gezien, vond ik dat een onmogelijke vraag. Ik wilde niet gokken, maar het zeker weten. Ik ben toen op zoek gegaan bij de newspark collega’s wie hier ook vragen over had en het liefst zelfs antwoorden. Mijn optimisme werd beloond toen collega Silvio bleek met dezelfde vragen te zitten en hier zelfs een applicatie voor heeft laten ontwikkelen: TestCompass.
Ik ontdekte dat TestCompass methodes als (early) Model Based Testing (eMBT)en shift-left omarmt om vroeg in het proces de juiste vragen te stellen. Door vroeg in het proces (van het tot stand komen van een functionaliteit) aandacht te besteden aan het opstellen van een testmodel, werd duidelijk welke paden er zijn en welke aandacht vereisen. Waar contradicties, aannames en open eindjes zaten. Deze testmodellen worden later gebruikt als input voor het opstellen van testgevallen.
Met behulp van TestCompass kon ik (met terugwerkende kracht) vanuit de functionele documentatie testmodellen maken. Deze modellen besprak ik met de Product Owner en ontwikkelaar om de kloof tussen het idee en de uitvoering te dichten (Three Amigo-gesprekken). Hierdoor kon ik eindelijk onderbouwen waar mijn testgevallen vandaan kwamen. Niet alleen waardevol voor mijzelf maar ook voor de tester die na mij zal komen.
Tijdens de Three Amigo-gesprekken kwamen we erachter dat we een aantal testpaden niet gecoverd hadden, die we toch graag gedekt wilde hebben. Niet alleen dat, maar we kregen zelfs vragen waarom deze functionaliteit eigenlijk zo werkte. Met een testmodel als praatplaat werd het idee concreter en krijgen alle betrokkenen een gezamelijk begrip van hoe de functie zou moeten werken.
Vanuit de modellen kon ik direct de coverage bepalen door deze in TestCompass automatisch te laten genereren. Hierbij zijn verschillende test coverage vormen mogelijk gebaseerd op de ingeschatte risico’s. Zo had ik direct vanuit het testmodel mijn testgevallen, zonder er één over het hoofd te zien.
Met het idee dat ik alles gecoverd kon hebben, sloeg ik door. Ik wilde een API datacontract validatie modelleren met alle exceptie paden. Modelleren bleek echter niet de 'holy grail' waarin je elke uitzondering moet uitwerken. De truc die ik leerde was, om niet door te slaan in het nastreven van absolute waarheden, maar ook hier te durven vertrouwen op (testers) intuïtie (wat werk ik wel uit en wat niet?).
Door gebruik te maken van TestCompass kun je niet alleen vragen over coverage beter beantwoorden, maar krijg je ook de bijvangst van traceability. Je kunt de gegenereerde testgevallen direct exporteren naar Jira en linken aan Epics of Stories. Zo is de weg van resultaat naar documentatie altijd terug te vinden.
Kan ik nu, met behulp van deze modellen, beter antwoord geven op de vraag welk cijfer ik onze testdekking geef? Ja. Door te accepteren dat je het nooit 100% zeker kunt weten, maar het ook niet volledig bij intuïtie te laten (wat effectief 0% onderbouwing is), bieden testmodellen de perfecte basis. Je ontkomt er niet aan om je intuïtie te gebruiken, maar door model based testen (MBT) krijgt die intuïtie een fundament.
