Testen (software)

'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.)

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:

1. De positieve benadering, waarbij wordt aangetoond dat het systeem of het product voldoet aan de belangrijkste eisen van gebruik.
2. 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.

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.

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.

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 kunnen ook worden onderverdeeld in statisch en dynamisch testen.

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.