Testen (software)

Uit Wikipedia, de vrije encyclopedie

Er is een aantal definities van testen (van software) beschikbaar. Centraal in ieder van de definities staat een toets, hierbij is van belang te weten wat je gaat testen (het testobject), waarmee je gaat vergelijken (de norm: eisen, correcte werking, verwachtingen) en hoe je gaat testen (methoden en technieken).

[bewerken] Definities

Onder andere de volgende definities van 'testen' bestaan:

Het methodisch 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 [11].)

[bewerken] Software testen algemeen

Wat we nu met software testen willen bereiken is dat de software naar behoren functioneert en dat het aan de verwachtingen voldoet. Software wordt door software ontwikkelaars gemaakt 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.

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

Het testen van software is tegenwoordig een vak apart met binnen het vakgebied verschillende specialismen. Zo zijn er test specialisten op het gebied van functioneel acceptatie testen, performance testen, security testen, test automation, test management, etc.

[bewerken] Dynamisch of statisch

Bij testen kan worden gesproken van dynamisch testen en van statisch testen:

Statisch testen wordt uitgevoerd zonder het systeem daadwerkelijk uit te voeren.
Bij dynamische testen vindt controle van het draaiende systeem plaats.

Een voorbeeld van statisch testen is de syntaxiscontrole die een compiler uitvoert, een voorbeeld van dynamisch testen is het draaien van een computerprogramma en controleren of het programma een functie correct uitvoert. Bij een product voert men een optische controle uit (statisch) of men laat de machine proefdraaien (dynamisch).

[bewerken] Test tijdstip

Op verschillende momenten kan er getest worden.

Alvorens het ontwikkeltraject is begonnen, kunnen er statische tests plaatsvinden op de documentatie. Dit kan d.m.v. verschillende reviewtechnieken op o.a. het technisch, functioneel of grafisch ontwerp.
Aan het begin, als er nog niets veranderd is; dan hebben we het over een zogenaamde nulmeting. Dat is het referentiepunt waarmee de testresultaten van andere test kunnen worden vergeleken.
Tijdens het ontwikkelen kan er een statische test op de code plaatsvinden, of er kan d.m.v. een component- of unittest gekeken worden of afzonderlijke onderdelen naar verwachting werken. Ook kan er in het kader van een RAD ontwikkeltraject getest worden of de nieuwe versie voldoet aan ongespecificeerde gebruikerswensen. Tijdens de integratietests wordt gekeken of de verschillende onderdelen en/of afzonderlijke systemen goed met elkaar werken.
Nadat de ontwikkeling is afgesloten, kan getest worden of het testobject volgens de vooraf vastgelegde specificaties werkt.
Nadat er een wijziging heeft plaatsgevonden aan een al functionerend systeem. De wijziging wordt getest en tevens wordt getest of de gedeelten die niet gewijzigd zijn, nog steeds goed functioneren. Dit is de regressietest.

[bewerken] Doelen van het testen

Vanuit de leverancier, producent, gezien is het doel van het testen, het leveren van het bewijs dat het ontwikkel en programmeer-werk 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.
Ten tweede wil men weten of de gebruikers met het systeem willen en kunnen gaan werken. 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.

[bewerken] Manier van testen

Alles kan getest worden of er kan een steekproef genomen worden. Uiteindelijk gaat het bij testen om het beheersen van risico's. Het is heel moeilijk om echt foutvrij te werken. Een systeem hoeft ook niet foutvrij te zijn. Zelfs met fouten kan het beter zijn dan het systeem dat het vervangt. Het is ook heel goed mogelijk om fouten later te herstellen. Het is heel duur en het kost veel tijd om alles te testen. Het testen kan gestructureerd gebeuren, volgens een Testplan. In het testplan wordt bepaald wat en hoe uitgebreid zaken getest worden. Vaak wordt hier gebruik gemaakt van testscripts. Ook is het mogelijk en heel populair om in het wilde weg te testen. Voordeel daarvan is dat het weinig voorbereiding kost, nadeel is dat er mogelijk niet volledig getest wordt, je weet niet wat er getest is. Ook kunnen gevonden fouten niet reproduceerbaar zijn, waardoor ze niet te herstellen zijn.

[bewerken] Twee stromingen

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

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

