Als manager kun je herkennen of developers écht testen door verder te kijken dan hun eigen verklaringen. Concrete signalen zoals testresultaten, gedekte codepaden en geautomatiseerde testrapportages geven een betrouwbaarder beeld dan een mondelinge bevestiging. In dit artikel beantwoorden we de meest gestelde vragen over testverantwoordelijkheid in agile teams, zodat jij als manager grip houdt zonder te micromanagen. Heb je vragen over jouw specifieke situatie? Neem gerust contact op, we helpen je graag verder.
Welke signalen verraden dat developers testwerk overslaan?
Developers die niet testen laten dat zelden expliciet zien, maar de signalen zijn er wel degelijk. Denk aan een hoog aantal bugs dat pas in acceptatietesten of productie opduikt, een codebasis zonder aantoonbare testhistorie, of sprints waarin testactiviteiten altijd als laatste worden afgekapt wanneer de deadline nadert.
Andere veelzeggende signalen zijn:
- Testbestanden die nauwelijks worden bijgewerkt terwijl de productiecode wekelijks groeit
- Geen falende tests in de CI/CD-pipeline, terwijl er wel regelmatig bugs worden gerapporteerd
- Developers die niet kunnen uitleggen welke scenario’s hun tests afdekken
- Testdekking die op papier hoog is, maar waarbij alle tests triviale paden controleren
- Bugfixes zonder bijbehorende regressietests die herhaling voorkomen
Het patroon dat het meest voorkomt is dat developers wel unit tests schrijven, maar alleen voor de eenvoudige, al werkende code. De complexe bedrijfslogica, foutafhandeling en randgevallen blijven ongetest. Als manager zie je dat terug in productieproblemen die telkens op onverwachte plekken opduiken.
Wat is het verschil tussen testdekking en testkwaliteit?
Testdekking is een kwantitatieve maatstaf die aangeeft welk percentage van de code door tests wordt uitgevoerd. Testkwaliteit is een kwalitatieve beoordeling van of die tests daadwerkelijk zinvolle scenario’s controleren en echte fouten zouden opsporen. Een hoge testdekking garandeert geen testkwaliteit.
Dit onderscheid is cruciaal voor managers die softwaretesten willen controleren. Een team kan een dekking van 90% rapporteren terwijl de tests in de praktijk weinig waarde hebben. Dit gebeurt wanneer tests geen assertions bevatten die echt iets verifiëren, wanneer alleen de happy path wordt getest, of wanneer tests zo zijn geschreven dat ze altijd slagen ongeacht de uitkomst.
Wat zegt hoge testdekking wel en niet?
Hoge testdekking zegt dat bepaalde coderegels zijn uitgevoerd tijdens het testen. Het zegt niets over of de verwachte uitkomsten worden gecontroleerd, of foutscenario’s worden afgedekt, of de integratie tussen componenten klopt. Het is een nuttig startpunt, maar nooit een eindoordeel.
Hoe herken je kwalitatieve tests?
Kwalitatieve tests falen wanneer de code kapot gaat, beschrijven het verwachte gedrag in begrijpelijke testnamen, dekken zowel normale als uitzonderlijke situaties af, en worden onderhouden als de productiecode verandert. Als een test nooit faalt in de loop van maanden, is dat zelden goed nieuws.
Hoe kun je als manager testpraktijken zichtbaar maken zonder micromanagen?
Testpraktijken zichtbaar maken zonder te micromanagen doe je door structurele transparantie in te bouwen via dashboards, sprintreviews en teamafspraken, niet door individueel werk te controleren. De focus ligt op het systeem, niet op de persoon.
Praktische aanpakken die werken in agile teams:
- Definition of Done uitbreiden: Maak testcriteria expliciet onderdeel van de acceptatievoorwaarden per story. Een story is pas klaar als de tests zijn geschreven, draaien en slagen.
- Testresultaten zichtbaar maken in sprintreviews: Vraag teams om testrapportages te presenteren als onderdeel van de demomomenten, niet als apart technisch detail.
- Testdekking opnemen in teamdashboards: Niet als afrekenmechanisme, maar als gedeelde kwaliteitsindicator die het team zelf bespreekt.
- Testverantwoordelijkheid beleggen bij het team: Geef developers eigenaarschap over de teststrategie in plaats van controle van bovenaf op te leggen.
De sleutel is dat je als manager vragen stelt in plaats van oordelen velt. Vragen als “Welke scenario’s zijn afgedekt?” of “Wat zou er fout kunnen gaan dat we nog niet testen?” creëren bewustzijn zonder wantrouwen.
Welke tools laten zien of tests echt worden uitgevoerd?
Tools die aantonen of tests daadwerkelijk worden uitgevoerd zijn onder andere CI/CD-platformen zoals Jenkins, GitLab CI of GitHub Actions, testdekkingtools zoals JaCoCo, Istanbul of Coverage.py, en testrapportagetools zoals Allure of ReportPortal. Deze tools maken testuitvoering objectief en traceerbaar.
Elke tool heeft een eigen focus:
- CI/CD-pipelines tonen of tests automatisch draaien bij elke codewijziging en of de build slaagt of faalt
- Testdekkingtools laten zien welke coderegels en branches zijn geraakt tijdens testuitvoering
- Testrapportageplatforms geven historisch inzicht in testtrends, faalpatronen en regressies over tijd
- Mutatietestentools zoals PIT of Stryker controleren of tests ook echt falen als de code bewust kapot wordt gemaakt
Mutatietesten is een bijzonder krachtige techniek om testkwaliteit te meten. De tool past kleine wijzigingen aan in de productiecode en controleert of de bestaande tests deze mutaties opvangen. Als dat niet het geval is, zijn de tests niet effectief genoeg, ongeacht de gerapporteerde dekking.
Voor teams die starten met testautomatisering of hun tooling willen verbeteren, bieden wij ondersteuning via onze zorgeloze teststrategie aanpak, waarbij we toolkeuze en implementatie afstemmen op jouw specifieke context.
Wanneer moet je een externe testaanpak of testexpert inschakelen?
Een externe testaanpak of testexpert inschakelen is zinvol wanneer het interne team structureel dezelfde soort bugs mist, wanneer testverantwoordelijkheid onduidelijk is verdeeld, of wanneer de organisatie wil overstappen naar een professionele teststrategie maar de kennis daarvoor intern ontbreekt.
Concrete situaties die om externe expertise vragen:
- Productie-incidenten die telkens teruggrijpen op problemen die tests hadden moeten opvangen
- Teams die wel willen testen maar niet weten hoe ze dat structureel moeten aanpakken in een agile omgeving
- Organisaties die performancetesten, securitytesten of mobiel testen willen toevoegen aan hun aanpak
- Situaties waarbij objectiviteit nodig is, bijvoorbeeld bij een audit of bij het opzetten van een nieuwe teststrategie
- Teams die willen groeien in testautomatisering maar vastlopen op toolkeuze of architectuur
Een externe testexpert brengt niet alleen technische kennis mee, maar ook een frisse blik op blinde vlekken die intern zijn ontstaan. Bovendien kan een expert de brug slaan tussen management en ontwikkelteams over wat haalbare en zinvolle testkwaliteit is, iets wat intern regelmatig tot discussie leidt.
Wil je weten of jouw team écht test en hoe je dat als manager structureel kunt verbeteren? Neem contact op en we bespreken samen wat de beste aanpak is voor jouw organisatie.
Veelgestelde vragen
Hoe vaak zou ik als manager testresultaten moeten bekijken?
Een wekelijkse check op teamniveau is voor de meeste agile teams voldoende, bij voorkeur als vast onderdeel van de sprintreview of een kort kwaliteitsoverleg. Het gaat er niet om dat je elke dag in dashboards duikt, maar dat testresultaten een structureel gespreksonderwerp worden. Trends over meerdere sprints zijn vaak veelzeggender dan één momentopname.
Wat doe ik als mijn team weerstand biedt tegen meer testverantwoordelijkheid?
Weerstand tegen testen komt vaak voort uit tijdsdruk, onduidelijke verwachtingen of een gevoel van wantrouwen. Begin met het gesprek aan te gaan over waarom testen waardevol is voor het team zelf, niet alleen voor management, en betrek developers actief bij het opstellen van de Definition of Done. Zorg er ook voor dat er ruimte in de sprint is voor testwerk; als testen structureel wordt weggepland door deadlines, lost geen enkel beleid dat op.
Welk percentage testdekking is een realistisch minimaal doel voor mijn team?
Er bestaat geen universeel ‘goed’ percentage, maar een dekking van 70-80% op unit- en integratieniveau wordt in veel professionele teams als een gezonde ondergrens beschouwd. Belangrijker dan het getal is wát er gedekt wordt: kritieke bedrijfslogica, foutafhandeling en veelgebruikte paden verdienen prioriteit boven triviale getters en setters. Bespreek met je team welke delen van de codebase het hoogste risico dragen en zorg dat die aantoonbaar goed gedekt zijn.
Hoe voorkom ik dat testautomatisering een papieren tijger wordt?
Testautomatisering wordt een papieren tijger wanneer tests wel bestaan maar nooit worden uitgevoerd, onderhouden of serieus genomen bij falen. Koppel je testsuites altijd aan de CI/CD-pipeline zodat een falende test automatisch de build blokkeert, en behandel een falende test als een bug die direct aandacht verdient. Maak het onderhouden van tests een expliciet onderdeel van elke story, niet een optionele nabewerking.
Wat is het verschil tussen een tester in het team en een developer die test?
Een dedicated tester brengt een onafhankelijke, kritische blik mee en heeft vaak meer breedte in testtechnieken zoals exploratory testing, performancetesten en testontwerp. Een developer die test heeft diepgaande kennis van de code en kan unit- en integratietests efficiënter schrijven, maar loopt het risico zijn eigen aannames mee te nemen. In moderne agile teams vullen beide rollen elkaar aan: developers zijn verantwoordelijk voor technische testen, terwijl een tester of SDET de bredere teststrategie bewaakt en aanvult.
Hoe ga ik om met een team dat claimt dat hun applicatie 'te complex is om te automatiseren'?
Dit argument is zelden volledig waar, maar wijst vaak op een reëel probleem: de codebase is mogelijk slecht gestructureerd voor testbaarheid, of het team mist de kennis om de juiste testaanpak te kiezen. Begin met het identificeren van de specifieke obstakels, zoals tightly coupled code, externe afhankelijkheden of ontbrekende interfaces. In veel gevallen is een combinatie van refactoring voor testbaarheid en een pragmatische testpiramide-aanpak voldoende om alsnog tot zinvolle automatisering te komen.
Hoe betrek ik de product owner bij testverantwoordelijkheid zonder technische details te hoeven uitleggen?
Vertaal testresultaten naar zakelijke risico’s in plaats van technische metrics: een lage testdekking op het betalingsproces betekent een verhoogd risico op productiefouten in de meest kritieke gebruikersflow. Betrek de product owner bij het prioriteren van welke user stories extra testaandacht verdienen op basis van bedrijfsimpact. Zo wordt testen een gezamenlijke verantwoordelijkheid van het hele team, in plaats van een technisch detail dat alleen developers aangaat.