Een opdrachtgever stelde ons eens een eenvoudige vraag: 'Leg mij nu eens uit hoe het testen op basis van requirements en acceptatiecriteria zich verhoudt tot het testen op basis van productrisico’s?'. En zoals dat vaker gaat bij eenvoudige vragen, liet het antwoord even op zich wachten. Sterker, nog niemand kon ons een antwoord op deze vraag geven. Blijkbaar heeft de testwereld hier een steek laten vallen. Wij hebben het antwoord gevonden en het antwoord bleek dermate interessant dat ik er dit jaar een presentatie over heb gegeven op het testcongres van Europa Eurostar.
Om bij het begin te beginnen: testen op basis van requirements en testen op basis van risico's zijn twee verschillende benaderingswijzen. Requirements zijn letterlijk de eisen waaraan het systeem moet voldoen bij zijn oplevering. De projectmanager vraagt aan zijn testmanager om het testproces op basis van de requirements in te richten. De testmanager gaat aan de slag en zorgt ervoor dat hij de belangrijkste eisen (requirements) de meeste aandacht geeft bij het testen en accepteren. Het resultaat is dat aan het einde van het project de acceptatiecriteria afgedekt en afgetest zijn en dat het project kan worden afgesloten.
Bij het testen op basis van risico's wordt veel meer gekeken naar wat fout kan gaan met het systeem als het eenmaal in productie staat. Een fase die voor de projectmanager minder interesseert is, omdat het project is afgesloten en hij uit beeld is. Voor de opdrachtgever is dit echter juist de fase waarin hij geld moet verdienen met het nieuwe systeem of heel veel geld verliest als gevolg van productieverstoringen. Hij wil dus niet worden geconfronteerd met allerlei productieproblemen die door middel van testen vermeden hadden kunnen worden.
De testmanager moet hier dus tijdens het testen ook rekening mee houden. Maar hoe zorgt hij ervoor dat hij de verschillende belangen van zijn twee ‘bazen' kan dienen? Hier geven beide benaderingswijzen onvoldoende antwoord op. Risk based testing kijkt te weinig naar het belang van requirements en requirement based testing let onvoldoende op de productrisico's. Er wordt dus geen stap gemaakt om tot een goede afweging te komen tussen testen op basis van risico's en testen op basis van requirements.
Hiervoor hebben we een ultieme testaanpak ontwikkeld. Om te beginnen moeten beide belangen inzichtelijk worden gemaakt. Hierbij is het indelen naar prioriteiten een belangrijk hulpmiddel. Een voor de hand liggende methode hiervoor is het prioriteren van de requirements volgens de MoSCoW-methode. Risico's kunnen aan de hand van een productrisico-analyse (PRA) van hoog naar laag worden ingedeeld. Het resultaat is de bijgevoegde grafiek waarin duidelijk wordt hoe requirements staan ten opzichte van de risico's.
Op basis van de grafiek kan je aan het begin van je project een testaanpak opstellen. Je bent in staat om een nog betere afweging te maken. Je weet precies in welke fase van het project je een specifiek onderdeel van het systeem door wie moet laten testen. Aan de hand van het bovenstaande schema maak je aan het begin van je project de volgende afwegingen:
1. Het rode kwadrant met de hoogste risico's en de belangrijkste requirements zijn de rode draad voor de testers en de eindgebruikers. Alle testaandacht moet hier vanaf het begin op gericht zijn.
2. Aan de hand van het gele kwadrant trek je de conclusie dat het valideren door de eindgebruikers kan worden afgehandeld. Testers zullen gezien het lage risico hier minder aandacht aan besteden.
3. Het groene kwadrant krijgt zowel voor de eindgebruiker (acceptant) als de tester marginaal aandacht. Het betreft tenslotte ‘nice to have' requirements met een laag risico.
4. Aan het begin van het project zal voornamelijk over het oranje kwadrant gesproken moeten worden. De testmanager zal op basis van de grafiek zijn projectleider en opdrachtgever het advies geven om ‘nice to have' requirements met een hoog productrisico te elimineren uit het project. Je wilt geen onnodige risico's introduceren met extra functionaliteit welke weinig toevoegt aan het systeem.
Aan de hand van de grafiek voer je aan het begin van je project een discussie waarmee je vervolgens voor het hele project een testaanpak definieert. Met deze testaanpak zet je de goede mensen op het goede moment in, dek je de hoogste risico's zo vroeg mogelijk en je zorgt dat je belangrijkste requirements zijn afgedekt. Met behulp van het inzicht is het dus mogelijk om de teststrategie te verfijnen en ‘lean and mean' te testen. Het is noodzakelijk om niet alleen naar de requirements te kijken, maar ook nog naar de prioritering van de requirements! Hier schieten risico en requirement based testing te kort!
Het uiteindelijke resultaat zal zowel de projectmanager als de opdrachtgever tevreden stellen: de requirements zullen worden geaccepteerd maar ook de risico's krijgen de aandacht die het verdient!
Dit artikel kwam tot stand in samenwerking met Ard Kramer van EclipseIT
Ik zie het heel pragmatisch als volgt:
Uiteindelijk wil de klant alle gerealiseerde software ook getest hebben door de leverancier, in de systeemtest, of de gerelateerde requirements nu eerst ‘must have’ of ‘nice to have’ waren.
Gebouwd is gebouwd, de afweging is al gemaakt bij het in scope plaatsen van een requirement.
In de acceptatietest zal een eindgebruiker met zijn kennis van de business meer aandacht willen geven aan de risico’s op productniveau, om schade in productie te vermijden: ‘Must test’ versus ‘should test’.
De eindgebruiker moet er vanuit kunnen gaan, dat de ‘should tests’ in de systeemtest al een keer (minimaal) getest zijn.
De leverancier kan uit de ‘Must test’ versus ‘Should test’ van de aceptatie test afleiden, aan welke systeemdelen hij meer aandacht moet geven in zijn systeemtest.
@Testert,
“Kun je me dan vertellen waar in dat boek dan de risico’s en de requirements tegen elkaar worden uitgezet en op basis van deze plot de inspanning wordt verdeeld. En vooral: waar wordt dan beschriven dat nice to haves met een hoog product risico zouden kunnen worden geelimineerd?”
Zelfs als het er niet zou staan Testert, dan meen ik als professionele tester snel de conclusie te hebben getrokken dat een nice to have requirement het overwegen waard is niet te testen of minder zwaar te testen. De impact op het in te schatten risico is daarmee lager. Andersom ook: een MUST HAVE requirement zal absoluut (zwaarder)getest moeten worden omdat dit als een acceptatie criterium zal gelden (hiermee geeft de klant aan o.b.v. wat zij het eindproduct goedkeurt/decharged).
Het is een bijzonder interessant onderwerp en waardeer elke poging op dit gebied, maar laten wij er als testers ervoor waken niet iets sensationeler te maken dan het is. Het is wellicht onderbelicht maar niet vernieuwend vanuit theoretisch perspectief. Dit houdt ons beroep geloofwaardig.