In het kort: Een regressietest controleert na een wijziging of alles wat al werkte nog steeds werkt. Draai hem na je eigen wijzigingen en na updates die je niet zelf doet. Automatiseer eerst de stabiele checks die er het meest toe doen. De meeste regressietests vallen stil omdat niemand ze bijhoudt, dus regel dat onderhoud vanaf het begin.

Op 8 september bracht Microsoft de maandelijkse beveiligingsupdate voor Windows uit. Op de eigen supportpagina staan inmiddels vijf bekende problemen bij die update. Remote Desktop-verbindingen vielen na een paar minuten weg. Op sommige computers konden mensen niet meer inloggen met hun bedrijfsaccount. Microsoft bracht op 14 en 22 september herstelupdates uit. Voor één probleem was er eind september nog alleen een workaround.

Jouw software draait op zulke updates. Daarvoor is de regressietest: hij laat zien dat wat gisteren werkte, vandaag nog steeds werkt.

Wat is een regressietest?

Een regressietest is een test die je na een wijziging opnieuw draait, om te controleren of bestaande functies nog goed werken. Een regressie is een fout in iets dat eerst wel goed ging. De wijziging kan van alles zijn: een nieuwe functie, een bugfix, opgeschoonde code, een nieuwe versie van een bibliotheek of een update van het besturingssysteem. Het ISTQB is de internationale organisatie voor softwaretesten. Het beschrijft regressietesten als testen dat zoekt naar nieuwe fouten in de delen van de software die niet zijn veranderd. Je test dus alles rondom de wijziging. Neem een webwinkel die een nieuwe betaalmethode toevoegt. De regressietest kijkt of inloggen, zoeken, het winkelmandje en de oude betaalmethoden nog werken. Een hertest is iets anders. Die controleert of één specifieke bug is opgelost. Een regressietest controleert of die oplossing niets anders kapot heeft gemaakt.

Een eenvoudig voorbeeld: de test logt in als testklant, zet twee producten in het winkelmandje, vult een kortingscode in en controleert het totaalbedrag. Klopt het bedrag ineens niet meer, dan moet iemand kijken wat er is veranderd.

Wanneer draai je een regressietest?

Draai een regressietest na elke wijziging die bestaande functies kan raken. Dat zijn in de eerste plaats je eigen wijzigingen: nieuwe functies, bugfixes en aanpassingen in de code. Het zijn ook wijzigingen die je niet zelf doet. Besturingssystemen en browsers krijgen elke maand updates. Cloudplatforms hebben hun eigen ritme. Salesforce brengt bijvoorbeeld drie keer per jaar nieuwe functies uit, in het voorjaar, de zomer en de winter, en elke release vraagt om een eigen testronde voor Salesforce. Elk van die updates kan een proces breken waar je team al maanden niet aan heeft gezeten. De Windows-update van september is een voorbeeld: ook teams die die week niets opleverden, konden problemen krijgen met Remote Desktop. Een handige regel: is er iets in je systeem veranderd, dan draait de regressietest voordat je gebruikers het merken.

Voor de meeste teams komt dat neer op drie momenten:

• Na elke build of merge: een korte set met de belangrijkste checks.
• Voor elke release: de volledige set.
• Na updates die je niet zelf doet: patches van het besturingssysteem, nieuwe browserversies, platformreleases en nieuwe versies van bibliotheken.

Moet je regressietesten automatiseren?

Ja, voor het grootste deel. Een regressietest herhaalt elke keer dezelfde stappen, en daar is een computer goed in. Geautomatiseerde tests draaien elke nacht, terwijl je team slaapt. Ze slaan nooit een stap over omdat het vrijdagmiddag is. Handmatig regressietesten gaat in het begin prima, maar het groeit mee met elke release. Na een jaar kost één handmatige ronde al snel dagen testtijd. Testautomatisering kost ook iets. Tests moeten mee veranderen als de applicatie verandert. Slecht gebouwde tests falen zonder duidelijke reden. Dat noem je flaky tests, en ze maken het vertrouwen snel kapot. Laat mensen daarom het werk doen waar oordeel voor nodig is: verkennend testen, nieuwe functies, gebruiksgemak en alles wat visueel is. De beste aanpak is een mix: de computer controleert wat nooit mag breken, en je testers zoeken naar wat nog niemand had bedacht.

Een eenvoudige vuistregel: automatiseer een check als hij vaak draait, het proces stabiel is en een fout pijn doet. Houd hem handmatig als de functie elke sprint verandert of als je de check maar één keer per jaar doet.

Wat zet je als eerste in je regressietestset?

