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 (de 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 een 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 foutloze 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 een 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 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.
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. Het is ook mogelijk dat gevonden fouten niet kunnen worden gereproduceerd, waardoor ze moeilijker te vinden en te herstellen zijn.
Methoden en documentatie 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.
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, die 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 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.
Dynamisch testen 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.
Impliciet dynamisch 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.