Dit blog-artikel is de tweede in een serie van drie, waarin we je meenemen in een aantal ontwikkelingen op het gebied van softwaretesten. Waartoe hebben deze ontwikkelingen ons geleid en welke kansen en perspectieven zien wij voor de (nabije) toekomst? Deel 1 gemist? Je vindt ‘m hier!
Het is 2018. Ons grote ICT-project loopt als een trein. Inmiddels werken er verschillende feature-teams aan de applicatie. Elk team schrijft unit-, systeem-, integratie- en acceptatietesten, die goed passen bij de context van hun werk. Deze testen worden geautomatiseerd, zodra er ook maar een aanwijzing is dat een test herhaald zou moeten kunnen worden.
Met al die verschillende testsoorten en werkwijzen ontstaat wel een nieuw probleem. Elk team heeft zijn eigen keuzes gemaakt waar het gaat om teststrategie, -tools en -frameworks. Hoewel er al heel veel testen zijn en dat aantal elke sprint gestaag meegroeit met alle nieuwe features, lijkt het inzicht in de kwaliteit paradoxaal genoeg alleen maar kleiner te worden. Een volledige regressierun van de inmiddels duizenden tests duurt geen minuten meer, maar uren. Er valt eigenlijk altijd wel wat om; soms vanwege de wijzigingen van een ander team, soms vanwege omgevingsinstabiliteit, maar soms ook om onduidelijke redenen.
Terwijl “vroeger” testen een kostbare bezigheid was en er dus heel veel nagedacht werd over een goede teststrategie, lijkt het er in ons project meer op dat als er iets geautomatiseerd kan worden dat ook gedaan wordt. En als iets geautomatiseerd is, het dan altijd belangrijk blijft. Dat het resultaat hiervan is dat onderhoud op de testset steeds duurder wordt, de overlap in dekking van tests toeneemt en de regressietest steeds langer gaat duren wordt blijkbaar voor lief genomen.
Wanneer onvoldoende is nagedacht over welke zaken hoe, waarom en wanneer (niet) getest moeten worden, ontstaan vaak situaties waar het proces terugvalt naar een proces van hokjes en hand-overs. De ‘scheidingslijnen’ vallen dan vaak op de grenzen van de testsoort: ontwikkelaars zijn verantwoordelijk voor de unittests, testers zijn verantwoordelijk voor systeem- en acceptatietests. Maar levert deze scheiding van verantwoordelijkheden binnen je team nu de meest effectieve teststrategie op?
In ons grote ICT-project schrijft de tester vooral tests tegen de UI en houdt vanwege het toenemende onderhoud steeds minder tijd over om naast het automatiseren van die controles ook nog zelf te testen. Geen van de ontwikkelaars weet hoe de geautomatiseerde end-to-end testen zijn opgebouwd en als de tester op vakantie is rijst de vraag of de release moet worden uitgesteld of dat de testen die week even kunnen worden uitgezet?
In alle trajecten waarin geautomatiseerd getest wordt, groeit de set van testgevallen mee met de hoeveelheid opgeleverde functionaliteit. Vaak treedt er ongemerkt al snel redundantie op in de aanwezige testen. Neem een front-end applicatie voor geregistreerde gebruikers. De loginfunctionaliteit zal misschien al in sprint 1 gebouwd zijn samen met een aantal tests die vaststellen dat we aan alle requirements in die story hebben voldaan. Een aantal sprints later echter zijn er tientallen nieuwe tests geschreven, die allemaal via het loginscherm door een flow heen lopen. Als de login niet werkt, vallen al deze tests om. Je kunt je afvragen hoe waardevol de login-tests uit sprint 1 nog zijn en of die waarde opweegt tegen de langere doorlooptijd en het extra onderhoud. Dit proces herhaalt zich keer op keer. Testscenario’s tonen impliciet veel meer aan dan waarvoor ze initieel misschien bedoeld waren. Maak daar gebruik van en gooi overbodige testen regelmatig weg!
Hebben we de afgelopen sprints misschien nieuwe inzichten opgedaan of functionaliteit opgeleverd die de bestaande testen zou kunnen verbeteren? Als team valt er veel te winnen door het gesprek over testen op gang te houden. Ook de product owner moet hierbij betrokken zijn: geautomatiseerde testen horen bij het product en het optimaliseren ervan op de backlog. Een snellere testset betekent sneller naar productie en dat levert business value op!
Wanneer alle teamleden elkaars kennis gaan benutten en van elkaar begrijpen wat ze doen, wordt het mogelijk de verschillende testsoorten beter op elkaar af te stemmen. Het opleveren van de juiste applicatie is niet alleen de verantwoordelijkheid van de ontwikkelaar, net zo min als het opleveren van een goede testset alleen de verantwoordelijkheid is van de testspecialist. Van ‘samen werken’ naar ‘samenwerken’ is voor veel professionals nog een hele kunst, maar wel de enige manier om de hoeveelheid dubbele en nutteloze testen te verminderen. Is het nodig functionaliteit te controleren door middel van een front-end test? Of heeft de module die de logica bevat ook een API? Ziet een tester in dat zijn testgeval in milliseconden in een unittest uitgevoerd kan worden? En wie weet was die unittest er al? Andersom is het bijzonder prettig wanneer ontwikkelaars ook meedenken over nieuwe integratie- of end-to-end testen, die horen bij de functionaliteit die opgeleverd wordt.
Met meerdere releases per dag en de steeds groter wordende testset is het steeds lastiger om continu het overzicht te bewaren van wat er op enig moment getest zou moeten worden (zeker als je met 6 teams aan een product werkt!). De stap van samen werken naar samenwerken is noodzakelijk om dit overzicht te vergroten, maar dan nog is het lastig te bepalen wat de “optimale testset” objectief gezien is. Met een traditionele testadministratie redden we dat niet meer. We zouden onze teststrategie bijna real-time moeten stroomlijnen. Volgende week nemen we je mee in onze visie op hoe dat zou kunnen.
