Testen (software)

Het testen van software is het vaststellen in hoeverre de software aan de eisen voldoet. Hierbij is het van belang te weten wat, welk object er gaat worden getest, de eisen, vastgelegd in de testbasis, wanneer en hoe, dus met welke methode, er gaat worden getest.

'Testen' kan worden gedefinieerd als:

• Een verzameling activiteiten die uitgevoerd wordt om een of meer kenmerken van een product, proces of dienst vast te stellen volgens een gespecificeerde procedure. [ISO/ IEC, 1991]
• Een proces dat inzicht geeft in, en adviseert over, de kwaliteit van de software en de daaraan gerelateerde risico's.
• Het methodische proces van het aantonen van afwijkingen tussen de werkelijke werking versus de verwachte werking van een systeem of product.
• De activiteit waarbij de kwaliteit van het gehele systeem of product wordt gecontroleerd.
• Het proces waarmee de correcte werking van een systeem of product wordt aangetoond.
• Activiteiten zoals meten, onderzoeken, beproeven, keuren met kalibers van één of meer kenmerken van een product of dienst en het vergelijken van de uitkomsten met de gestelde eisen, om te bepalen of aan deze voorwaarde is voldaan.^[1]

Software wordt door softwareontwikkelaars ontworpen voor een bepaalde toepassing. Dit lijkt op zich eenvoudig, maar door de complexiteit van software en de omgeving waarin software werkt, is het praktisch onmogelijk om foutloos software te maken. Dit maakt het testen van software zo belangrijk.

Vanuit de leverancier, producent, gezien is het doel van het testen, het leveren van het bewijs dat het ontwikkel- en programmeerwerk goed gedaan is zodat de factuur ingediend en betaald kan worden.

Vanuit de opdrachtgever, klant, gebruiker gezien zijn er meerdere doelen.

• Ten eerste wil men weten of de leverancier heeft gedaan wat is afgesproken.
• Ook wil men de risico's in kunnen schatten bij het gebruik van de software. Men wil weten of de gebruikers met het systeem willen en kunnen gaan werken.
• Ook wil men fouten vinden, en wel zo snel mogelijk, want hoe later fouten gevonden worden hoe duurder het wordt om ze te herstellen.
• Ook wil men fouten voorkomen, dat gebeurt bijvoorbeeld met statisch testen.

Testen kost tijd en geld, daarom moet er nagedacht worden over wat er getest wordt en hoe uitgebreid dit gebeurt. Hoe uitgebreid er getest wordt is dan ook afhankelijk van het budget en van de risico's die men wil inschatten. In het ideale geval wordt er niet getest, want dat is het goedkoopst, maar vaak durft men dat niet omdat men bepaalde risico's niet wil lopen. Door te testen krijgt men inzicht in die risico's. Daarom moet er een impliciete of expliciete risico-inschatting gemaakt worden. Het testen kost tussen de 10 en 30% van het totale projectbudget. Eventueel kan men met bijvoorbeeld een testpuntanalyse een inschatting maken.

Software wordt vóór het operationeel gebruik getest, niet om alle fouten weg te halen, maar om het risico op problemen tijdens het gebruik op een acceptabel niveau te houden. Als het al uitvoerbaar zou zijn, zou het maken van foutloze software een onevenredige hoeveelheid tests en kosten betekenen.

De invoering van het systeem heeft allerlei gevolgen voor de omgeving. Deze gevolgen wil men goed kunnen inschatten. Het gaat om de gevolgen op commercieel, organisatorisch, personeel, administratief, financieel en technisch gebied.

In de internationale ISO 9126-standaard voor softwarekwaliteit worden de volgende kwaliteitsattributen gedefinieerd:

