PRA – de Broodnodige Start van elk Testtraject
Je kunt elke test-Euro maar één keer uitgeven, dus je wilt testen en toetsen gericht inzetten. Een Product Risico Analyse (PRA) kan je daarin ondersteunen. Wat is een PRA? In een notendop: je vraagt aan de stakeholders welke risico’s worden ervaren. Zo ontstaat een gedragen beeld van de risico’s die worden gelopen – en kun je gericht maatregelen definiëren, waaronder testen en toetsen.
Als we onbeperkte resources (tijd, geld en personeel) zouden hebben, dan zouden we “alles” kunnen testen. Helaas is de werkelijkheid anders en moeten we keuzes maken. Een PRA-sessie helpt bij het maken van keuzes op gebied van testen en toetsen – en andere mitigerende maatregelen.
In een PRA-sessie geven de stakeholders aan welke risico’s zij ervaren: wat gebeurt er als iets het niet -of niet goed- doet? Risico’s worden gescoord op Kans en Impact (kosten, schade). Op basis daarvan bepalen we welke onderdelen we “zwaarder”, “normaal” en “lichter” willen testen. Op die manier besteed je je testbudget heel gericht aan de grootste risico’s. En pak je de ernstigste risico’s als eerste aan.
De testmanager of -coördinator helpt bij het kiezen van de testontwerptechnieken die het beste toe te passen zijn, gegeven een bepaalde zwaarte.
Werkvorm PRA varieert
De werkvorm van een PRA kan variëren: veelgebruikte methodes zijn “stickeren” (meer stickers = meer risico/belang) of het toekennen van punten per Functie. Elk van de elementen landt dan in een kwadrant van de onderstaande risicomatrix.
Ook de indeling/verdeling van de kleuren over het vlak kan afwijken.
Wat betekenen de kleuren?
Landt een onderwerp (functie, systeemdeel, proces) in de rode zone, dan willen we daar méér zekerheid over hebben en dan zullen we éérder en intensiever testen. Landt een onderwerp daarentegen in de groene zone, dan volstaat minder diepgaand (en later) testen.
Van PRA naar Teststrategie
Op basis van het aantal elementen in een specifieke zone, het beschikbare budget, de beschikbare tijd én de aanwezige skills van de testers, kan een testconsultant een voorstel doen voor een teststrategie. In deze strategie staat wie, wat, wanneer, hoe en waarmee zal testen en over welke andere mitigerende maatregelen (anders dan “testen”) we eventueel beschikken.
Deelnemers aan de PRA
Aan een PRA-sessie kunnen al diegenen deelnemen die een uitspraak kunnen doen over de kans en de impact van fouten in het op te leveren product (het systeem, de output van het systeem). Dat wil zeggen: product owners, systeemeigenaren, eindgebruikers, beheerders, lead engineers en testers maar óók privacy- en security-experts van de organisatie.
De laatstgenoemden vertellen ons iets over kaders waarbinnen we ons moeten bewegen (zoals: privacy- en securityrichtlijnen, architectuur). Dit kan invloed hebben op de gevraagde samenstelling van het bouw- en testteam (skills, ervaring).
Deze groep kan bij uitstek bepalen wie er last van gaan hebben als het systeem niet goed werkt en wat de schade zal zijn:
Hoeveel omzet missen we? Krijgen we boetes? Loopt ons imago een deuk op? Kunnen collega’s hun werk niet meer doen – of alleen nog door omwegen te bewandelen? Wat kan een uur, dag of week wachten en wat móet juist 24*7 doorgaan? Voor wie is het product? Voor een “doorsnee” collega of voor “De Toezichthouder”? Wordt het product dagelijks gebruikt of “maar één keer per jaar” (en wat als dat dan net de Miljoennenota is?)
Wat kost een hersteloperatie als het mis is gegaan?
Bijkomend voordeel van gezamenlijke deelname aan de PRA: je ziet vaak dat de Business (afnemer) en de IT-leverancier elkaar veel beter begrijpen na zo’n sessie.
Wat is dan “Lichter en Zwaarder Testen”?
Testers zijn in staat om testontwerptechnieken in te zetten die méér of juist minder testgevallen opleveren. Dit heeft gevolgen voor de zgn. testdekking: met méér testgevallen heb je een betere dekking, maar soms is méér niet noodzakelijk beter (bv. in de “groene zone”).
Bij het vaststellen van een teststrategie bepaal je dus wélke testontwerptechnieken je inzet op welk deel van de PRA Matrix.
Een ruw voorbeeld: je zou ervoor kunnen kiezen om alle functies die in de “groene zone” staan, te testen middels een checklist, door de eindgebruiker. Alle elementen in de “oranje zone” betreffen in deze casus condities (beslissingen) en invoer/uitvoer en verlangen daarom testen op basis van equivalentieklassen (EP), grenswaardenanalyse (BVA) en een beslissingstabel (Decision Table). De condities in de “rode zone” testen we op basis van Modified Condition Decision Coverage (MCDC).
NB: De teststrategie wordt ook gevormd op basis van de projectdoelstellingen, de aard van het product, het budget en van de eventuele aanwezigheid (of afwezigheid) van testvaardigheden in het team. Als een team een bepaalde testontwerptechniek niet beheerst, zal voor een “next best” optie gekozen moeten worden.
De Rol van Testautomatisering
Niet alleen wát je wilt testen, maar ook hoe váák je het wilt testen speelt een rol bij het uitstippelen van de teststrategie. Wil je iets vaker testen? Dan zul je snel denken aan testautomatisering.
Neem je alle gerealiseerde testgevallen op in een geautomatiseerde (regressie) testset? Of voer je ze éénmalig uit? Dit heeft direct invloed op de testkosten – op de langere termijn. En maakt het inzetten van “veel testgevallen” wellicht toch eerder nuttig en betaalbaar. Tegelijk moet je goed nadenken over de onderhoudskosten van zo’n (geautomatiseerde) testset.
Andere Mitigerende Maatregelen
Testen en toetsen zijn bekende maatregelen die ingezet kunnen worden voor het mitigeren van de onderkende risico’s. Daarnaast zijn nog talloze andere maatregelen denkbaar: bv. méér ervaren ontwikkelaars verwerven (verlaagt de kans op fouten) of méér beheerders aantrekken (verlaagt de impact van fouten).