7 Testrisicoanalyse

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
Routeber.-Standaard ber.
Navigatie-Invoeren bestemming
270
150
Hoog
Routeber.-Zoek alternatief
Accuratesse
Navigatie-Favorietenlijst
117
99
80
Midden
Gebruikersgemak
Routeber.-Route type
Extra-File-info
Performance
Navigatie-Recente bestemming
65
63
45
45
20
Laag
Navigatie-Huis
Extra-Weerbericht
Instellingen-Audio
Instellingen-Kaarten
Instellingen-Standaard
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