• Effectiviteit of functionaliteit gaat over de vraag of de software doet wat het moet doen. En dit kan zowel beschreven als stilzwijgende vanzelfsprekende behoeften betreffen.
• Betrouwbaarheid heeft betrekking op het vermogen van het product/proces om het prestatieniveau onder bepaalde condities, zoals veel gebruikers, voor een bepaalde periode te handhaven.
• Gebruiksvriendelijkheid heeft betrekking op de inspanning benodigd voor gebruik, en op de individuele beoordeling van zo'n gebruik, door de gebruikers.
• Flexibiliteit heeft onder andere betrekking op de mogelijkheid om de software van de ene omgeving naar de andere om te zetten, maar ook op de mogelijkheid om het te wijzigen.
• Onderhoudbaarheid heeft betrekking op de benodigde inspanning om wijzigingen aan te brengen.
• Beheerbaarheid heeft betrekking op het gemak waarmee het systeem in operationele staat kan worden gebracht en gehouden.
• Beveiliging, gaat zowel over privacy als over het vermogen om zaken als brand, diefstal en moedwillige verstoringen te overleven.
• Efficiency heeft betrekking op de relatie tussen het prestatieniveau van het product/proces en de hoeveelheid gebruikte middelen.

Een belangrijk aspect bij testen is het vaststellen van de norm. Oftewel de vraag: wat is correct? Bij computerprogramma's kan dit zijn vastgelegd in één of meerdere documenten, waaronder een technisch of functioneel ontwerp, een interactie-ontwerp of ontwerp van de grafische gebruikersinterface. Deze documenten vormen samen de testbasis, het geheel van producten waarop de verwachtingen, oftewel het testontwerp, wordt gebaseerd. Er wordt gesproken van 'verwachtingen', omdat er bij software testen niet wordt gekeken of de software goed of fout functioneert, maar of de resultaten overeenkomen met wat er in de testbasis is beschreven en/of wat men “verwacht”.

We zien globaal twee stromingen in het testen die afhankelijk van het toepassingsgebied worden toegepast:

• De positieve benadering, waarbij wordt aangetoond dat het systeem of het product voldoet aan de belangrijkste eisen van gebruik.
• De negatieve benadering, gericht op het aantonen dat er fouten in het geteste product of systeem zitten.

Bijvoorbeeld: de functionele acceptatietest is erop gericht om fouten te vinden. Men test aan de hand van de functionele specificaties of het systeem doet wat het moet doen, maar vooral ook of het systeem niet doet wat het niet moet doen. De gebruikersacceptatietest is er veel meer op gericht te kijken of de gebruiker met het systeem kan werken en of het systeem de gebruiker, waarvoor het systeem bedoeld is, voldoende faciliteert. Uiteraard is dit diffuus. In de functionele acceptatietest zal men er niet aan ontkomen eerst te kijken of het systeem werkt zoals het moet werken, en zal men in de gebruikersacceptatietest nog altijd fouten tegenkomen.

Alles kan getest worden of er kan een steekproef genomen worden. Uiteindelijk gaat het bij het testen om het beheersen van de risico's. Het is heel moeilijk om echt foutvrij te werken. Een systeem hoeft ook niet foutvrij te zijn, zelfs met fouten kan het nieuwe systeem beter zijn dan datgene wat het vervangt. Het is ook heel goed mogelijk om fouten later te herstellen. Het testen kan gestructureerd gebeuren, volgens een methode of een testplan. In het testplan wordt bepaald wat, en hoe uitgebreid zaken getest worden. Vaak wordt hier gebruikgemaakt van testscripts. Ook is het mogelijk en heel populair om minder gestructureerd (ad hoc) te testen zoals exploratory testing of error guessing. Voordeel daarvan is dat het weinig voorbereiding kost, nadeel is dat er mogelijk niet volledig getest wordt. Het is ook mogelijk dat gevonden fouten niet kunnen worden gereproduceerd, waardoor ze moeilijker te vinden en te herstellen zijn.

Voor op een gestructureerde wijze het opzetten van tests zijn verschillende methoden beschikbaar. Die methoden maken vervolgens weer gebruik van een veelheid aan testtechnieken. De verschillende methoden zijn vaak door handboeken gedocumenteerd. Meer of minder bekende methoden en boeken zijn:

