Testaanpak: leidraad voor het kiezen van een testtechniek

Transcriptie

1 Testaanpak: leidraad voor het kiezen van een testtechniek SYSQA B.V. Almere Datum : 18 november 2012 Status : Definitief Opgesteld door :

2 Organisatie: SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding Fase testplanning Kwaliteitsniveau Product Risico Analyse Testen en toetsen Teststrategie Testbegroting en planning Fase testvoorbereiding en specificatie Testspecificatie Voordelen van de testaanpak... 9

3 Organisatie: SYSQA B.V. Pagina 3 van 9 1 Inleiding Het doel van testen is, om een gefundeerde uitspraak te doen over de kwaliteit van een systeem en om een inschatting te maken van de risico's die men kan lopen bij de implementatie ervan. Als een organisatie over onbeperkte middelen (tijd, geld, bemensing) zou beschikken is het theoretisch mogelijk om een systeem voor 100% te testen. In de praktijk is dit niet haalbaar en daarom zullen gedurende het testtraject keuzes gemaakt moeten worden over welke zaken zwaar, licht en welke niet getest moeten worden. Om tot een gefundeerde uitspraak te komen, moet bij het inrichten van de testen rekening gehouden worden met de volgende zaken: de beschikbare middelen die een organisatie wil besteden aan testen, meestal beperkt tot tijd en geld; de risico's die de organisatie wenst te lopen bij implementatie, uitgedrukt in een productrisico inschatting voor het systeem; de resultaten die de organisatie door middel van het project verwacht te halen. In deze leidraad zijn de stappen beschreven om vanuit deze onderdelen de benodigde testen af te leiden. 2 Fase testplanning Gedurende de planningsfase van een testtraject wordt de basis gelegd voor een beheersbaar en kwalitatief goed testproces. In samenspraak met de belanghebbenden formuleert de testmanager in deze fase het gewenste kwaliteitsniveau en maakt een inschatting van de verwachte productrisico's. Ook stelt hij de teststrategie op, waarbij de testinspanning zo goed mogelijk wordt verdeeld over de systeemonderdelen. 2.1 Kwaliteitsniveau De kwaliteit van een systeem is het geheel aan systeemeigenschappen en -kenmerken, dat nodig is om aan de behoefte van de gebruikers te voldoen. Om een uitspraak te kunnen doen over systeemkwaliteit, moet eerst worden achterhaald wat het gewenste kwaliteitsniveau is. Daarvoor legt de testmanager van alle belanghebbenden van het systeem vast welke systeemonderdelen en projectresultaten zij belangrijk vinden. Dit zijn de testdoelen en ze kunnen ontleend worden aan Kritieke Succesfactoren, requirements, procesbeschrijvingen, wijzigingsverzoeken, etc. 2.2 Product Risico Analyse Om testdoelen te kunnen vertalen naar testcases moet ze eerst inzichtelijk en meetbaar worden gemaakt. Dit gebeurt door ze te splitsen in de volgende vier elementen: (deel)processen: de bedrijfsprocessen, die door het systeem ondersteund worden; producteisen: de eisen die de opdrachtgever aan het systeem stelt; kenmerk: de systeemeigenschappen waarop het systeem wordt getest; (deel)object: de systeemonderdelen, in een voor test logische combinatie.

