mijn kijk opMijn visie op: de moeilijkheid van regressietesten
Wat is er nou zo moeilijk aan regressietesten? Net zoals in vele andere disciplines in het software testen brengt ook regressietesten bepaalde valkuilen met zich mee. Het is niet altijd duidelijk wanneer je nou precies een run doet, of dit handmatige of geautomatiseerd moet gebeuren en welke testgevallen er deel uitmaken van de set. Deze principes en aspecten spelen een rol bij de bepaling van het moment van uitvoer en de grootte van de set. Het is belangrijk om kennis en begripsvorming te hebben over wat er met testgevallen kan gebeuren om het regressietesten te stroomlijnen.
Regressietesten op zich
'Regressietesten is een vorm van software testen met als doel de controle dat alle functionaliteiten na een wijziging nog steeds werken als voorheen.' Maar daarmee is natuurlijk alleen maar een introductie gegeven tot wat regressietesten inhoudt en is nog niet ingegaan op alle moeilijke aspecten die een rol kunnen spelen. Regressietesten is een hele moeilijke vorm van software testen. Dit komt omdat er rekening moet worden gehouden met minimaal drie grote aspecten namelijk: de oude functionaliteit, de nieuwe functionaliteit en de samenhang tussen beide. Regressietesten vergt zowel goede functionele en technische software testers en vaak ook nog testautomatisering als fundering.
Regressietesten en testautomatisering
Regressietesten hangt nauw samen met testautomatisering. Want veel bedrijven komen er vroeg of laat achter dat als je bepaalde testen iedere zoveel tijd moet herhalen dat het dan fantastisch zou zijn als dit geautomatiseerd zou kunnen. Daarbij moet altijd één ding scherp in de gaten worden gehouden: 'Alles geautomatiseerd testen is NIET mogelijk en dat is helaas nog wel eens iets wat sommige personen of bedrijven dreigen te vergeten. Het komt allemaal neer op het principe dat een computer niet kan denken (horen, zien of voelen) zoals een mens. Met als gevolg dat iets wat als voor ons compleet logisch is opgeschreven door een computer totaal verkeerd wordt geïnterpreteerd. De moeilijkheid hierin is dan weer om te beseffen dat de computer vaak letterlijk doet wat je van hem vraagt, alleen dat de mens het soms impliciet wat minder letterlijk had bedoeld.
Een klein (praktijk-)voorbeeld
Stel een geautomatiseerde test is geschreven waarbij het getal '7' op het scherm dient te verschijnen, deze moet bij wijze van test worden geverifieerd door de computer. Na afloop geeft de testtool aan dat de test geslaagd is. Maar bij handmatige controle blijkt dat de 7 op zijn kop geprint stond. Feitelijk gezien had de computer gelijk, er stond ook een 7, maar ja, dan op zijn kop.
Conclusie: manuele, handmatige testen door een mens blijven nodig
De moeilijkheid van regressietesten
De moeilijkheid van regressietesten zit hem in het aspect dat het altijd lastig is om te bepalen wanneer je een run van een regressietest nou precies uitvoert. Daarbij komt ook dat je precies wilt weten wat de regressietest precies omvat
(m.a.w. "Wat zit er wel in en wat zit er niet in?").
Afbeelding 1 /
Bron: Softwaretester
In afbeelding 1 is een voorbeeld geschetst van een Operating Systeem welke er een nieuw element bij krijgt. Het kan ook zijn voor een informatiesysteem welke er een nieuwe functie (feature) bij krijgt, het principe blijft hetzelfde.
De uitgangssituatie is als volgt: er bestaat een set van testgevallen en er komt een nieuwe functionaliteit bij. De nieuwe functie zorgt voor nieuwe testgevallen. Vul je deze nieuwe testgevallen aan in de bestaande set en draai je daarna de regressietest? Of, draai je eerst de regressietest en vul je daarna de testgevallen aan die de nieuwe functionaliteit nodig hebben? Dit is een groot dilemma en voor beide is wel iets te zeggen. Het lastige is alleen dat je nooit weet wat de betere keuze geweest zou zijn. Het is niet zoals met schoenen waarbij vaak geldt in het algemeen: "Gooi nooit je oude schoenen weg voordat je nieuwe hebt". Toch is de vergelijking nog niet eens zo verkeerd: Want als je je oude schoenen weggooit voordat je nieuwe hebt (dan loop je op blote voeten), krijg je dan blaren? Of … Als je de oude weggooit meteen nadat je de nieuwe aan hebt geschaft … (dan loop je op nieuwe schoenen) zitten de nieuwe schoenen dan nog krap en krijg je dan alsnog blaren?
Waar dient men zoal rekening mee te houden?
Qua regressietesten zijn er in het verband met het bovenstaande een aantal zaken waar rekening mee gehouden dient te worden.
In de eerste plaats: er bestaat een regressietestset, de set die er al lang is en misschien al wel een paar keer is uitgevoerd. Maar daarnaast komen er ook nieuwe functies bij, die een aanvulling voor de testset gaan vormen. (bijvoorbeeld de testset was eerst 100 testgevallen groot en door de nieuwe functionaliteit worden dat er 105).
Ten tweede: de verhouding tussen één requirement (eis aan de software) en een testgeval is 1:N oftewel, één requirement kan meerdere testgevallen hebben.
Een voorbeeld
Requirement: De spellingscontrole moet werken. Testgevallen: De spellingscontrole moet werken voor de talen Nederlands, Duits, Engels en Frans.
Ten derde: Wat er kan gebeuren met een testgeval
- Een testgeval kan nieuw aangemaakt worden.
- Een testgeval kan aangepast worden.
- Een testgeval kan verwijderd worden.
- Een testgeval kan 'hetzelfde blijven' (er verandert niets).
Betreft het oude gedeelte van de regressietest set zijn deze vier bovenstaande gebeurtenissen van kracht. Echter, betreft de nieuwe functionaliteit is alleen punt 1. Een testgeval kan nieuw aangemaakt worden (eerst) van kracht.
Als we het voorbeeld van de spellingscontrole hierboven nemen komen we op het volgende schema:
- Een testgeval kan nieuw aangemaakt worden: spellingscontrole land Noorwegen komt er bij.
- Een testgeval kan aangepast worden: Frans hoeft alleen in het weekend gecontroleerd te worden.
- Een testgeval kan verwijderd worden: Duits hoeft niet langer gecontroleerd te worden.
- Een testgeval kan 'hetzelfde blijven' (er verandert niets): Nederlands en Engels blijven zoals ze waren.
Bron: Softwaretester Conclusie
De combinatie van het feit dat een testgeval kan wijzigen in samenhang met het moment dat een regressietestrun kan draaien zorgt ervoor dat de begripsvorming over wat er allemaal kan gebeuren middels regressietesten erg moeilijk is. Aan de ene kant heb je het aspect dat een testgeval gewijzigd kan worden (aangepast, aangevuld of verwijderd), aan de andere kant heb je het aspect dat er nieuwe functionaliteit (en dus testgevallen) bij komen.
Het inschatten van de gevolgen van het wél aanpassen van een testgeval in combinatie met bepaalde (nieuw) functionaliteit, t.o.v. het niet aanpassen van een testgeval in combinatie met bepaalde (nieuwe) functionaliteit is nooit van te voren te bepalen.
Daarnaast komt nog dat je voor alle testgevallen (zowel oude, nieuwe, als aangepaste) moet bepalen of ze geautomatiseerd gecontroleerd moeten (blijven) worden of handmatig. Iedere keuze hierin kan weer gevolgen hebben voor het al dan wel of niet vinden van een bug.
Je zou hiervan een checklist kunnen maken welke wordt nagelopen voordat iedere nieuwe regressie-run een 'go' krijgt:
- Hebben we gecontroleerd of alle testgevallen van de oude bron nog op de juiste manier worden geverifieerd? handmatig of geautomatiseerd?
- Hebben we gecontroleerd of alle testgevallen van de nieuwe functionaliteit op de juiste manier worden geverifieerd? handmatig of geautomatiseerd?
- Hebben we gecontroleerd of er door de nieuwe functionaliteit samenhang is ontstaan met de oude functionaliteit waardoor er aanvullende testgevallen nodig zijn? (of dat oude testgevallen aangepast of verbeterd dienen te worden?) Zo ja, zijn deze weer ingedeeld in handmatig of geautomatiseerd?
- Hebben we gecontroleerd of alle (belangrijkste) functionaliteit in zijn geheel door de regressietest wordt geraakt?
Uiteraard is verstandig om deze checklist zelf aan te vullen met belangrijke checkpunten (dit kan namelijk snel verschillen per product of bedrijf).
Lees verder