Gebruikelijk is om eerst te testen of het testobject voldoet aan de belangrijkste eisen, dus om eerst "positief" te testen. Na deze test kan al besloten worden of het systeem wordt ingevoerd of niet.

Blijkt het systeem goed genoeg, dan kan er "negatief" getest worden, waarbij op uitzonderingen getest wordt. Gekeken wordt hoe het systeem reageert op veel gebruikers tegelijkertijd, de stresstest op jaarovergangen, op ongebruikelijke rapportages, op uitgebreide query's, op foutieve invoer etc.

[bewerken] Black Box of White Box

Een andere onderverdeling van testen zit in de manier waarop het object van de test benaderd wordt:

Black Box test

Van het testobject is niets (of maar een klein deel) van de werking bekend bij de tester. De tester zet zijn tests op volledig onafhankelijk van de interne werking en alleen gebaseerd op wat de invoer is en wat de verwachte uitvoer zou moeten zijn.

White Box test

De interne werking van het testobject is bekend, tests zijn gebaseerd op hoe de interne werking er uit ziet. Tests volgen de diverse relevante paden door het te testen object heen.

(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.")

[bewerken] Impliciet of expliciet

Bij het testen kan ook nog een onderverdeling worden gemaakt naar impliciet testen of expliciet testen.

Impliciet

Bij het impliciet testen wordt er wel aandacht besteed aan het testen van het testobject op een bepaalde kwaliteitseigenschap, maar de test vindt zijdelings plaats naast andere tests. Een voorbeeld is het impliciet testen van performance. Naast bijvoorbeeld een 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

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.

[bewerken] Normen

Een belangrijk aspect bij testen is het vaststellen van de norm. Oftewel de vraag: wat is goed? Bij computerprogramma's kan dit vastliggen in een functioneel ontwerp, bij andere producten is er vaak sprake van een productbeschrijving, offerte of norm. Het functioneel ontwerp van een programma beschrijft wat de functies zijn, het definieert wat je van een programma mag verwachten. Dat ontwerp is dan de norm, die bepaalt of een programma correct werkt of niet. Wat overigens niet hetzelfde is als de vraag of het programma correct is of niet, immers ook het ontwerp kan fout zijn, dus als het programma volgens ontwerp goed is wil dat nog niet per definitie zeggen dat het voor het gebruik voldoet. Dat wordt getest in de gebruikersacceptatietest of GAP genoemd. Een gebruikersacceptatietest is nodig omdat de gebruikers vaak niet het functioneel ontwerp hebben gelezen. Mogelijk zijn er wel enkele gebruikers betrokken geweest bij het opstellen van dit ontwerp, maar of dit goed is gegaan wordt in de GAP getest. Kleine wensen kunnen vergeten zijn, of nooit genoemd omdat die zo voor de hand liggend waren. Ook kunnen kleine groepen gebruikers niet gehoord zijn, weinig voorkomende situaties kunnen over het hoofd gezien zijn, van die dingen.

[bewerken] 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.

[bewerken] Testontwikkelmethoden

[bewerken] Testtechnieken

[bewerken] Black-box

[bewerken] White-box

[bewerken] Statische testtechnieken

[bewerken] Testsoorten

[bewerken] Kwaliteitsattributen

Functionaliteit heeft betrekking op het bestaan van een set producten/processen en hun specifieke gebruik. Het zijn de producten/processen die beschreven of stilzwijgende behoeften bevredigen.
Betrouwbaarheid heeft betrekking op het vermogen van het product/proces om het prestatieniveau onder bepaalde condities voor een bepaalde periode te handhaven.
Onderhoudbaarheid heeft betrekking op de benodigde inspanning om gespecificeerde wijzigingen aan te brengen.
Bruikbaarheid heeft betrekking op de inspanning benodigd voor gebruik, en op de individuele beoordeling van zo'n gebruik, door een bepaalde of gebleken groep van gebruikers.
Portabiliteit heeft betrekking op de mogelijkheid om het product van de ene omgeving naar de andere om te zetten.
Efficiency heeft betrekking op de relatie tussen het prestatieniveau van het product/proces en de hoeveelheid gebruikte middelen onder bepaalde condities.
Beheerbaarheid heeft betrekking op het gemak waarmee het systeen in operationele staat kan worden gebracht en gehouden.