8 manieren om software te testen

Software testen - een vak apart

We hebben verschillende testers in huis die de functionaliteit en de prestaties van het design en de software controleren. Want net zoals een schrijver moeite heeft om zijn eigen werk te redigeren, zo kan een developer een blinde vlek hebben voor zijn eigen code (ook al beschikt hij over de 10 kwaliteiten van een succesvolle software developer!). Bovendien kan een developer niet altijd overzien wat er gebeurt als verschillende apart gebouwde delen van de software bij elkaar komen. Daarom is het goed dat een tester de werking van de software helemaal naloopt en kijkt of alles doet wat het moet doen. Testers zijn dus géén designers of developers, het is een aparte discipline!

Vooraf: acceptatiecriteria opstellen

Testen komt al voor de start van een project om de hoek kijken, namelijk bij het opstellen van de acceptatiecriteria. Deze criteria bevatten de verschillende testonderdelen en de voorwaarden waaraan de software moet voldoen. De tester controleert of de criteria deugen: zijn het reële wensen of verwachtingen en kan de software straks eigenlijk wel datgene uitvoeren waarvoor hij bedoeld is?

Deze manier van werken voorkomt verrassingen bij de acceptatietest aan het eind van het traject. Bij de acceptatietest loopt de opdrachtgever of de gebruiker door de applicatie, website of webshop heen. Als er dan nog fouten aan het licht komen, moet je weer een stap terug in het ontwikkelproces. Voor je het weet, zijn er dan weer twee tot drie weken verstreken. Dankzij de acceptatiecriteria weten we zeker dat de software straks 100% gebruiksvriendelijk is en precies doet wat de opdrachtgever wil. Dat biedt alle partijen houvast en voorkomt vertraging.

Vijf essentiële technische tests

De eisen en wensen liggen vast in de Definition Of Done (DoD). Dit document beschrijft waaraan de software moet voldoen en daarmee wat en hoe er getest gaat worden. Iedere keer dat een stuk software gereed is, voert het ontwikkelteam twee technische tests uit:

1. Unittest: We testen de kleinst testbare eenheid, bijvoorbeeld een losse softwaremodule, een menukeuze die verschillende andere modules aanroept, of een ander onderdeel van de software.
   
   
2. Systeemtest: We testen alle testbare eenheden, maar dan in samenhang met elkaar. Want meerdere onderdelen die los van elkaar perfect werken, kunnen samen toch een fout opleveren.

Naast deze twee standaard technische tests zijn er nog drie performancetests. Deze optionele technische tests garanderen dat het hele systeem, dus alle verschillende onderdelen bij elkaar, naar behoren presteert en dat de verschillende functies snel genoeg worden uitgevoerd. Dit zijn:

1. Loadtest: De tester onderzoekt of het systeem een reële gebruikersbelasting aankan, zowel bij normaal als bij piekgebruik. Zo nee, dan bekijken de developer, tester, systeembeheerder en designers samen wat hiervan de oorzaak is. Samen met de systeembeheerder kijken we ook naar de technische infrastructuur om te zien welke verbeteringen hier mogelijk zijn.
   
   
2. Stresstest: Bij een stresstest zetten we het systeem langdurig onder druk met veel invoer, veel gebruikers en veel verwerkingen. Zo komen we erachter hoeveel gebruikersacties het systeem maximaal aankan.
   
   
3. Duurtest: Waar de stresstest een langdurige piekbelasting simuleert, heeft de duurtest als doel een reële belasting over een lange periode na te bootsen. Hiermee controleer je of de hardware niet bezwijkt onder langdurige belasting. Ook spoor je zo memory leaks op, waarbij het systeem onnodig veel computergeheugen gebruikt.

Het is aan te raden om de drie performancetests na de oplevering of livegang periodiek te laten plaatsvinden. Zo weet je zeker dat je applicatie, website of webshop goed blijft werken. Vanzelfsprekend kunnen wij deze tests voor je uitvoeren.

Drie gebruikerstests: ervaar wat jouw bezoeker meemaakt

Dankzij de technische tests weten we dat de software in technisch opzicht werkt: er zijn geen foutmeldingen, de software stopt er niet plotseling mee, en de snelheid (performance) is voldoende. Maar software moet niet alleen werken, je moet ermee werken. Daarom voeren we drie verschillende gebruikerstests uit:

1. Regressietest: Iedere keer dat er een nieuw onderdeel van de software gereed is, ontwikkelen we een speciaal testscript dat automatisch controleert of de software doet wat hij moet doen. Dit is de zogenaamde regressietest. Naarmate de software verder wordt uitgebreid, wordt ook de set met testscripts steeds verder uitgebreid. Zo controleren we in de loop van het ontwikkeltraject voortdurend de functionaliteit van de software.

2. Functionele acceptatietest (FAT): Zowel de tester als de eindgebruiker gaan aan de slag met de software en kijken of alles inderdaad zo werkt als het is bedoeld.

3. Gebruikersacceptatietest (GAT): Deze test vindt ook vaak plaats met een gebruikerspanel. Zij testen dan of de software voldoende ondersteuning biedt bij hun taken.

Wanneer welke test?

Zodra een deel van de software gereed is, voeren we standaard een unittest, een systeemtest en een regressietest uit. Komen er fouten aan het licht? Dan pakken we die meteen op in de volgende stap van het ontwikkeltraject. Aan het eind van het traject vinden de functionele en gebruikersacceptatietests plaats. In overleg met onze opdrachtgever bepalen we hoeveel tijd hiervoor nodig is.

Go-live!

Na afloop van het ontwikkelproces weten we zeker dat het systeem aan de acceptatiecriteria voldoet. Dan is het tijd voor de livegang. Die is niet zo spannend meer, aangezien we alles al heel uitgebreid hebben getest. Is je interesse in testen aangewakkerd? Lees ook ons artikel over de vooroordelen van testen.