Regressietesten

Regressietesten is een vorm van softwaretesten met als doel de controle dat alle functionaliteiten na een wijziging nog steeds werken als voorheen. Het regressietesten richt zich niet zozeer op de nieuwe functionaliteiten, maar meer op het behoud van de correcte werking van de functionaliteiten die altijd al bestonden. Noot: in dit artikel wordt gebruikgemaakt van Engelse termen, zoals deze ook bij het regressietesten worden gebruikt.

Een introductie op regressietesten

Regressietesten is niet eenvoudig, er komt namelijk heel veel bij kijken en er zijn heel veel aspecten die een invloed uitoefenen. Met het regressietesten moet je goed nadenken over de aspecten die allemaal een rol (kunnen) spelen. Je zult zien dat je hier vaak op moet anticiperen, maar ook dat je te maken krijgt met voortschrijdend inzicht (je kunt namelijk niet in de toekomst kijken).

Tijdens het regressietesten komen vaak zaken naar boven die erg belangrijk zijn voor het informatiesysteem. Soms toont het juist de zwakheden van een systeem aan. Het belangrijkste aan regressietesten is dat je een set van testen schrijft die van tijd tot tijd te herhalen valt en de belangrijkste checks bevat.

De basis en het testobject

Er zijn natuurlijk verschillende systemen, Operating Systemen, platforms of type informatiesystemen waar een regressietest op uitgevoerd kan worden. Eén van de moeilijkere vormen is de regressietesten op het image van een Operating Systeem. Op een testobject kunnen modules of applicaties worden verwijderd of toegevoegd. Vaak beïnvloeden ze elkaar en is er samenhang. Dit maakt het moeilijk om te doorgronden welke neveneffecten dit kan hebben. Het is zaak om goed te onderzoeken en geïnformeerd te raken over alle samenhang en effecten die er kunnen spelen.

De regressietest richt zich niet op de in-depth functionaliteiten van die module of het specifieke programma, maar richt zich met name op het blijven functioneren van het overkoepelende geheel. De functionele aspecten zijn in eerdere, voorgaande testfases reeds geverifieerd op de correcte werking.

Het onderhouden van een regressietest-set

Het onderhouden van een regressietest-set gaat als volgt. Wanneer er testen worden uitgevoerd voor een applicatie (of module, programma of policy) op een bepaalde build versie om te bepalen of de werking correct is, zal dat gedaan worden aan de hand van requirements waarop testgevallen gebaseerd worden. (Een selectie van) deze (meest essentiële) testgevallen wordt overgenomen in de regressietest-set. Niet alles, want dat zou de regressietest-set te groot maken qua doorlooptijd.

Waar moeten de testgevallen dan aan voldoen?

Aan te bevelen is:

• De testcases testen op high-level niveau de correcte werking.
• De testcases hebben een hele hoge dekking (met weinig verificatieslagen worden zo veel mogelijk requirements afgedekt).
• De testcases richten zich op belangrijke aspecten en grote risico's.
• De testcases richten zich op essentiële zaken ("zit de stekker in het stopcontact").
• De testcases richten zich niet op de technische of functionele details.
• De testcases zorgen ervoor dat er een zo goed mogelijk en compleet mogelijk beeld ontstaat over wat er goed gaat en wat eventueel minder.

Dit is niet de enige manier waarop aanwas van testgevallen voor de regressietest-set kan gebeuren. Er kunnen ook fouten optreden in productie die nieuwe of verbeterde testgevallen (voor de regressietest-set) vereisen. Er kunnen aanbevelingen of wensen (om verschillende redenen) voor meer diepgang op een onderdeel van de build voortkomen. Deze zullen dan worden opgepakt en de regressietest zal moeten worden verbeterd of aangevuld.

Lees verder

• De termen 'quality assurance' vs 'software testen' uitgelegd
• Mijn visie op: de moeilijke aspecten in het software testen
• Testmanagement en -coördinatie
• Uitleg over softwaretest-rollen