Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Ultieme testaanpak: requirements vs. risico’s

 

Expert

Christian Hoppenbrouwers
Directeur Salves Testservices West, Salves. Expert van voor het topic .

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

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3182200). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Ik herken wel wat je zegt. Als tester werk je nu eenmaal veelal voor of een leverende partij of een accepterende partij. Deze kunnen tegenstrijdige belangen hebben die nog wel eens kunnen botsen.

Ik ben het niet helemaal met de stelling dat de testwereld hier een steek heeft laten vallen, laat staan dat wat hier staat echt vernieuwend is. TMap betrekt in haar PRA aanpak beide partijen en maakt hier gebruik van testdoelen, kwaliteitsattributen en risico's. Hiermee kan wel degelijk een brug geslagen worden tussen de requirements en risico's.

Ik ben het helemaal met Bart eens. Dit is zeker geen nieuwe materie en ik lees hier niets dat ik niet in minstens 2 andere methoden al gezien heb.

Bart en Michael als mede schrijver van dit artikel ben ik erg benieuwd naar jullie bewijzen..

ik ben namelijk van mening dat deze laatste stap nergens wordt gemaakt om risico's en requirements op deze manier ten opzichte van elkaar te plaatsen. In het boek testmanagement komt men er wel heel dicht bij maar maakt men niet de laatste stap om juist beide op basis van prioriteiten ten opzichte van elkaar uit te zetten.
Maar ik houd mij aanbevolen als jullie die wel ergens in de literatuur hebben gevonden..

Bart & Michael,

Ik ben het met jullie eens dat de beide onderwerpern, risico's en acceptatiecriteria in meerdere testmethoden genoemd worden. Waar Ard echter een nieuwe opening heeft gevonden is door deze twee tegenover elkaar te zetten en hierdoor een nieuw gezichtpunt creeert waarmee we als testers toegevoegde waarde leveren aan het begin van een project.

Het vernieuwende is dus de combinatie.

Even een vraag voor jullie. Wie was de uitvinder van de fiets?
- diegene die het wiel e/o de ketting heeft uitgevonden
- of diegene die deze bij elkaar heeft gebracht en er een fiets van heeft gemaakt...

Zover ik weet gaat het bij RRBT (Risk & Requirement Based Testing) zoals beschreven in Testmanagement, een integrale aanpak (2003), juist over het afwegen van risico's en requirements. De fase risk&requirements matching is een van de peilers van deze aanpak. Tijdens deze stap wordt gecontroleerd aan de hand van de risico's of re requirements compleet zijn en welke risico-prioriteit aan de requirements (naast de het belang van het requirement zelf) wordt toegekend. Dus ja deze aanpak is goed maar niet nieuw!

@Chris,

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?
Het is zeker gebaseerd op RRBT, maar het is in mijn ogen zeker een extra stap.

@testert
Hoofdstuk 2 gaat daarover. par 2.4 gaat over req/risc matching. Daar komt tot uitting dat nice to haves met een hoog risico of eerst getest moeten worden of niet gebouwd moeten worden. in 2.3 gaat het over de Strategic Test Slicing Method die beslising ondersteunt om obv de risico's delen al dan niet te testen.
Overigens, in de laatste versie van TestFrame wordt ook een aandacht aan dit onderwerp besteed: hoofdstuk 4 gaat over het opstellen van testcondities waarbij zowel de functionele prio (het belang voor de org) en de risicoprioriteit worden gewogen.

@chris,

interessant verwijzingen Chris naar RRBT, maar ik heb het nagelezen en er staat nergens letterlijk dat requirements kunnen afvallen als ze nice to have zijn en een hoog risico hebben......

Interessant artikel; Ik hou me hier in mijn huidige opdracht ook mee bezig en heb er veel over nagedacht.
M.i. kun je risico's en requirements niet los zien van elkaar, maar juist in elkaars verlengde. Een requirement is een maatregel om je risico te vermijden of te mitigeren. Een requirement (of ICT in het algemeen) is slechts een van de mogelijkheden om risico's te beperken.
Een nice-to-have requirement kan dan volgens mij ook nooit gelinkt zijn aan een hoog productrisico.
Ik stel nu de product risico's als hoogste "orde", om het uiteindelijke proces (inclusief systeem) te accepteren.

Interessant artikel, volgens mij gaan Iris Pinkster en Bob van de Burgt hier op in in hun boek "Succesvol Testmanagement".
Oude wijn in nieuwe vaten lijkt mij derhalve, eens met hetgeen Chris aangeeft.

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×