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