Misschien komt het bekend voor: je team voert aanpassingen door in de software. Je gaat naar produktie. Je krijgt direct een probleem gemeld bij de helpdesk door een klant. Je manager roept: “hoe kan dat nou? Is er dan niet getest?”. Het team in verweer: “ja, maar we hebben ook geen goede geautomatiseerde regressietest en we kunnen niet alles met de hand testen”.
Oplossing: we gaan de regressietest uitbreiden en automatiseren. Manager blij, team blij.
En toch zijn er 2 fundamentale problemen met de regressietest als fenomeen:
Een analogie ter verduidelijking:
Je brengt je auto naar de garage voor het vervangen van de motorolie. Aan het einde van de dag haal je je auto weer op en krijg je de rekening. Deze rekening bedraagt €1750 !!
Furieus schreeuw je naar de garagehouder hoe dat toch mogelijk is.
De garagehouder stelt het volgende:
We hebben uw motorolie vervangen en gecontroleerd of we dat goed gedaan hebben door te controleren of de olie er aan de onderkant niet uitloopt en we hebben ook gecontroleerd middels de peilstok of er voldoende olie aanwezig is. Echter…
Omdat we geen idee hebben wat het wisselen van de motorolie heeft gedaan met de overige onderdelen van de auto hebben we een volledige test gedaan van de stuurinrichting, de wielophanging, de remmen, de electronica etc etc. Dat heeft in totaal 6 uur geduurd. We hebben vastgesteld dat deze onderdelen prima werken en we tijdens het wisselen van de motorolie niet onbedoeld iets hebben verandert aan deze delen waardoor ze wellicht niet meer juist werken.
Vreemd? Toch is dit precies wat we doen bij een regressietest.
Dit brengt ons bij het eerste probleem van de regressietest, namelijk de definitie:
Een regressietest is een test om vast te stellen of we bij aanpassingen niet onbedoeld delen van de software hebben stukgemaakt die geen onderdeel zijn van die aanpassing. In het beste geval is een regressietest een test om vast te stellen of onze basisfunctionaliteiten (de primaire functies) van onze software nog werken na aanpassingen elders in de software.
Wat is het probleem met deze definitie?
Waarom zijn er redenen om aan te nemen dat onaangepaste delen van de software opeens niet of niet goed meer werken na een aanpassing elders (denk aan de remmen na een motorolie wissel)? Als we kijken naar de kans op potentiele schade, dan is die kans bijna nul. Waarom besteden we dan toch zo enorm veel tijd en geld aan het maken van een (geautomatiseerde) regressietest?
En dan komen we op het tweede probleem van de regressietest, namelijk de ware oorzaak van het probleem:
We hebben geen idee wat we eigenlijk precies gewijzigd hebben en wat de impact van deze wijziging is in de software. Als we dit 20 jaar geleden zouden roepen, dan zou dat nog te begrijpen zijn, anno 2022 zijn er echter zeer veel geavanceerde tools die ons kunnen helpen met het precies bepalen waar alle aanpassingen zijn gedaan en wat de impact hiervan is op de software. Op basis hiervan kan door de developer en tester samen een prima inschatting worden gemaakt wat er wel of niet geraakt wordt en wat er dan vervolgens wel of niet getest hoeft te worden op basis van de potentiele schade.
Hiermee nemen we de oorzaak van het probleem waarvoor de regressietest (een dus overbodige) oplossing is weg en kunnen we ons focussen op het toevoegen van meer waarde in plaats van het inbouwen van zekerheden achteraf omdat we eigenlijk niet precies weten wat we aan het doen zijn.
‘Regressietesten’ is onderdeel van de training Agile-United Certified Practitioner in Agile Testing. Wil je hier als software tester meer over weten of beter in worden, kijk dan op onze site.
Alain Bultink | Managing Director
[email protected]
06-15361077
Benno Kuipers | Directeur
[email protected]
06-52600438
Emilie Lamers | Directeur
[email protected]
06-15653500