4 Organisatie: SYSQA B.V. Pagina 4 van 9 Het kenmerk wordt daarbij vaak afgeleid met behulp van de kwaliteitseigenschappen volgens de ISO 9126 standaard (zie onderstaande afbeelding) of de kwaliteitsattributen volgens TMap Next (TMap Next voor resultaatgericht testen ( ), hoofdstuk 10.2). Vervolgens bepalen de betreffende belanghebbenden van het systeem de productrisico's op basis van de bovenstaande vier elementen. De testmanager heeft hierbij een organisatorische en faciliterende rol. Voor elke producteis en (deel)proces combinatie wordt de verwachte schade als gevolg van productfalen bepaald (impact). Voor elke (deel)object en (deel)proces combinatie wordt de verwachte kans bepaald van het in productie manifesteren van een productfout (faalkans). Door impact en faalkans te combineren wordt het productrisico van een (deel)object afgeleid. Door de producteis en het systeem(deel)object daarbij te koppelen aan een kenmerk kan de testmanager de teststrategie bepalen. Als de productrisico's zijn vastgesteld wil dit niet zeggen dat ze voor de rest van de looptijd van het project vast staan. Aan het begin van het project zijn eisen vaak alleen op hoofdlijnen bekend en zijn de technische oplossingen nog niet gekozen, waardoor de faalkans nog niet volledig ingeschat kan worden. Ook kunnen veranderingen in de omgeving en voortschrijdend inzicht een herijking door de belanghebbenden van de productrisico's nodig maken. 2.3 Testen en toetsen Het verzamelen van informatie over de systeemeigenschappen en -kenmerken en het gedrag van een systeem kan op meerdere manieren: Testen: waarbij het actuele resultaat van het draaien van software vergeleken wordt met het verwachte testresultaat. Toetsen; waarbij controles worden uitgevoerd op de systeemcode of de systeemdocumentatie (procedure, handleiding, prototype, ontwerp, etc.). Reviews/Inspecties/audits; waarbij de projectdocumentatie (projectplan, requirements, handleiding, ontwerp, testspeificaties, etc.) geëvalueerd worden. Het inzetten van toetsen en Reviews/ Inspecties/ Audits is voor de testmanager een manier om zowel kosten als tijd te besparen. Dit omdat: de controle wordt uitgevoerd op producten, die relatief goedkoop geproduceerd en gecorrigeerd kunnen worden; de controle gelijktijdig met systeemontwikkeling kan worden uitgevoerd, wat een positief effect heeft op de doorlooptijd; het de kwaliteit van ontwerpdocumentatie ten goede komt, wat leidt tot minder fouten in de te testen systemen, wat de hersteltijd verkort.

5 Organisatie: SYSQA B.V. Pagina 5 van 9 Daarnaast blijft het wel nodig om testen uit te voeren. Enerzijds omdat anders niet alle risico's zullen worden afgedekt. Anderzijds zullen bij de bestudering van documentatie de afwijkingen tussen de werking van het gebouwde systeem en de beoogde functionaliteit niet altijd gevonden worden. 2.4 Teststrategie Op basis van de uitgevoerde risicoanalyse wordt bepaald hoe, hoe zwaar en op welk moment de verschillende systeem(deel)objecten moeten worden getest. De uitgangspunten die hierbij gelden zijn: Welke testsoorten schrijft het testbeleid van de organisatie voor? Wordt het project gestuurd op basis van tijd, geld of risico minimalisatie? Wat is het vroegst mogelijke moment waarop een (deel)object getest kan worden? Hoe is de risicoverdeling over de verschillende (deel)objecten en welke moeten dus lichter of zwaarder getest worden? Welke (deel)objecten hebben in de risicoanalyse een dermate laag risico toegekend gekregen dat ze niet getest hoeven te worden? De onderstaande tabel geeft een aanzet voor de verdeling van de manier van testen over de verschillende kenmerken en testsoorten. Hierbij staat 'a' voor afvinklijst, (*) voor testen met lichte dekking, (**) voor testen met gemiddelde dekking en (***) voor testen met zware dekking. Ook kan tijdens het testen van het ene kenmerk een ander impliciet beoordeeld worden, zonder dat er vooraf testgevallen zijn gedefinieerd. Deze mogelijkheid is in de tabel met een 'i' aangegeven. Kenmerk Testsoort ISO 9126 TMap Toets OT ST/FAT GAT PAT Bruikbaarheid Beheerbaarheid a i * Bedienbaarheid Functionaliteit Beveiliging a * * Beveiligbaarheid Bruikbaarheid Bruikbaarheid a i * *** Bedienbaarheid Begrijpelijkheid Leerbaarheid Compleetheid Functionaliteit Connectiviteit a i i Koppelbaarheid Betrouwbaarheid Continuïteit a i ** Bedrijfszekerheid Bestendigheid Herstelbaarheid Bedrijfszekerheid Robuustheid Herstelbaarheid Degradatiemogelijkheid Uitwijkmogelijkheid Functionaliteit Controleerbaarheid a a/i i i Compleetheid Functionaliteit Flexibiliteit a * i Compleetheid Functionaliteit Juistheid Functionaliteit a * *** i/*