Begin klein, en begin bij wat de meeste pijn doet. Een eerste set van 10 tot 20 tests is genoeg, als ze de processen dekken waar je bedrijf niet zonder kan. Een kleine set die elke nacht draait en die iedereen vertrouwt, is meer waard dan 500 tests die niemand leest. Bouw hem in deze volgorde op:

1. Maak een lijst van je belangrijkste processen, zoals inloggen, een bestelling plaatsen of een aanvraag goedkeuren. Zet ze op volgorde van schade als ze falen.
2. Automatiseer eerst de bovenste vijf, van begin tot eind.
3. Voeg de bugs toe die al eens terugkwamen, en voortaan een test voor elke bug die in productie terechtkomt.
4. Voeg de koppelingen toe die het vaakst breken, zoals betaalproviders, inlogsystemen of data-exports.
5. Laat de set op vaste tijden draaien, zodat het niet afhangt van iemand die eraan denkt. Breid hem daarna stap voor stap uit.

Weet je nog niet goed wat je überhaupt moet testen? Begin dan met een teststrategie voordat je iets automatiseert.

Waarom valt een regressietest na een jaar stil?

De meeste regressietests gaan door dezelfde fase. Een snelle start, de dekking groeit en de tests vinden echte bugs. Dan stopt de groei, een paar maanden later. Oude tests repareren kost de tijd die eerst naar nieuwe tests ging. Iemand zet een kapotte test “even” uit, en niemand komt er nog op terug. In gesprekken over testautomatisering horen we iets vergelijkbaars. “Dat hebben we al geregeld” betekent vaak dat één persoon het meeste heeft gebouwd. Niemand anders begrijpt de opzet, en onderhoud is nooit ingepland. Vertrekt die persoon, dan bestaat de testset nog, maar niemand draait hem en niemand vertrouwt hem. Meestal ligt het aan eigenaarschap. Behandel een regressietestset als een klein product. Er moet iemand zijn die kapotte tests nog dezelfde week repareert, verouderde tests opruimt en uitlegt wat de resultaten betekenen.

Wat betekent dit voor je team?

Begin met drie vragen. Welke processen mogen nooit breken? Draai je een regressietest na updates die je niet zelf deed? En wie repareert deze week een kapotte test? Zijn de antwoorden niet duidelijk, begin dan daar, voordat je een nieuwe tool koopt.

Daar past Nekst. Met Test Automation as a Service bouwen en draaien we je geautomatiseerde regressietest, samen met je team. Wij draaien de regressietest, jij beslist wat live gaat. We halen tot 70% van het handmatige regressietesten weg. Je tests draaien elke nacht, en wij houden ze draaiend. Geen project dat stilvalt zodra degene die het bouwde weg is. Zo krijgen je testers weer tijd voor het werk waar ze echt voor nodig zijn.

We beginnen door in de eerste dagen met je team de huidige testaanpak door te lopen en de knelpunten te vinden. Binnen de eerste maand staat er een werkend proof of concept. We bouwen, documenteren en onderhouden de testset, zodat hij van jou blijft.

Dat deden we bijvoorbeeld voor MyTerminal, het online logistieke platform van Hutchison Ports ECT Rotterdam. Het platform groeide in één jaar met 400% klanten en bracht in hoog tempo nieuwe functies uit. Ana Duško van MyTerminal zei daarover: “Good test automation, set up by Nekst IT, has contributed to a continuous performance and a high speed of release.”

Veelgestelde vragen

Wat is het verschil tussen een regressietest en een acceptatietest?

Een acceptatietest controleert of een nieuwe functie doet wat de business vroeg. Meestal doen gebruikers uit de organisatie die test. Een regressietest controleert of bestaande functies na een wijziging nog werken. Je hebt ze allebei nodig: de acceptatietest voor wat nieuw is, de regressietest voor wat al werkte.

Hoe vaak draai je een regressietest?

Draai een korte set bij elke build en de volledige set voor elke release. Draai hem ook na updates waar je geen invloed op hebt, zoals Windows-patches of platformreleases. Voor de meeste teams is een nachtelijke run een goed uitgangspunt.

Wat is een voorbeeld van een regressietest?

Een webwinkel voegt een nieuwe betaalmethode toe. De regressietest controleert daarna of inloggen, zoeken, het winkelmandje en de bestaande betaalmethoden nog precies zo werken als voor de wijziging.

Kun je regressietesten helemaal automatiseren?

Niet helemaal, en dat moet je ook niet willen. Automatiseer de checks die stabiel zijn, vaak terugkomen en er echt toe doen. Laat verkennend testen en visuele beoordeling bij mensen. Veel teams eindigen met een grote geautomatiseerde basis en een korte handmatige check.