Alle IT-kennis onder één wereldwijd dak
Werken bij de beste IT dienstverlener van Nederland?
Resultaat door passie voor IT
Start typing keywords to search the site. Press enter to submit.
Generative AI
Cloud
Testing
Artificial intelligence
Security
September 11, 2024
In maart kwam het Continuous Testing Report (CTR) 2019 uit. Ik heb dit met veel interesse gelezen. Een paar zaken vielen mij op. Ondanks dat organisaties afgelopen jaren veel hebben geïnvesteerd in het automatiseren van testactiviteiten, blijft dit nog altijd een grote uitdaging. Vooral het behalen van voldoende testdekking blijkt een probleem. Alleen focus op automatisering is dus niet de oplossing. Aandacht voor de testaanpak blijft ook essentieel.
Mijn ervaring als Agile Quality Coach is dat veel organisaties die de stap hebben gemaakt naar Agile werken, het test- en QA-vakmanschap hierin niet hebben meegenomen. Daardoor gooien ze het soms zelfs overboord – met alle gevolgen van dien. Door testen specifiek een punt van aandacht te maken, ontstaat er meer kwaliteitsbewustzijn binnen teams, oftewel een quality culture. Aangevuld met de capaciteit om dit gestructureerd te organiseren in het ontwikkelproces, leidt dit tot een verbeterde testdekking en daarmee tot meer grip op kwaliteit. Dit wordt testen dus zeker niet weer een activiteit die alleen door testers vanuit hun eigen silo wordt gedaan, maar een vast onderdeel van het hele voortbrengingsproces.
Traditioneel keken we naar de complete scope van een project. Op basis daarvan maakten we een productrisicoanalyse (PRA) en daar baseerden we de teststrategie op. Zo zorgden we voor een effectieve dekking, waarbij we de hoge risico’s zwaarder testten dan de lage risico’s. Tegenwoordig kijken we in het organiseren van de werkzaamheden een paar sprints vooruit. Op basis daarvan bepalen we de testinspanning. Met als resultaat: (automatische) testen op een beperkt stukje functionaliteit.
Het probleem is dat er dan een lappendeken aan testen ontstaat waarin de samenhang tussen functionaliteit niet wordt getest. Deze samenhang is geen onderdeel van de user story en daardoor heeft het team hier geen aandacht voor. Ook zien we regelmatig dat er geen samenhang is tussen de opgezette unit testen en de functionele testen. Hierdoor is er veel overlap:: de punten die wel worden getest worden vaak dubbel getest en de samenhang wordt juist niet getest.
Hoe lossen we dit dan op? Moeten we toch terug naar langere release-intervallen, zodat we het makkelijker kunnen plannen? Nee, zeker niet. Omdat scope variabel is en we dus niet vooraf een PRA kunnen doen over het hele product, moeten we dit op een andere manier aanpakken. De oplossing hiervoor zit in transparantie van testdekking. Dit begint al bij de requirements. Daar moeten we inzicht creëren in de samenhang tussen functionaliteiten en de gewenste toevoegingen.
Een ander deel van de oplossing is te vinden in de creatie van testen. Hierbij geldt: meten is weten. Tijd besteden aan het opzetten en zichtbaar maken van, voor het team, waardevolle metrieken betaalt zich dubbel en dwars uit. Ideaal is het als het ophalen van deze data ook geautomatiseerd gebeurt. Is dit nog niet mogelijk? Begin hier dan vooral handmatig mee. Voorbeelden van kwaliteitsmetrieken zijn bijvoorbeeld code coverage voor unittesten, maar ook: hoeveel testscripts hebben we per acceptatiecriteria of welke componenten en koppelingen raken we met onze testen.
Het verzamelen van metrieken heeft alleen waarde wanneer het team hier ook regelmatig naar kijkt en dan vooral de focus legt op trends. De betekenis van de meting moet uitgelegd kunnen worden en gekoppeld zijn aan doelstelling van het team om te verbeteren. Door structureel inzicht te creëren in de testdekking en te zoeken naar verbeteringen zal op termijn de kwaliteit van de testdekking verbeteren. Hiermee neemt de betrouwbaarheid van het geleverde product toe.
Ben je op zoek naar meer inzicht rondom testautomation en het bepalen van de juiste testdekking? Download dan het volledige Continuous Testing Report.
Download het rapport
