Leiderschap in testen: modellering en dekking
In de wereld van softwaretesten weet effectief leiderschap hoe het een duidelijke richting moet bepalen voor de manier waarop teststrategieën aansluiten op ontwikkeldoelen. Naarmate softwaresystemen steeds complexer worden, hebben traditionele testmethoden moeite om bij te blijven.
Hier worden innovatieve benaderingen zoals testmodellering en dekkingsanalyse cruciaal. Deze werkwijzen zorgen ervoor dat teams kritieke paden en randgevallen afdekken en maken betere samenwerking, minder risico en snellere oplevering mogelijk.
In dit artikel onderzoeken we wat het betekent om leiding te geven met modellering en dekking als uitgangspunt. We bespreken hoe testleiders deze strategieën kunnen inzetten om hun processen te optimaliseren, de productkwaliteit te verbeteren en een uitgebreide testdekking te garanderen—en dat alles terwijl ze een cultuur van uitmuntendheid en verantwoordelijkheid bevorderen. Of je nu QA-manager, teamleider bent of je inzicht in testleiderschap gewoon wilt verdiepen, deze gids voorziet je van bruikbare inzichten en technieken om je testaanpak naar een hoger niveau te tillen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Laten we erin duiken.
Wat is een testmodel?
Testen is een proces waarin we mentale modellen creëren van de omgeving, het programma, de menselijke aard en de tests zelf. Elk model wordt gebruikt totdat we accepteren dat het gedrag correct is of totdat het model niet langer toereikend is voor het beoogde doel.
Boris Beizer, Software Test Techniques, 1990
Testontwerp is het proces waarbij we uit het brede scala aan beschikbare opties de tests selecteren waarvan we denken dat ze voor ons en onze belanghebbenden de meeste waarde opleveren. Testmodellen helpen ons om tests systematisch te selecteren en vormen de basis van testen.
De manier waarop testers modellen gebruiken:
- We identificeren en onderzoeken kennisbronnen om testmodellen op te bouwen.
- We gebruiken deze modellen om onze bronnen uit te dagen en te valideren, waardoor zowel onze bronnen als onze modellen verbeteren.
- We gebruiken deze modellen om zowel het testen als de ontwikkeling richting te geven.
Gegeven een testmissie is onze eerste taak het identificeren van kennisbronnen. Dit kunnen de volgende zijn:
- Documentatie: specificaties, ontwerpen, vereisten, standaarden, richtlijnen enzovoort.
- Mensen: belanghebbenden, gebruikers, analisten, ontwerpers, ontwikkelaars en anderen.
- Ervaring: je eigen kennis en ervaring met vergelijkbare (of juist verschillende) systemen, je voorkeuren, vooroordelen, gissingen, ingevingen, overtuigingen en vooringenomenheden.
- Nieuw systeem: het systeem dat wordt getest, als het bestaat, beschikbaar en toegankelijk is.
- Oud systeem: het systeem dat wordt vervangen is uiteraard een bron – het kan op bepaalde gebieden van de functionaliteit een orakel voor verwacht gedrag bieden.
Het is belangrijk om op te merken dat al onze kennisbronnen feilbaar en onvolledig zijn, en dat geldt ook voor onze modellen. Testers gebruiken ervaring, vaardigheden en beoordelingsvermogen om deze bronnen te doorgronden, ze met elkaar te vergelijken en ter discussie te stellen, en tot een consensus te komen.
Alle modellen zijn fout, sommige zijn bruikbaar
George Box, econoom.
Een testmodel kan een checklist of een reeks criteria zijn. Het kan ook een diagram zijn dat is afgeleid van een ontwerpdocument of een analyse van verhalende tekst. Veel testmodellen worden nooit op papier vastgelegd – het kunnen mentale modellen zijn die specifiek zijn opgesteld om de tester te begeleiden tijdens het verkennen van het systeem dat wordt getest.
Het doel van modellen is complexe situaties te vereenvoudigen door details weg te laten die op dat moment niet relevant zijn. We gebruiken modellen om een probleem te vereenvoudigen – bijvoorbeeld door te selecteren wat we moeten testen. Het model beïnvloedt ons denkproces en we selecteren tests door het voorkomen van een bepaald belangrijk aspect van het model te identificeren.
We kunnen vertakkingen in een stroomdiagram of besturingsstroomdiagram selecteren, statusovergangen in een statusmodel, grenzen in een model van een invoer- (of uitvoer)domein en scenario's die zijn afgeleid van gebruikersverhalen die zijn geschreven in de domeinspecifieke taal Gherkin.
Maar let op: soms maken modellen omissies die niet veilig zijn – misschien vereenvoudigt het model een situatie te sterk – en daar moeten we aandacht aan besteden. Om je testmodellen efficiënter te maken, is het essentieel om gespecialiseerde testbeheersoftware te gebruiken.
Als we niet rechtstreeks over modellen uit onze bronnen beschikken, moeten we ze zelf bedenken. Wanneer vereisten bijvoorbeeld als verhalende tekst worden gepresenteerd, moeten we de taal van de vereisten gebruiken om functies en de logica van hun gedrag af te leiden. Dit kan moeilijk zijn voor ontwikkelaars en testers en is vaak een gezamenlijke inspanning, maar we moeten volharden.
Modellen gebruiken om te testen
We gebruiken testmodellen om:
- Vereenvoudig de context van de test. Irrelevante of verwaarloosbare details worden in het model genegeerd.
- Richt de aandacht op één perspectief van het gedrag van het systeem. Dit kunnen kritieke of risicovolle functies zijn, technische aspecten, interessante gebruikershandelingen of aspecten van de constructie of architectuur van het systeem.
- Genereer een reeks unieke tests (binnen de context van het model) die divers zijn (met betrekking tot dat model).
- Maak het mogelijk om het testen te ramen, te plannen, te bewaken en te evalueren op volledigheid (dekking).
Vanuit het perspectief van de tester helpt een model ons om aspecten van het systeem te herkennen die het onderwerp van een test kunnen zijn.
Modellen en dekking
Dekking is de term die we gebruiken om de grondigheid of volledigheid van ons testen met betrekking tot ons testmodel te beschrijven. Een dekkingsitem is iets dat we in onze tests willen uitvoeren.
Idealiter identificeert ons testmodel dekkingsitems op een objectieve manier. Wanneer we tests hebben gepland of uitgevoerd die de door ons model geïdentificeerde items afdekken, kunnen we de bereikte dekking kwantificeren en die dekking, als verhouding van alle items in het model, uitdrukken als een percentage.
Elk model waarmee dekkingsitems kunnen worden geïdentificeerd, kan worden gebruikt.
Modellen zijn vaak grafisch, met voorbeelden zoals stroomdiagrammen, gebruiksscenario's, sequentiediagrammen enzovoort. Deze en vele andere modellen bevatten elementen (of vormen) die door lijnen of pijlen met elkaar zijn verbonden. Deze worden doorgaans gerichte grafen genoemd.
Stel je een grafisch model voor dat uit vormen en pijlen bestaat. Er kunnen ten minste twee dekkingsdoelen worden gedefinieerd:
- Dekking van alle vormen
- Dekking van alle pijlen
- Enzovoort
Dus kan elk model dat een gerichte graaf is op dezelfde manier worden behandeld.
Met een formeel model kunnen dekkingsitems betrouwbaar worden geïdentificeerd. Daarom kan een kwantitatieve dekkingsmaatstaf worden gedefinieerd en gebruikt als een meetbaar doel.
Informele modellen zijn doorgaans checklists of criteria die worden gebruikt om te brainstormen over een lijst met dekkingsitems, ideeën voor testen te genereren of te testen tijdens een verkennende testsessie. Deze lijsten of criteria kunnen vooraf zijn gedefinieerd, zijn opgesteld als onderdeel van een testplan of zijn overgenomen in een verkennende testsessie.
Informele modellen verschillen van formele modellen doordat het afleiden van dekkingsitems afhankelijk is van de ervaring, intuïtie en verbeeldingskracht van de uitvoerder. Daarom kan de dekking met behulp van deze modellen nooit worden gekwantificeerd. We kunnen nooit weten wat volledige dekking betekent met betrekking tot deze modellen.
Tests die zijn afgeleid van een informeel model zijn net zo valide als tests die zijn afgeleid van een formeel model, als ze onze kennis van het gedrag of de mogelijkheden van ons systeem vergroten.
Modellen vereenvoudigen, dus gebruik er meer dan één
Een goed model biedt een manier om complexiteit te begrijpen en bereikt dit gedeeltelijk door details uit te sluiten die niet relevant zijn. Je model kan gebruikmaken van het concept van toestanden, foutmodi of stromen, invoercombinaties, domeinwaarden enzovoort.
Eén model is nooit voldoende om een systeem volledig te testen. Alle modellen sluiten compromissen, dus hebben we meerdere modellen nodig. Dit concept wordt gewoonlijk aangeduid als ‘diverse halve maatregelen’. Dit betekent dat we een diversiteit aan gedeeltelijke modellen nodig hebben om een systeem goed te testen.
Hoewel dit doorgaans niet in deze termen wordt beschreven, maken de testfasen in een watervalproject gebruik van modellen vanuit verschillende perspectieven. Unittests, subsysteemintegratietests, systeemtests en gebruikerstests hebben allemaal verschillende doelen; elke test gebruikt een ander model en perspectief – daar komt de diversiteit vandaan.
Modellen gebruiken voor beheer
Modellen vormen de kern van testen en ook van testbeheer. Dit omvat vier belangrijke aspecten:
- Betrokkenheid van belanghebbenden
- Reikwijdte
- Dekking
- Schatting en voortgangsbewaking
Betrokkenheid van belanghebbenden
Wanneer we tests plannen en afbakenen en aan belanghebbenden de voortgang en de betekenis van dekking uitleggen, moeten we modellen gebruiken die begrijpelijk zijn en aansluiten bij de doelstellingen van de belanghebbenden.
Als we een gebruikerstest plannen, zullen we waarschijnlijk de bedrijfsprocesstroom als ons model en als sjabloon gebruiken om paden te traceren waarmee we systeemfuncties testen die voor de gebruiker van belang zijn. Als we de integratie van servicecomponenten testen namens een technisch architect, gebruiken we het architectuurmodel, samenwerkingsdiagrammen, interfacespecificaties enzovoort als basis voor onze tests. Als we functies testen die door gebruikers zijn gedefinieerd, gebruiken we de gebruikersverhalen die het resultaat waren van eerder gezamenlijk uitgevoerd eisenwerk.
Als belanghebbenden je modellen niet begrijpen, zullen ze je tests niet begrijpen, vertrouwen of erin investeren. Misschien vertrouwen ze jou zelfs niet.
De reikwijdte beheren
De eerste activiteit binnen een discipline van systeemdenken is het definiëren van een systeemgrens. Bij het testen helpt het eerste model dat je definieert je om de reikwijdte van de tests vast te stellen. Het onderstaande diagram is een schematische weergave van de systeemarchitectuur – een ‘systeem van systemen’ – binnen een organisatie.
Elk systeem (de concentrische cirkels) bevindt zich binnen een toepassingsgebied, zoals CRM, boekhouding of de website. Alle systemen en toepassingsgebieden bevinden zich binnen het ‘systeem van systemen’. Het model bevat uiteraard geen details, maar het is duidelijk te zien hoe elk systeem in de algehele architectuur past.
We zouden de reikwijdte van onze tests bijvoorbeeld eenvoudig kunnen definiëren als de ERP-systemen.
In het tweede onderstaande diagram hebben we meer details aan de systeemarchitectuur toegevoegd en drie manieren voorgesteld waarop we de reikwijdte specifieker zouden kunnen definiëren.
- De geel gearceerde systemen zijn de zogenaamde registratiesystemen. Deze systemen kunnen bijvoorbeeld een database delen, en wijzigingen in het databaseschema kunnen elk van deze systemen nadelig beïnvloeden – en binnen de reikwijdte van de tests vallen.
- De systemen die door de paarse lijn worden omsloten, delen mogelijk bepaalde gemeenschappelijke functionaliteit of infrastructuur – misschien gebruiken ze allemaal dezelfde verzameling webservices, hetzelfde berichtensysteem of draaien ze op dezelfde server.
- De blauwe stippellijn geeft een gebruikersreis aan die gebruikmaakt van de systemen die door de lijn met elkaar zijn verbonden. Misschien is de gebruikersreis gewijzigd en ligt onze focus op de consistentie en nauwkeurigheid van de gegevensstroom tussen deze systemen.
Een model kan laten zien wat binnen de reikwijdte van de tests valt, maar net zo belangrijk is dat het ook laat zien wat erbuiten valt.
Een model helpt de reikwijdte van een test te definiëren en deze ook aan belanghebbenden uit te leggen in termen die zij begrijpen, waarderen en (hopelijk) goedkeuren.
Wanneer we een model gebruiken om de reikwijdte te definiëren, bepaalt het model het gebied en identificeren de items binnen de reikwijdte de plaatsen die we van plan zijn te verkennen en te testen.
De testdekking beheren
Het meten van de testdekking kan helpen om testen beheersbaarder te maken. Als we geen idee hebben van de dekking, kunnen we mogelijk geen antwoord geven op vragen als: ‘wat is er getest?’, ‘wat is er niet getest?’, ‘zijn we al klaar?’, ‘hoeveel tests zijn er nog?’ Dit is vooral lastig voor een testmanager.
De dekking die we willen bereiken, is de logische volgende stap zodra de reikwijdte is gedefinieerd.
We gebruiken het model voor de reikwijdte om de plaatsen te definiëren waar we zullen testen. Ons dekkingsmodel vertelt belanghebbenden hoe grondig we van plan zijn op die plaatsen te testen.
Testmodellen en dekkingsmetingen kunnen worden gebruikt om kwantitatieve of kwalitatieve doelstellingen voor het ontwerpen en uitvoeren van tests te definiëren. In verschillende mate kunnen we dergelijke doelstellingen gebruiken om te plannen en ramingen te maken. We kunnen ook de voortgang meten en conclusies trekken over de grondigheid of volledigheid van de tests die we hebben gepland of uitgevoerd. We moeten echter zeer voorzichtig zijn met kwantitatieve dekkingsmetingen of percentages die we gebruiken.
Een dekkingsmeting (gebaseerd op een formeel testmodel) kan objectief worden berekend, maar er bestaat geen formule of wet die zegt dat X-dekking Y-kwaliteit of Z-vertrouwen betekent. Alle dekkingsmetingen geven slechts indirecte, kwalitatieve en subjectieve inzichten in de grondigheid of volledigheid van onze tests. Er bestaat geen betekenisvolle relatie tussen de dekking en de kwaliteit of aanvaardbaarheid van systemen.
Kwantitatieve dekkingsdoelstellingen worden vaak gebruikt om exitcriteria voor het voltooien van tests te definiëren, maar deze criteria zijn arbitrair. Een strengere dekkingsdoelstelling kan twee keer zoveel items opleveren om te dekken. Twee keer zoveel tests die twee keer zoveel kosten, maken een systeem echter niet twee keer zo grondig getest of twee keer zo betrouwbaar. Een dergelijke interpretatie is zinloos en dwaas.
Soms kunnen de formele modellen die worden gebruikt om een systeem te definiëren en te bouwen, aan testers worden opgelegd zodat zij deze kunnen gebruiken om dekkingsdoelen te definiëren. Op andere momenten beschikken testers mogelijk over weinig documentatie en moeten zij zelf modellen bedenken. De keuze van een testmodel en dekkingsdoel is enigszins arbitrair en subjectief. Bijgevolg kunnen informele testmodellen en dekkingsmetingen net zo nuttig zijn als gevestigde, formele modellen.
Snelle oefening in modelvorming
Een korte oefening om af te sluiten. Schets in de volgende voorbeelden hoe je denkt dat het model eruit zou kunnen zien – alleen de vorm ervan – als afbeelding/diagram, tabel of lijst:
- Gebruikers zijn bezorgd over de trajecten van begin tot eind in het systeem.
- Een berichtenservice kan zich in vier toestanden bevinden: uitgeschakeld, actief, aan het opstarten en aan het afsluiten.
- Een rekenmachine voor verzekeringspremies heeft 40 invoerwaarden die gezamenlijk van invloed zijn op de berekening; tussen sommige invoerwaarden bestaan afhankelijkheden.
- Een extractie/transformatie/laadproces heeft zeven fasen. Na de extractie verwerpt elke fase records, stuurt ze naar een bestand voor twijfelgevallen of transformeert ze en geeft ze door aan de volgende fase. De laatste fase is een laadproces dat afwijzingen verwerkt. Test of alle geëxtraheerde records zijn verantwoord.
Schrijf je in voor de nieuwsbrief van The CTO Club voor meer inzichten op het gebied van testen!