6 Organisatie: SYSQA B.V. Pagina 6 van 9 Kenmerk Testsoort ISO 9126 TMap Toets OT ST/FAT GAT PAT Bruikbaarheid Gebruikersvriendelijkheid a i a/** Aantrekkelijkheid Bedienbaarheid Begrijpelijkheid Leerbaarheid Herbruikbaarheid a i i Geschiktheid a i *** infrastructuur Functionaliteit Inpasbaarheid a i ** Compleetheid Onderhoudbaarheid Onderhoudbaarheid a i i i * Analyseerbaarheid Wijzigbaarheid Efficiëntie Performance a i i i ** Snelheid Portabiliteit Portabiliteit a i i i ** Overzetbaarheid Installeerbaarheid Onderhoudbaarheid Testbaarheid a * i Testbaarheid Efficiëntie Zuinigheid a i i * Middelenbeslag Onderhoudbaarheid a i i i * Stabiliteit Portabiliteit Beïnvloedbaarheid Vervangbaarheid a * In de praktijk wordt de tabel alleen ingevuld voor die kenmerken die bij risicoanalyse aangemerkt zijn. Dit vanuit het standpunt dat alleen de producteisen en objecten die bedrijfskritisch zijn, meegenomen moeten worden in de test. Daarnaast is de tabel opgesteld vanuit een best practice en moet de manier van testen waar nodig aangepast worden aan de eerder genoemde uitgangspunten voor een teststrategie. 2.5 Testbegroting en planning Op basis van de teststrategie en de projectplanning stelt de testmanager een testbegroting en testplanning op en stemt deze af met de opdrachtgever. Als planning, begroting, resultaat en risico voor de opdrachtgever niet in evenwicht zijn, dan past de testmanager de teststrategie aan. Dat kan betekenen dat testdoelen komen te vervallen of dat (deel)objecten minder uitgebreid of minder zwaar getest worden. Ook als er gedurende het testtraject een herijking plaats vindt van de productrisico's wordt deze doorberekend in de testbegroting. Uiteindelijk geven de testbegroting en de teststrategie samen weer hoeveel tijd en geld een organisatie wil besteden aan testen en hoeveel risico ze daarvoor wensen te nemen bij implementatie.

7 Beheerbaarheid Beveiliging Bruikbaarheid Continuïteit Functionaliteit Gebruikersvriendelijkheid Infrastructuur Inpasbaarheid Performance Portabiliteit Zuinigheid Organisatie: SYSQA B.V. Pagina 7 van 9 3 Fase testvoorbereiding en specificatie De voorbereidingsfase van een testtraject start zodra de benodigde systeeminformatie (de testbasis) wordt opgeleverd. In deze fase kiest de testmanager en/of tester de te gebruiken testtechnieken en maakt zo de teststrategie concreet. Eerst controleert de tester of de kwaliteit van de testbasis voldoende is, om tests, uitgangssituaties en/of checklists te kunnen specificeren. Het doel in deze fase is, om de benodigde testgevallen ontworpen te hebben, op het moment dat de ontwikkelaars het systeem opleveren. 3.1 Testspecificatie Voor het definiëren van testgevallen wordt gebruik gemaakt van testontwerptechnieken. Door op deze gestandaardiseerde manier testgevallen af te leiden, kan een bepaalde, voorspelbare testdekking bereikt worden, die aansluit op de teststrategie. TMap Next beschrijft een elftal testontwerptechnieken en een tiental bijbehorende basis technieken (TMap Next voor resultaatgericht testen ( ), hoofdstuk 14). De keuze voor een bepaalde testontwerptechniek hangt voornamelijk af van: het kenmerk van het (deel)object dat getest moet worden (conform teststrategie); de zwaarte waarmee het deel)object getest moet worden (conform teststrategie); de tijd die beschikbaar is om de testen uit te voeren (conform testplanning); de testbasis, maw de beschikbare informatie over het te testen (deel)object; de kennis en kunde van de testers. Die onderdelen waarvan het belang hoog is, vragen daarbij om de inzet van een techniek met een hoge testdekking, een formele techniek en/of meerdere verschillende technieken. In de onderstaande tabel wordt voor elke testontwerp techniek of testvorm aangegeven voor welk kenmerk deze te gebruiken is. TMap kenmerken Testontwerp technieken Beslistabeltest (BTT) * Datacombinatietest (DCT) * * * * Elementaire Vergelijkingstest (EVT) * Error Guessing (EG) * * * * * * * * * * * Exploratory testing (ET) * * * * * * * * * Gegevenscyclustest (GCT) * * Penetratietest * Procescyclustest (PCT) * * * * *

8 Paden Beslispunten Equivalentieklassen Orthogonale arrays Pairwise testing Grenswaarden analyse CRUD Statistisch: profiles Goed-/foutpaden Afvinklijst Beheerbaarheid Beveiliging Bruikbaarheid Continuïteit Functionaliteit Gebruikersvriendelijkheid Infrastructuur Inpasbaarheid Performance Portabiliteit Zuinigheid Organisatie: SYSQA B.V. Pagina 8 van 9 TMap kenmerken Testontwerp technieken Real life test (RLT) * * * * * * * Regressietest * * Semantische test (SEM) * * Syntactische test (SYN) * * Usabilitytest * Use case test (UCT) * * * * * In de hoogte van de testdekking kan gevarieerd worden door in testontwerptechniek en/of in basistechniek te variëren. TMap Next beschrijft wanneer welke variaties toegepast kunnen worden, om de gewenste dekking te genereren (TMap Next voor resultaatgericht testen ( ), hoofdstuk 14). In de onderstaande tabel wordt voor elke testontwerp techniek aangegeven welke basistechniek te gebruiken is. Basistechnieken Testontwerp technieken Beslistabeltest (BTT) * * Datacombinatietest (DCT) * * * * Elementaire Vergelijkingstest (EVT) * * * Error Guessing (EG) Exploratory testing (ET) * * * * * * * * * * Gegevenscyclustest (GCT) * * Procescyclustest (PCT) * Real life test (RLT) * Semantische test (SEM) * * * Syntactische test (SYN) * * Use case test (UCT) * * * *

9 Organisatie: SYSQA B.V. Pagina 9 van 9 Zodra is vastgesteld welke technieken het best passend zijn voor elk (deel)object, kunnen de testgevallen gedefinieerd worden. Daarbij wordt begonnen met die objecten die het zwaarst getest moeten worden en waarvan de software als eerst opgeleverd gaan worden. De testgevallen worden zo uitgeschreven, dat een willekeurige tester deze tijdens de fase testuitvoering kan doorlopen. 4 Voordelen van de testaanpak Door de planning en de voorbereiding van het testtraject volgens deze leidraad uit te voeren treden er tijdens het testtraject een aantal voordelen op. Allereerst zijn de belanghebbende van het systeem meer betrokken bij het testproces, waardoor de mate van acceptatie groeit. Ook geeft het de testmanager de mogelijkheid om te communiceren/rapporteren in de terminologie van de business, waardoor het testproces transparanter en beter bestuurbaar wordt voor de opdrachtgever. Daarnaast wordt op deze manier de testvoorbereiding uit het kritieke pad van een project gehaald. Het opstellen van testgevallen vindt in de luwte van systeemontwikkeling plaats en dus zal de druk op de testers in deze fase verminderen. Samen met de gestructureerde aanpak heeft dit een kwaliteitsverhogend effect op de testspecificatie. Dit maakt het tevens voor de testmanager makkelijker om tijdens de fase testuitvoer het aantal testers uit te breiden zodra dit gewenst is. Tenslotte is het direct duidelijk welke zaken belangrijk zijn en deze kunnen dus als eerste getest worden. Mocht er tijdens de testuitvoer alsnog vertraging optreden, is daardoor de kans gering, dat belangrijke (deel)objecten ongetest in productie gaan.