• International Software Testing Qualifications Board ISTQB, voorheen ISEB, is een standaardisatie die door veel landen is erkend. Alle landen van de Europese Unie, Canada en Australië hebben deze standaard aangenomen. De Verenigde Staten hebben hun eigen standaardisatie, die van de IEEE.
• Test Management Approach TMAP is een methode die door het toenmalige bedrijf IP/Softwarecontrol, het huidige Sogeti Nederland, is samengesteld.
• Kwaliteitszorg door Acceptatietesten van NPM Mors is een van de eerste boeken over gestructureerd testen in de Nederlandstalige wereld.
• Als inspiratiebron voor TMAP en ISTQB wordt Barry Boehm vaak genoemd. Hij beschreef het belang van zo vroeg mogelijk testen op basis van eisen en wensen aan de te leveren software.

Software kan getest worden tijdens het beheer, als het gaat om kleine wijzigingen van de software of tijdens de ontwikkeling, in een project, als het gaat om grotere wijzigingen.

Nadat de projectmatige systeemontwikkeling is afgesloten komt het systeem in beheer, waar ook nog kleinschaligere ontwikkelingen kunnen volgen die ook getest moeten worden. De tests die in projecten gebruikt worden kunnen hier ook uitgevoerd worden. De wijziging wordt getest en tevens wordt getest of de gedeelten die niet gewijzigd zijn, nog steeds goed functioneren. Dit kan met een zogenaamde regressietest.

Op verschillende momenten kan er in het project getest worden. Door de verschillende ontwikkelmethoden zijn er ook verschillende manieren van testen.

• Alvorens het ontwikkeltraject is begonnen, kunnen er statische tests plaatsvinden op de documentatie. Dit kan door middel van verschillende reviewtechnieken op o.a. het technisch, functioneel of grafisch ontwerp.
• Aan het begin, als er nog niets veranderd is, kan er getest worden, dan spreekt men over een zogenaamde nulmeting. Dat is het referentiepunt waarmee de testresultaten van andere tests kunnen worden vergeleken.
• Tijdens het ontwikkelen kan er een statische test op de code plaatsvinden, of er kan door middel van een component- of unittest gekeken worden of afzonderlijke onderdelen naar verwachting werken.

De meeste software wordt ontwikkeld, beginnend bij de wensen en eisen van de eindgebruikers, via de functionele en technische beschrijvingen naar de uiteindelijke code. Dit is het watervalmodel. Bij iedere fase horen verschillende eindproducten, welke als testbasis gebruikt worden.

• Unittesten worden uitgevoerd door de programmeurs/ontwikkelaars en baseren zich op gedetailleerde beschrijvingen van de software (bij het watervalmodel), of op ongespecificeerde gebruikerswensen bij een RAD ontwikkeltraject.
• De Integratietest baseert zich op de documenten die de systeemarchitectuur beschrijven.
• Bij de systeemtest wordt gekeken naar de systeemspecificaties.
• En bij de gebruikersacceptatietest wordt gekeken naar de gebruikerswensen.

Deze fases en hun samenhang is beschreven in het V-model.

Testen kunnen ook worden onderverdeeld in statisch en dynamisch testen.

Statisch testen wordt uitgevoerd zonder het informatiesysteem daadwerkelijk uit te gebruiken, vaak als het nog niet of alleen gedeeltelijk beschikbaar is. Dit wordt ook toetsen genoemd. Deze toetsen worden daarom vaak aan het begin van de ontwikkeling uitgevoerd. Er kan bijvoorbeeld worden getoetst of de documentatie voldoende of volledig aanwezig is en aan bepaalde kwaliteitseisen voldoet. Voorbeelden van statische testen zijn peerreview, syntaxiscontrole en andere statische analyse van de gebruikte computerprogramma's.

Zodra er een systeem beschikbaar is kan het draaien en kan er dynamisch worden getest. Bij het dynamisch testen kan een onderverdeling worden gemaakt naar impliciet testen of expliciet testen en naar de mate hoeveel de tester weet van de interne structuur van de software. Dat verschil wordt met whiteboxtest en blackboxtest aangegeven.

