7 Testrisicoanalyse 7.1 Introductie Veel testtrajecten zijn tegenwoordig gebaseerd op risico s. Bij risicogebaseerd testen (RBT) bepaalt het risico dat de organisatie loopt als het systeem in gebruik wordt genomen de testaanpak. Afhankelijk van het risico worden de scope en diepgang van de testen gevarieerd. Voordeel van risicogebaseerd testen is dat de tijd en aandacht gaan zitten in die zaken die toegevoegde waarde hebben voor het beoogde resultaat [Pinkster et al, 2004]. Om de risico s in kaart te brengen wordt er een Testrisicoanalyse (TRA) uitgevoerd. Een Testrisicoanalyse levert inzicht in de risico s die het beoogde resultaat bedreigen. Dit inzicht vormt op verschillende momenten in het testtraject een leidraad voor de te nemen beslissingen. De TRA wordt gebruikt bij het vaststellen van de Teststrategie. Zelden is er in een testtraject voldoende tijd om alles te kunnen testen. De TRA kan dan worden gebruikt voor prioriteitsbepaling; om aan te geven waar de testactiviteiten zich op moeten richten. Op basis van de TRA kan de testcoördinator bijvoorbeeld besluiten om bepaalde zaken niet of minder goed te testen. De TRA ondersteunt daarbij de keuze voor de toe te passen testontwerptechnieken. Bij reviews en intakes kan op basis van de TRA worden besloten belangrijke onderdelen beter te beschouwen dan de minder belangrijke. Tijdens de testuitvoering wordt de TRA gebruikt om de volgorde vast te stellen waarin de testen uitgevoerd worden. Het is gebruikelijk om te beginnen met de belangrijkste testen. Dit vergroot de kans dat de belangrijkste bevindingen snel worden gevonden. Daarnaast heeft dit
TestGoal, resultaatgedreven testen het voordeel dat als de testuitvoering vroegtijdig wordt afgebroken, de belangrijke testen zijn uitgevoerd. In de testrapportage wordt verwezen naar de risico s. Dit heeft als voordeel dat de testrapportage verhaalt over zaken die de belanghebbenden aanspreekt, namelijk de risico s voor het beoogde resultaat. We onderscheiden twee vormen van TRA die naast elkaar gebruikt kunnen worden. 1-D TRA Bij de eendimensionale TRA wordt het relatieve belang bepaald van de verschillende onderdelen van het testobject. Aan de hand van een functionele decompositie wordt een overzicht gemaakt van de functies die het systeem moet kunnen ondersteunen. De TRA definieert welke functies belangrijk zijn, en welke minder belangrijk. Input voor de 1-D TRA is de systeem- of requirementsspecificatie. Hierin zijn de functies benoemd die het systeem moet ondersteunen. Het product van de 1-D TRA is een lijstje met deze functies, gerangschikt naar hun relatieve belang. De 1-D TRA is goed bruikbaar om per functie de testdiepte te bepalen en om de volgorde van de testuitvoering te bepalen. 2-D TRA De tweedimensionale TRA brengt de bedreigingen van het beoogde resultaat in kaart. Van elke bedreiging wordt ingeschat wat de kans is dat deze werkelijk optreedt en wat de impact ervan is. Input voor de 2-D TRA zijn de bedreigingen die door de belanghebbenden worden erkend. Het product van de 2-D TRA is een impact x waarschijnlijkheid -matrix waarin elk risico is gepositioneerd. De 2-D TRA is goed bruikbaar om te bepalen welke testen er uitgevoerd moeten worden. Dit zal ook vaak leiden tot het testen van de nonfunctionele kwaliteitsattributen. Het voordeel van de 2-D TRA is dat deze het meest nauwkeurig is en het beste aansluit bij het beoogde resultaat. De 2-D TRA brengt de risico s voor de business in kaart en nodigt daarbij uit om verder te kijken dan de systeem- of requirementsspecificaties. De Testrisicoanalyse kan aantonen dat er een risico is dat niet in het systeemontwerp is geadresseerd. Als dit tijdig geconstateerd wordt, kan dit risico verwerkt worden in het ontwerp. Op deze wijze wordt er een fout voorkomen nog voordat deze gecodeerd is. 98
7 Testrisicoanalyse Binnen de testwereld is risicogebaseerd testen een begrip. Toch zijn er nog steeds veel organisaties waar het risicogebaseerd testen nog geen gemeengoed is. De ervaring leert dat het in veel organisaties moeilijk is om de discipline en tijd op te brengen voor het uitvoeren van de 2-D TRA. Niet alleen kost het opstellen van een 2-D TRA meer tijd dan het opstellen van een 1-D variant; ook de opdrachtgever zal soms weinig ruimte geven aan een proces dat vraagtekens zet bij het systeemontwerp. Verstandig of niet, er zijn projecten waarbij de opdracht afdwingt dat het systeem conform het ontwerp wordt gerealiseerd. Met de testen wil de opdrachtgever aantonen dat het systeem conform specificaties werkt. Hij heeft er geen belang bij om aan te tonen dat het ontwerp beter kan. In deze situaties voldoet de eendimensionale TRA vaak wel. Deze TRA is relatief snel op te stellen, is makkelijk te begrijpen en geeft toch duidelijke handvatten om testdiepte te differentiëren. Tevens helpt de 1-D TRA de volgorde van de testuitvoering te bepalen. Aan de hand van de 1-D TRA is het mogelijk het risicogerelateerd denken te introduceren. Als de organisatie de voordelen van risicogebaseerd testen ervaart, kan altijd de stap naar 2-D TRA gemaakt worden. Kortom: een 1-D TRA zou altijd uitgevoerd moeten worden. Als er ruimte en tijd is voor de 2-D TRA, overweeg dan deze toe te passen. Testen is het reduceren of wegnemen van risico s. Het is daarbij de kunst om een strategie te kiezen waarbij op een zo efficiënt mogelijke wijze inzicht wordt verkregen in de werkelijke risico s. Het is dan ook belangrijk om de resultaten van de testen te kunnen herleiden tot de geïdentificeerde risico s. Tijdens en na het testen rapporteert de tester over de resultaten van de testen. Door in de testrapportage aan te geven hoe het testen bepaalde bedreigingen heeft weggenomen, toont hij de toegevoegde waarde aan van het testen en geeft hij aan over welke zaken het businessmanagement zich geen zorgen meer hoeft te maken. Door in de testrapportage het beoogde resultaat aan de TRA te koppelen, ontstaat er gaandeweg steeds meer zekerheid over de kwaliteit van het systeem. Dit is weergegeven in de volgende figuur. 99
TestGoal, resultaatgedreven testen Resultaat Rapportage 1-D TRA 2-D TRA Testen Figuur 7.1 De cirkel van resultaat naar resultaat: de figuur geeft aan hoe TRA, testen en testrapportage het beoogde resultaat als begin- en eindpunt hebben Figuur 7.1 geeft aan dat het vertrekpunt van alle testactiviteiten het beoogde resultaat is. De TRA brengt in kaart welke risico s dit resultaat bedreigen. Hieruit kan worden afgeleid welke punten de meeste aandacht behoeven tijdens het testen. Het testen zelf is een activiteit om te onderzoeken in welke mate de risico s reëel zijn. Is de tester bijvoorbeeld bang dat door een rekenfout de facturen foutieve bedragen bevatten, dan kan hij de berekening testen. Door aan te tonen dat de berekening geen fouten bevat, heeft hij het risico geëlimineerd; zie de bespreking van de testrapportage. De tester herleidt de testresultaten naar de eerder vastgestelde risico s en kan hierdoor uitspraken doen over de mate waarin hij denkt dat het beoogde resultaat werkelijk behaald gaat worden. In principe is het niet wenselijk dat er voor elk testtraject een eigen Testrisicoanalyse wordt gemaakt, dit is namelijk niet efficiënt. Daarnaast dienen alle aan het ontwikkeltraject gerelateerde activiteiten hetzelfde resultaat na te streven en geldt er dus voor alle betrokkenen dezelfde Testrisicoanalyse. Dus de TRA kan het beste testtrajectoverstijgend worden uitgevoerd. Soms is er echter geen algemene Testrisicoanalyse beschikbaar en is het ook niet mogelijk om deze op testtrajectoverstijgend niveau vast te stellen. In dat geval dient de testcoördinator zorg te dragen voor zijn eigen TRA. In de volgende paragraaf wordt uitgelegd hoe een TRA tot stand komt. 100
7 Testrisicoanalyse 7.2 De 1-D testrisicoanalyse 7.2.1 Introductie Voor het uitvoeren van een eendimensionale testrisicoanalyse wordt een Testboom gedefinieerd. Een Testboom is een decompositie van het testobject in functies en aandachtsgebieden. Tijdens de Testrisicoanalyse wordt per tak van de boom ingeschat wat het relatief belang is. Het resultaat is een eendimensionale risicomatrix. Dit is in feite een lijst met daarin de naar relatief belang gesorteerde risicogebieden, zie tabel 7.1. Risicocategorie Risicogebied Relatief belang Kritisch Hoog Midden Laag Routeber.-Standaard ber. Navigatie-Invoeren bestemming Routeber.-Zoek alternatief Accuratesse Navigatie-Favorietenlijst Gebruikersgemak Routeber.-Route type Extra-File-info Performance Navigatie-Recente bestemming Navigatie-Huis Extra-Weerbericht Instellingen-Audio Instellingen-Kaarten Instellingen-Standaard 270 150 117 99 80 65 63 45 45 20 15 9 8 6 6 Tabel 7.1 Een eendimensionale risicomatrix De Testrisicoanalyse wordt uitgevoerd tijdens een workshop waarbij verschillende belanghebbenden aanwezig zijn. De belanghebbenden kunnen vanuit hun expertise en werkveld de functies en aandachtsgebieden identificeren en van een prioriteit voorzien. De TRA wordt georganiseerd door de moderator die hierbij als procesbegeleider fungeert. Hij is degene die de TRA-sessie organiseert en na afloop de gegevens verwerkt. Vaak fungeert de testcoördinator als moderator. 101
TestGoal, resultaatgedreven testen Bij het tot stand komen van de eendimensionale TRA doorlopen we de volgende stappen. 1. Identificeren belanghebbenden en kick-off. 2. Vaststellen van de functies en aandachtsgebieden. 3. Bepalen van het relatief belang. 4. Verwerken van de gegevens. 5. Accorderen van de TRA. In de volgende paragrafen worden de stappen nader toegelicht. 7.2.2 Identificeren belanghebbenden en kick-off Tijdens de Inventarisatie beoogd resultaat is er waarschijnlijk al stilgestaan bij de belanghebbenden van het project. Deze belanghebbenden worden nu door de moderator benaderd voor het uitvoeren van de TRA. Als het goed is, vertegenwoordigen de belanghebbenden een aantal verschillende disciplines. Verschillende belanghebbenden hebben waarschijnlijk verschillende visies op het beoogde resultaat en de risico s [Thompson, 2004]. Het betrekken van verschillende disciplines helpt om een evenwichtige en doordachte risicoinschatting te krijgen. Denk aan: De afnemers gebruikers, businessmanager of beheerders. De bouwers analisten, systeemontwerpers of programmeurs. Projectverantwoordelijken projectmanagers of opdrachtgever. Nadat de deelnemers van de TRA zijn geselecteerd en uitgenodigd, is het moment aangebroken om een kick-off te houden. De moderator legt uit waarom de TRA gehouden wordt, hoe de TRA in zijn werk gaat en wat er van de belanghebbenden wordt verwacht. Het is belangrijk dat elke deelnemer aan de TRA deskundig genoeg wordt bevonden door de groep die hij vertegenwoordigt. Dit zorgt dat de deelnemer onderbouwde uitspraken kan doen over de prioriteit. Het zorgt er ook voor dat zijn inschatting door zijn achterban wordt geaccepteerd. Dit lijkt misschien een klein issue, maar dit is toch belangrijk, bijvoorbeeld in het volgende geval: Voorbeeld 7.1: Een webapplicatie Binnen de organisatie wordt een webapplicatie gebouwd waarmee klanten bestellingen kunnen plaatsen. Tijdens de TRA geeft de projectleider aan dat er weinig tijd beschikbaar is. Hierdoor zullen er concessies moeten worden 102