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 er getest gaat worden (het testobject), de eisen, (de testbasis), wanneer er getest gaat worden en hoe er getest gaat worden (methode).

Definities

'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. (Definitie volgens de standaard ISO 8402.)

Doelen

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.

Kwaliteitsattributen

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.

Norm en testbasis

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”.

Twee stromingen

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 functioneleacceptatietest 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, zowel in de functioneleacceptatietest 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.

Manier van testen

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. Ook kunnen gevonden fouten niet reproduceerbaar zijn, waardoor ze moeilijker te vinden en te herstellen zijn.

Boeken, methoden en technieken

Voor het opzetten van tests op een gestructureerde wijze zijn verschillende methoden beschikbaar. Die methoden maken vervolgens weer gebruik van een veelheid aan testtechnieken. Meer of minder bekende methoden zijn:

ISTQB voorheen ISEB. Dit is een standaardisatie die door veel landen is erkend. Alle EU-landen, Canada en Australië hebben deze standaard omarmd. De Verenigde Staten hebben hun eigen standaardisatie, namelijk de IEEE.
TMAP is een handboek dat is samengesteld namens het toenmalige bedrijf IP/Softwarecontrol (het huidige Sogeti Nederland), gebaseerd op de pijlers Techniek, Infrastructuur, Organisatie, met als middelste pijler de Fasering.
Kwaliteitszorg door Acceptatietesten van N.P.M. Mors is een van de eerste boeken over gestructureerd testen in de Nederlandstalige wereld.
Als inspiratiebron voor TMap en ISTQB wordt vaak opgevoerd Barry Boehm. Deze beschreef het belang van zo vroeg mogelijk testen op basis van eisen en wensen aan de te leveren software.

Testtijdstip

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.

Testen tijdens beheer

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.

Testen in een project

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.

Statisch of dynamisch

Testen kunnen ook worden onderverdeeld in statisch en dynamisch testen.

Statisch testen

Statisch testen wordt uitgevoerd zonder het systeem daadwerkelijk uit te voeren en vaak als het systeem nog niet (volledig) beschikbaar is. Dit wordt ook wel toetsen genoemd. Deze toetsen worden daarom vaak aan het begin van de ontwikkeling uitgevoerd. Er kan bijvoorbeeld worden getoetst of de documentatie (volledig) aanwezig is en aan bepaalde kwaliteitseisen voldoet. Voorbeelden van statische testen zijn de optische controle, syntaxiscontrole, collegiale review, Informele review, formele inspectie, technische review, statische code analyse.

Dynamisch testen

Zodra er een systeem beschikbaar is kan het draaien en kan er dynamisch getest worden. 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; blackboxtest of whiteboxtest.

Impliciet dynamisch

Bij het impliciet testen wordt er impliciet/zijdelings getest of het testobject aan een bepaalde requirement voldoet. Een voorbeeld is het impliciet testen van performance. Naast bijvoorbeeld een expliciete functionele test kan een tester dan een checklist invullen om de performance van het testobject bij te houden in termen als het aantal seconden voor het openen van een scherm.

Expliciet dynamisch

Bij het expliciet testen wordt een testobject juist heel direct getest op bepaalde kwaliteitseigenschappen. Een voorbeeld is dat een tester heel bewust een test opzet voor het meten van performance waarin hij van tevoren de uit te voeren acties en controles definieert, inclusief verwachte resultaten. Vervolgens voert de tester zijn test uit om te controleren of het object voldoet aan de gedefinieerde performance verwachtingen.

Whiteboxtest

Bij een whiteboxtest is de interne werking van het systeem of product bekend. Deze werking mag (tijdelijk) aangepast worden; bijvoorbeeld om tussenresultaten te kunnen controleren. Een voorbeeld hiervan is het compileren in debug-mode. Omdat implementatie bekend is, kunnen de testen specifiek hiervoor gemaakt worden. En doordat tussenresultaten beschikbaar zijn is het eenvoudiger te controleren of de werking correct is. Whiteboxtesten worden vaak door de ontwikkelaars zelf gebruikt; deze kennen immers de interne werking. Het primaire doel is vaak niet het controleren op fouten (verificatie), maar het opsporen van fouten (debuggen). Een bekend voorbeeld hiervan is de unittest, vaak in combinatie met een Test-Driven Development-aanpak.

Indien de interne werking gebruikt wordt, maar de test wordt uitgevoerd op echte (gecompileerde!) product is het een Glassboxtest, al wordt die term vaak niet gebruikt.

Blackboxtest

Bij de Blackboxtest is niets (of maar een klein deel) van de werking bekend bij de tester. 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.

Grayboxtest

Naast de onderverdeling in de hoofdstromen, het blackbox- en whiteboxtesten, is er nog een variant, namelijk grayboxtesten: "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, shadowtest.

Op ervaring gebaseerd

Wat ook veel voorkomt zijn testen door experts die op grond van hun ervaring testen. Dit zijn niet helemaal ad-hoctests, maar het komt wel in de buurt. Voorbeelden zijn "error guessing" en "exploratory testing". Bij error guessing test men systematisch 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 gevonden worden. Eerst worden vaak de goed-paden doorlopen en vervolgens wordt ook gekeken of het systeem ook de uitzonderingen goed aan kan.

Testverslag

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.

Overdracht

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 in de praktijk

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.