Bij het impliciet testen wordt gecontroleerd dat een informatiesysteem aan bepaalde systeemeisen voldoet, bijvoorbeeld de snelheid waarmee het werkt. Een checklist is daarbij een goed hulpmiddel. Er wordt nog niet gecontroleerd dat het aan de volledige functieomschrijving voldoet.

Bij het expliciet testen wordt wel gecontroleerd dat een informatiesysteem aan de functieomschrijving voldoet. Er wordt bijvoorbeeld gecontroleerd dat gegeven een bepaalde invoer het informatiesysteem de goede uitvoer geeft.

Bij een whiteboxtest is de interne werking van het systeem of product bekend. Deze werking kan worden aangepast om bijvoorbeeld tussenresultaten te kunnen controleren. Deze voor de controle nodige veranderingen zijn dus meestal tijdelijk. Een voorbeeld hiervan is het compileren in debug-mode. Omdat de implementatie bekend is kan er op specifieke punten worden gecontroleerd. Doordat tussenresultaten beschikbaar zijn is het eenvoudiger te controleren of de werking correct is. Whiteboxtesten worden vaak door de ontwikkelaars zelf gebruikt, omdat zij weten hoe de verschillende onderdelen van het te controleren computerprogramma werken. Het primaire doel is vaak niet het controleren op fouten, op verificatie, maar het opsporen van fouten, dus debuggen. Een bekend voorbeeld hiervan is de unittest, vaak in combinatie met test-driven development.

Indien de interne werking gebruikt wordt, maar de test wordt uitgevoerd op het in de praktijk te gebruiken informatiesysteem heet het een glassboxtest.

Bij de blackboxtest is niets of maar een klein deel van de werking van de gebruikte programma's bekend. De blackboxtests wordt meestal na de whiteboxtest uitgevoerd door mensen die ook niet ontwikkeld hebben en niets of weinig hoeven te weten van de interne structuur. Een voorbeeld is een acceptatietest.

Behalve de onderverdeling in blackbox- en whiteboxtesten is er nog een variant, de grayboxtest: It doesn't matter whether a cat is black or white as long as it catches mice. Voorbeelden zijn: de stresstest, regressietest, dataconversietest, real-life test en de schaduwtest.

Wat ook veel voorkomt zijn testen door experts die op grond van hun ervaring testen. Dit tests gaan niet helemaal ad-hoc, maar het komt wel in de buurt. Voorbeelden zijn error guessing en exploratief testen. Bij error guessing test men op veel voorkomende fouten. Bij exploratory testing gaat men kriskras door het systeem. Dit heeft ook een leereffect en geeft vertrouwen als er geen fouten worden gevonden. Eerst worden vaak de paden doorlopen die het meeste voorkomen en goed werken en vervolgens wordt gekeken of het systeem ook de uitzonderingen goed aan kan.

Na afloop van het testen kan in een testverslag verteld worden wat er getest is. Dit is handig omdat tests herbruikbaar zijn, maar ook om zaken niet dubbel te testen. Een testverslag kan de volgende zaken bevatten: checklists met wat van de testbasis getest is. Testgevallen en testscripts met verslagen van wat er van is uitgevoerd. Bewijs dat de testgevallen zijn uitgevoerd, zoals screendumps. Bevindingenadministratie, testcoveragetools, geautomatiseerde tests, test-Driven Development administratie en tot slot een demonstratie, walkthrough van het systeem.

Aan het einde van het testproces wordt een vrijgaveadvies opgesteld aan de opdrachtgever met de testresultaten en mogelijke risico's bij de implementatie. De overdracht van de software inclusief documentatie vindt plaats aan de beheerafdeling, testscripts en overige testware worden geborgd zodat deze later bij wijzigingen of hertests gebruikt kunnen worden.

Testen is arbeidsintensief, de hoeveelheid werk kan oplopen tot 40% van de bouwinspanning van een informatiesysteem. Organisaties die bedrijfssoftware gebruiken, moeten in de praktijk in hoge mate vertrouwen op de kwaliteit van de leverancier van die software omdat de organisaties zelf te klein zijn om goed te testen. Met name in de zorg met relatief complexe software en geringe ICT traditie kan dit tot problematische situaties leiden.