Navigeer naar: #BLOG 1 #BLOG 2 #BLOG 3 #BLOG 5 #BLOG 6
Blog 4: Testautomatisering, “Alles automatiseren?”
Binnen de transitie van veel organisaties naar een Agile of DevOps IT-proces wordt vaak gezegd: “Automatiseer alles!” Voor testen vertaalt dit adagium zich naar “automatiseer alle tests!” Deze kernachtige uitspraak klinkt aanlokkelijk in een agile omgeving met korte doorlooptijden, want je lijkt af te zijn van het trage, handmatige testen. We zien dan ook veel teams die inzetten op testautomatisering, en vacatureteksten voor testers staan vol met termen die gerelateerd zijn aan testautomatisering. In de praktijk blijkt echter dat het ideaalbeeld rond testautomatisering niet overeenkomt met de werkelijkheid. We zien dat ondanks de vele geautomatiseerde tests er nog steeds veel problemen in productie zijn. We merken dat teams krakend vastlopen in het onderhoud van de steeds weer omvallende geautomatiseerde tests of dat de geautomatiseerde tests een doorlooptijd hebben die onwenselijk lang is. Dit duidt in de meeste gevallen op een gebrekkige teststrategie.
Testautomatisering wordt vaak gezien als een doel. Dit is incorrect. We moeten ons bij elke automatiseringsimplementatie realiseren dat het slechts gaat om een middel. Testautomatisering ofwel geautomatiseerde tests vinden geen bugs. Testers doen dat, omdat zij in staat zijn het systeem zodanig uit te dagen dat het systeem al haar geheimen prijsgeeft. Dat vraagt bij nieuwe en aangepaste functionaliteit in eerste instantie om gedegen, exploratory testen (onderzoeken), al dan niet ondersteund met tools, waarbij de tests voortkomen uit een teststrategie. Voor dit alles zijn goede testvaardigheden nodig en dit zijn andere vaardigheden dan de vaak gevraagde testautomatiseringsvaardigheden. Uit het exploratory onderzoek ontstaat een beeld van een testset die handig is om in de toekomst te gebruiken om te kunnen beoordelen of de functionaliteit nog werkt: de regressietest. Deze regressietest vervolgens automatiseren is een goed idee. Je houdt dan als tester je handen en hoofd vrij voor nieuw onderzoek naar de nieuwe functionaliteit in de volgende iteratie. Toch is ook dit niet triviaal. Je moet nog wel goed blijven nadenken over de teststrategie voor die regressietest. Op welk niveau zet je de tests in? Er zijn namelijk legio opties, bijvoorbeeld units, integratie, component, API, GUI, etc. Het maken van een goede weloverwogen keuze op welk niveau je de regressietest inzet, voorkomt terugkerend en toenemend onderhoud aan omvallende tests.
Last but not least: testautomatisering is het schrijven van code. Hiervoor gelden alle regels die ook gelden voor de bouw van applicaties. Dus denk na over een onderhoudbare architectuur. Gebruik design patterns, refactor vaak en vergeet niet: test je code. Op automatisering wil je kunnen vertrouwen! Je moet zeker zijn dat een test alleen faalt als het gedrag dat getest wordt niet goed is. Je weet dit alleen zeker door minimaal één keer aan te tonen dat de test faalt als je dat verwacht. Ook dit is iets dat thuishoort in een goede teststrategie.
Lees hier blog 5: Architectuur, niet aanraken. Levensgevaarlijk!
Op donderdag 21 september behandelden we tijdens het Polteq webinar het toenemende belang van kwaliteit als onderscheidende factor bij softwareontwikkeling. Tijdens deze online lunch-presentatie gingen we in op het concept testprocesverbetering, methodieken om mogelijke verbeteringen te vinden en te adresseren en hoe je testprocesverbetering integraal kunt inbedden voor continue verbetering.
