Maar wat doe je dan met je regressietestscript? Een regressietest is tenslotte om vast te stellen of de delen van de applicatie die niet aangepast zouden moeten zijn, ook niet aangepast zijn. Om deze reden moet het regressietestscript, als je hem op productie uit zou voeren, altijd voor 100% slagen. In theorie tenminste. Dus volgens deze theorie moet je, als een applicatie met bugs naar productie wordt gebracht, je testscript aanpassen op deze bug. Maar daar staat tegenover: het doel van een testscript is juist om vast te stellen of je applicatie bugs bevat. De bugs je testscript inschrijven is daarmee in tegenspraak. Moet je een applicatie dan vervolgens afkeuren, omdat de bug niet meer op dezelfde manier fout gaat?
Wel of niet een bug
Om te bepalen of je je regressietestscript wel of niet aan wil passen, moet je eerst het volgende nogmaals controleren: is er echt sprake van een bug? In veel gevallen zal er eerder sprake zijn van een verbetering, meestal op het gebied van interactie. Als een gebruiker nu geen geboortedatum in kan voeren met het toetsenbord, maar wel een datum kan kiezen met de muis, is dat geen bug die naar productie gaat. Het is misschien wel een aanpassing op de eerder geformuleerde eisen.
Er is alleen sprake van een bug als de gebruiker denkt: "Dit is fout", niet als hij denkt "Dit kan beter". Stel dat een gebruiker een geboortedatum invoert op stap 1. Als hij er pas op stap 5 achterkomt dat de invoer fout was, terwijl dit al op stap 1 had gekund, is dit erg ongewenst. En ik zou als tester zeker niet aanraden om hiermee naar productie te gaan. Maar als dit toch besloten wordt, is er uiteindelijk geen sprake van een bug. De gebruiker kan de geboortedatum nog aanpassen. Een voorbeeld van een echte bug is het volgende: een gebruiker voert op stap 1 een geboortedatum invoert en deze wordt op stap 2 verkeerd getoond Ook al lijken de gevolgen minder ernstig. Ook al wordt de geboortedatum op stap 3 t/m 5 wel goed getoond. Dit is een echte bug.
Alleen bij echte fouten moet je overwegen om je regressietestscript niet aan te passen. Dit heeft alles te maken met de betrouwbaarheid van je applicatie. Als gebruiker moet je je applicatie kunnen vertrouwen. Dat is ook een van de belangrijkste redenen om een regressietest uit te voeren. Of de gebruiker na het invoeren ontzetten geïrriteerd is, omdat het invoeren erg moeilijk ging, is zeker ook het melden waard. Maar voor een regressietest van minder belang.
Daarnaast blijven verbeteringen vaak langer open staan dan bugs. Ze vragen vaak meer tijd om te bouwen en ze krijgen vaak een lagere prioriteit. Redenen waarom ze vaak naar achteren worden geschoven. En verbeteringen hebben meestal ook meer effect op je regressietest, juist omdat ze regelmatig over interactie gaan. Als je een verkeerde geboortedatum invoert en er staat in je testscript dat de foutmelding al in stap 1 moet verschijnen, maak je je testscript een flink stuk minder bruikbaar als de echte controle pas in stap 5 plaats vindt. Terwijl je deze controle toch echt wil testen. Want een verkeerde geboortedatum die geaccepteerd wordt, kan ernstige gevolgen hebben.
Wel of niet aanpassen
Bij een echte bug is de basisregel: pas je regressietestscript niet aan. Een bug moet opgelost worden en een steeds falende regressietest is een goed middel om daaraan te blijven denken. En een middel om de organisatie ervan te overtuigen dat de prioriteiten meer naar bugfixen zouden moeten verschuiven.
Maar wanneer pas je je regressietest dan wel aan? Tijd is hierbij de belangrijkste factor. Als een bug over twee weken wordt opgelost, pas je de regressietest niet aan. Maar als nu al vast staat dat de bug pas over een jaar wordt opgelost, pas je de regressietest wel aan. Want een jaar lang een falende regressietest maakt van een regressietest een onbetrouwbaar testhulpmiddel. Voor mij ligt de grens ongeveer op twee maanden wachten op een bugfix, maar deze grens kan per bedrijf en per project verschillen.
Daarnaast is van belang in hoeverre de bug de betrouwbaarheid van je regressietest aantast. Als een vrouw op een scherm plotseling met "Meneer" wordt aangesproken, kan de bug rustig twee maanden in je regressietest blijven. Je regressietest blijft voor de rest betrouwbaar. Maar als de keuze voor het geboorteland "Griekenland" het opslaan onmogelijk maakt, kan je ook het opslaan van de andere gegevens niet meer testen. Dan zal je eerder een ander land moeten kiezen.
Hoe aanpassen
Van belang is dat je nooit de fouten in je regressietest toevoegt. Houd de volgende regel aan en deel deze ook mee aan je team en andere belanghebbende: bij fouten worden de falende controles uit de regressietest verwijderd. Ze worden niet aangepast naar de foutsituatie. Zodra de bug is opgelost, wordt de controle weer toegevoegd. Dit voorkomt dat je regressietest faalt, omdat een bug opgelost is. Of omdat een fout de volgende keer net iets anders fout gaat. Om deze reden kan het zeker verstandig zijn om een openstaande buglijst bij te houden. Bij deze buglijst kan je dan noteren welke controles je opnieuw toe moet voegen aan de regressietest, om te voorkomen dat je de aanpassing vergeet.
Samenvatting
Hoe ga je om met een regressietest bij bugs? Je bepaalt of er echt sprake is van een bug: ziet de gebruiker het als een fout of als iets wat beter kan werken. Afhankelijk van het tijdstip waarop de bug opgelost gaat worden en het effect op de betrouwbaarheid van de regressietest bepaal je of er een aanpassing nodig is. En als je besluit de regressietest aan te passen, verwijder je de controles die falen. Op deze wijze vind je een evenwicht tussen "altijd blijven testen" en "trouw zijn aan je testprincipes".
