Whitepaper Process Driven Requirements Testing

Whitepaper Process Driven Requirements Testing

Process Driven Requirements Testing

Inleiding Een acceptatietest is een door gebruikers uitgevoerde test met als doel het vaststellen of een oplossing (ICT en non-ICT) voldoet aan de requirements en aansluit op de processen. Deze whitepaper bedoelt met gebruikers de mensen die (delen van) de oplossing gaan gebruiken of beheren. Elke gebruiker is afnemer van de oplossing en heeft er belang bij dat de oplossing correct werkt. Gebruikers kunnen mensen zijn binnen de business (bijvoorbeeld binnen marketing, operations, finance). Andere gebruikers zijn klanten, leveranciers en beheerders van ICT-systemen. Bij acceptatietesten speelt een aantal problemen. Dit document gaat in op drie van deze problemen en reikt handvatten aan om ze te voorkomen.

Probleemstelling 1. Acceptatietesten vinden veelal plaats op basis van systeemdocumentatie en niet tegen de oorspronkelijke requirements. Gevolg is dat de oplossing niet aansluit op de werkelijke gebruikersbehoefte. 2. Een acceptatietest legt een groot beslag op gebruikers. Testen kost hen veel tijd. Tijd die schaars is en ten koste gaat van hun dagelijks werk. 3. Bij de oplevering van een project is niet altijd duidelijk: Welke requirements binnen de scope waren. Of ze gerealiseerd zijn. Of ze expliciet getest zijn. Wat de uitkomst van de test was. Kostbare tijd gaat verloren om dit uit te zoeken.

Process Driven Requirements Testing (PDRT) Process Driven Requirements Testing (PDRT) is een acceptatietest methode die vanuit gebruikers perspectief de oplossing toetst. Het is een aanvulling op de systeem(keten)test welke met name de werking van ICT-systemen beoordeelt.

een project. PDRT neemt met andere woorden niet de systeemdocumentatie als uitgangspunt. Die documentatie beschrijft namelijk hoe de requirements worden gerealiseerd. De gebruikers zijn actief betrokken bij het bepalen welke requirements en processen kritiek zijn en grote impact hebben op hun dagelijks werk. Hierdoor creëert PDRT een afgewogen risicoanalyse met risico’s vanuit business én ICT perspectief.

Gebruikers zoveel mogelijk ontlasten PDRT biedt een vaste structuur voor testgevallen. Het format en de methode staan vast. Daardoor kan de testuitvoering eenvoudig worden uitbesteed aan professionele testers en kunnen gebruikers tijd besteden aan hun echte werk. Kortom, PDRT zet gebruikers in waar ze het meest van toegevoegde waarde zijn en houdt rekening met hun dagelijkse werk.

Track en trace Projecten creëren veel documentatie waarin requirements, processchema’s, testgevallen en dergelijke staan. Echter, het verband tussen (de juiste versies van) die elementen is lastig of niet te vinden. PDRT lost dit probleem met een Requirements Traceability Matrix (RTM) die de samenhang weergeeft tussen requirements, processen, testscripts, (ICT-)oplossingen, et cetera. Door deze informatie in de RTM op te slaan en in overige documenten ernaar te verwijzen worden overlap en duplicatie voorkomen. Zo bespaart PDRT veel zoektijd.

Wat vertelt deze whitepaper over PDRT? PDRT is een aanvulling op bestaande test® ® methoden, zoals ISTQB en TMap NEXT . Omdat deze methoden noch technieken kennen om vanuit processen en requirements een risicoanalyse op te stellen noch handvatten aanreiken om op basis van requirements testcases te maken, biedt PDRT de benodigde aanvullingen. Deze whitepaper beschrijft met name hoe acceptatietestgevallen worden opgesteld.

Business requirements en risico’s zijn leidend PDRT gaat uit van testen op basis van de business requirements. Business requirements (hierna: requirements) zijn de verzameling eisen die gebruikers stellen bij aanvang van

ICT zonder risico

Pagina 2 van 10


Processen als brug tussen requirements en oplossing Een requirement maakt een reis door diverse documenten, voordat het uiteindelijk vertaald wordt naar een oplossing. De testbasis om deze oplossing te testen, bestaat doorgaans uit documenten zoals functionele en technische ontwerpen en niet de oorspronkelijke requirements. De vraag is dan of de test wordt uitgevoerd tegen de juiste testbasis. En of de acceptatietest een uitspraak kan doen of de oplossing aansluit op de gebruikersbehoefte. Zelfs als de requirements goed worden geïmplementeerd, dan nog is het voor de gebruiker moeilijk om zijn requirements te herkennen in de oplossing. En hoe weet een gebruiker dat een requirement niet is geïmplementeerd? Door in plaats van de ontwerpen en de systemen, de requirements als uitgangspunt te nemen, kunnen bovenstaande problemen worden voorkomen. Maar hoe verbind je de requirements met de oplossing als je de ontwerpdocumenten niet kunt gebruiken?

Een proces vormt namelijk het bindende element tussen de requirements enerzijds en de oplossing anderzijds (zie afbeelding 1; links staan de requirements, in het midden het proces en rechts de oplossing). Immers, de requirements hebben betrekking op processen en de oplossing ondersteunt deze processen. Daarnaast biedt het centraal stellen van processen nog een aantal andere voordelen: Prioritering Processen zijn te onderscheiden in bedrijfskritische en niet-bedrijfskritische processen. Processen kennen een frequentie waarin ze voorkomen en hebben impact op een organisatie. Frequentie, impact en belang van processen zijn vanuit business perspectief belangrijke aspecten om te prioriteren. Herkenning Gebruikers zijn vertrouwd met hun processen. Ze werken er dagelijks mee. Acceptatietesten beschreven in termen van processen verbeteren de communicatie tussen gebruiker, tester en ICT.

Het antwoord is eigenlijk eenvoudig: gebruik de processen als brug tussen de requirements en oplossing.

Afbeelding 1. Processen als brug

ICT zonder risico

Pagina 3 van 10

Stappenplan

Procesniveaus

PDRT hanteert een stappenplan om vanuit de requirements tot acceptatie van de oplossing te komen: 1. Opstellen risicoanalyse. Koppelen requirements aan processen en producten. Identificeren gebeurtenissen (business events) die een proces triggeren en opstellen business use cases (BUC’s). Koppelen oplossingen aan BUC’s. Opstellen risicoanalyse. 2. Opstellen testgevallen. 3. Uitvoeren acceptatietesten. 4. Afsluiten acceptatietest.

PDRT onderscheidt vier hiërarchische procesniveaus. Als voorbeeld staat achter elk niveau tussen haakjes een proces voor een online webshop. 1. Keten (Inkopen-Verkopen-Factureren) 2. Bedrijfsproces (Verkopen) 3. Werkproces (Bestellen) 4. Activiteit (Bevestigen bestelling)

Stap 1 gebeurt in twee fases. Eerst wordt op globaal niveau inzicht verkregen in de risico’s. Daarna vindt verdieping van de risicoanalyse plaats. Bij kleine projecten worden beide iteraties geïntegreerd tot één stap.

Een voorbeeld

Stap 1. Opstellen risicoanalyse Het doel van een risicoanalyse is om te identificeren welke processen, requirements en onderdelen van de oplossing van belang zijn om te testen. Voor het testen bestaan grenzen in tijd en geld, waardoor een project afwegingen moet maken waar ze haar testtijd en geld in steekt.

Koppelen requirements PDRT gaat er van uit dat de requirements aanwezig en geaccordeerd zijn. En dat er een beschrijving of schema van de processen bestaat. Per requirement wordt onderzocht op welk proces of product het requirement betrekking heeft (zie afbeelding 2). Een product is een input of output van een proces.

Deze hiërarchie is ook van toepassing op requirements. Een globale requirement geldt voor een gehele keten, bedrijfsproces of werkproces. Een detail requirement geldt voor een specifieke activiteit binnen een werkproces.

Requirement A luidt: “Tijdens het bestellen ziet de klant op elk moment de inhoud van zijn winkelwagentje”. Dit requirement geldt voor het gehele werkproces Bestellen, dus alle activiteiten hierin. PDRT noemt dit een globaal requirement. Requirement B luidt: “Als de klant de order bevestigt, moet hij ook de verkoopvoorwaarden accepteren”. Dit requirement hoort alleen bij de activiteit “Bevestigen bestelling”. PDRT noemt dit een detail requirement. Koppeling van een detail requirement aan een keten, bedrijfsproces of werkproces voegt geen waarde toe: het is namelijk niet duidelijk voor welke stap in het proces het requirement geldt. Koppeling van een globale requirement aan een activiteit is weinig zinvol, omdat het requirement ten opzichte van de activiteit te globaal geformuleerd is, waardoor deze niet te testen is. Afbeelding 3 toont het tabel waarin de detail requirements worden gekoppeld aan activiteiten.

Afbeelding 2. Koppelen requirements aan processen, input en output

Het is zaak dat een requirement aan het juiste procesniveau gekoppeld wordt. Zie ook het kader over procesniveaus hiernaast. Afbeelding 3. Tabel requirements en activiteiten


Identificeren business events en business use cases Procesmodellen tonen hoe processen met elkaar samenhangen. Ze laten echter niet eenvoudig de volgorde van processen zien naar aanleiding van een bepaalde gebeurtenis. Deze extra dimensie wordt een business use case (BUC) genoemd. Een BUC beschrijft hoe een gebeurtenis (business event) wordt afgehandeld in combinatie met randvoorwaarden (precondities). De BUC doorloopt een aantal processen van een bepaald procesniveau en leidt tot een resultaat, bijvoorbeeld een product, dienst of halffabricaat (zie afbeelding 4).

Op deze manier worden requirements en oplossing, via de processen, aan elkaar geknoopt (zie afbeelding 6).

Afbeelding 6. Oplossing koppelen aan BUC’s

Zo wordt duidelijk welke ICT-systemen en handmatige oplossingen welke processen ondersteunen. Op het niveau van ketens, bedrijfs- en werkprocessen legt PDRT koppelingen met bijvoorbeeld systemen of interfaces uit de ICT architectuur. Op het niveau van activiteiten met systeemfuncties en schermen. De informatie over de oplossing haalt PDRT voor een globale risicoanalyse uit de globale impactanalyse van ICT en business en uit schema’s van de ICT architectuur.

Afbeelding 4. Business use case structuur

Een business event is bijvoorbeeld het plaatsen van een order. De preconditie is dat dit door een bestaande klant wordt gedaan (NAW-gegevens zijn al bekend). De klant doorloopt het orderproces en aan het eind daarvan heeft hij een order geplaatst. Het resultaat is derhalve een order.

De samenhang van de oplossing met de processen uit de BUC’s komt terug in een tabel (zie afbeelding 7).

Met het opstellen van de BUC’s wordt feitelijk de tabel uit afbeelding 3 verder uitgebreid. Voor elke BUC wordt een tabel opgesteld zoals te zien in afbeelding 5.

Afbeelding 7. Samenhang processen uit de BUC met de oplossing

Globale risicoanalyse Het opstellen van een risicoanalyse vindt voor grote en complexe projecten plaats in twee fases. Eerst stelt PDRT een globale risicoanalyse op vanuit business en ICT perspectief. Voor een globale risicoanalyse is informatie nodig op een ‘hoog’ niveau met betrekking tot requirements, BUC’s en oplossingen.

Afbeelding 5. Requirements opgenomen in BUC

Koppelen oplossing Nadat inzichtelijk is welke BUC’s samenhangen met welke requirements, koppelt PDRT de oplossing aan de BUC’s.

Op business niveau voert PDRT een analyse uit op het belang en de impact van de requirements en BUC’s op de organisatie. De BUC’s hebben bij een globale analyse betrekking op de ketens, bedrijfsprocessen of werkprocessen.

ICT zonder risico

Pagina 5 van 10


Vanuit ICT perspectief analyseert PDRT de risico’s verbonden met de systemen en interfaces in de ICT architectuur. Risico’s worden in verband gebracht met complexiteit en foutgevoeligheid van systemen, de mate waarin er expertise is over de systemen, et cetera. Vervolgens integreert PDRT de business- en ICT-risico’s en volgt een afgewogen beeld welke BUC’s/oplossingen moeten worden getest en met welke mate van diepgang.

Detail risicoanalyse Voor een detailanalyse maakt PDRT een verdieping op de BUC’s die getest gaan worden. Er blijven met andere woorden ook requirements en BUC’s buiten beeld van de acceptatietest. In de RTM staat welke requirements en BUC’s buiten scope liggen, zodat het altijd inzichtelijk is, wat wordt getest en wat niet. De te testen BUC’s worden nader geanalyseerd op –voor testen- nieuwe relevante business events. Deze events krijgen een waardering op basis van hun belang, impact en frequentie. Daarmee ontstaat een compleet beeld welke business events en bijbehorende BUC’s en requirements in de test meegaan.

scherm, te ondernemen testacties en het verwachte testresultaat plaatst PDRT in de BUC’s. Deze informatie wordt aan de rechterkant van de BUC toegevoegd (zie afbeelding 8). Nu ontstaat een totaaloverzicht dat alle partijen begrijpen: aan de linkerkant het proces en de requirements in heldere taal voor de gebruikers en aan de rechterkant de testgevallen voor de tester.

Stap 3. Uitvoeren acceptatietesten Zodra de oplossing, of een deel ervan opgeleverd is aan het testteam, start de testuitvoering. De helder beschreven testgevallen maakt de testuitvoering logisch en eenvoudig. Feitelijk voert een tester de BUC’s uit, waarbij stap voor stap de processen worden uitgevoerd in samenhang met de ICT oplossing en andere procedurele oplossingen. In het testgeval (afbeelding 8) staan rechts twee kolommen die worden ingevuld door de tester. Hij geeft aan wat het testresultaat is en of de test OK is. Over het uitvoeren van acceptatietesten is nog veel meer te vertellen. Denk aan aspecten met betrekking tot testtechnieken, bevindingenregistratie, testomgevingen, et cetrea. Echter, voor deze whitepaper gaat het te ver om hier stil bij te staan.

Stap 4. Afsluiten acceptatietest Afbeelding 8. BUC aangevuld met informatie over de oplossing en testinstructies

Stap 2. Opstellen testgevallen Voor de nieuwe en bestaande business events worden de BUC’s op het niveau van activiteiten ontworpen. Er vindt een koppeling plaats tussen de detail requirements en de activiteiten uit de BUC’s. Bovendien verbindt PDRT aan elk requirement een oplossing, bijvoorbeeld een scherm, procedure of rapport. Om te weten welke oplossing bij welk requirement hoort, is input nodig vanuit de functionele ontwerpen en detail impactanalyses van business en ICT. Het uitschrijven van de testgevallen is gebaseerd op de structuur van de BUC’s (zie afbeelding 5). Informatie zoals het te tonen

PDRT sluit de acceptatietest af met het vrijgave advies. Een belangrijk hulpmiddel hierbij is de RTM. Hierin staat welke requirements zijn afgetest en akkoord bevonden en welke requirements nog opstaande bevindingen kennen. De RTM helpt bovendien bij het vinden wie de eigenaar is van een requirement, om mee af te stemmen hoe ernstig een openstaande bevinding is. Immers, via de RTM is traceerbaarheid gewaarborgd van testresultaat, naar testgeval, naar oplossing, naar requirement, naar eigenaar van een requirement.

Requirements Traceability Matrix (RTM) Een requirements traceability matrix (RTM) is het overzicht, meestal in de vorm van tabellen, dat de samenhang weergeeft tussen verschillende elementen, zoals stakeholders of gebruikers, requirements, business events,

ICT zonder risico

Pagina 6 van 10


BUC’s, ICT-systemen, procedurele oplossingen en testgevallen. Afbeelding 9 toont een gesimplificeerd, logisch model van een RTM. Elk element kent een tabel, bijvoorbeeld een tabel voor requirements, een tabel voor stakeholders. Behalve deze tabellen worden ook de relaties tussen gegevens uit de tabellen vastgelegd.

Elke organisatie bepaalt zelf welke elementen ze wil vastleggen en waar ze relaties tussen wil leggen. Een RTM is daardoor altijd op maat.

Minder documenten Projecten kennen doorgaans veel documenten met veel proza. De inhoud van die documenten kan overlappend, redundant en tegenstrijdig zijn. Requirements kunnen bijvoorbeeld in meerdere documenten voorkomen met verschillende versies of zijn niet herkenbaar in de documenten, maar staan als tekst verstopt tussen andere tekst. De samenhang tussen de documenten kan vragen opleveren. Bijvoorbeeld processchema’s staan over meerdere documenten verspreid zonder onderlinge samenhang. Of in functionele ontwerpen of use cases staan verwijzingen naar processen waarbij de verwijzingen onjuist zijn. Kostbare tijd gaat door deze zaken verloren aan lezen en interpreteren. De RTM ondervangt dit probleem door als centrale opslag te fungeren. Relevante elementen uit documenten krijgen met de RTM een centraal opslagpunt. Vanuit projectdocumenten zoals een functioneel ontwerp of impactanalyse kan worden gerefereerd naar elementen uit de RTM. Door alleen te refereren blijft de informatie op slechts één plaats opgeslagen.

Afbeelding 9. Model van een RTM

In het voorbeeld in afbeelding 9 wordt requirement r2 gekoppeld met stakeholder S2. Requirement r2 wordt ook gekoppeld met proces P4. De combinatie van r2 en P4 wordt in BUC B2 beschreven. Systeem R1 ondersteunt proces P4, en de testgevallen ts2, ts3 en ts4 testen het requirement r2. Op deze manier is precies na te gaan welk testgeval welk requirement afdekt. Het is ook mogelijk om na te gaan welke requirements niet door testgevallen zijn afgedekt. Omgekeerd is het ook mogelijk om te controleren welke requirements door een bepaald testgeval zijn afgedekt.

Genereren van documenten De RTM is bovendien een middel om bijvoorbeeld testgevallen uit te genereren. Immers, alle gegevens van een testgeval zoals PDRT die voorschrijft, staan in de RTM. Testen bestaat voor een belangrijk deel uit het opstellen van testgevallen. Deze testgevallen bevatten gegevens die al eerder zijn vastgelegd, zoals een BUC en requirements. Dan is het efficiënt als de gegevens slechts éénmaal hoeven te worden geregistreerd en testgevallen kunnen worden gegenereerd uit een centraal opslagmiddel.

Inzet van gebruikers bij PDRT

Uitbreidbaarheid en op maat De RTM structuur laat zich eenvoudig uitbreiden met elementen die meer projectgerelateerd zijn, zoals change requests, projecten, sprints of releases. Door koppeling van een requirement aan bijvoorbeeld een release, is het eenvoudig na te gaan wanneer een requirement wordt opgeleverd.

Acceptatietesten leggen een groot tijdsbeslag op gebruikers. Enerzijds begrijpen gebruikers dat ze een belangrijke rol spelen bij de acceptatie van een oplossing. Maar anderzijds hebben ze er relatief weinig tijd voor. Hun dagelijks werk gaat gewoon door, ook al plannen ze projecttijd in. Zodra er iets misgaat

ICT zonder risico

Pagina 7 van 10


in de operatiën, dan gaan die problemen uiteraard voor en krijgt de acceptatietest een lagere prioriteit. PDRT heeft door zijn aanpak een logische en werkbare knip gelegd tussen waar gebruikers een grote toegevoegde waarde hebben en waar ze die minder hebben. Gebruikers zijn met name intensief betrokken bij stap 1 van PDRT. Stap 1 is het opstellen van een risicoanalyse. Dat kan alleen gebeuren door mensen die verstand hebben van de organisatie, processen en ICT architectuur. Daar hebben gebruikers dan ook de hoogste toegevoegde waarde voor de acceptatietest. Bij stap 2 en 4 spelen gebruikers een reviewende rol. Voor het opstellen van de BUC’s in stap 2 is een check door gebruikers waardevol, omdat BUC’s over hun processen en requirements gaan. Stap 4 betreft het afsluiten van de test en het adviseren over in productiename van de oplossing. Het uitbrengen van het advies kan weliswaar door derden gebeuren, maar niet het goedkeuren van het advies. Daar spelen gebruikers de hoofdrol. Stap 3 tot slot, gaat over de testuitvoering. Deze kan zonder problemen volledig worden uitbesteed aan derden. Hooguit zouden gebruikers betrokken kunnen worden bij het testoverleg waar de testbevindingen worden doorgesproken.

Afbeelding 10. Procesmodel voor het bestellen op basis van een bestaande offerte

Voor elke activiteit in het procesmodel bestaan enkele requirements (zie afbeeldingen 11, 12 en 13).

Afbeelding 11. Requirements voor activiteit ‘Ophalen bestaande offerte’

Voorbeeld case Aan de hand van een fictief autoleasebedrijf demonstreert onderstaande case de PDRT aanpak om tot testgevallen te komen.

Afbeelding 12. Requirements voor activiteit ‘Bevestigen offerte’

Het leasebedrijf wil haar verkoopproces zodanig veranderen dat 90% van haar omzet online verloopt. Een projectteam heeft de taak gekregen om de processen en website hiervoor aan te passen. In de voorbereiding heeft de business analist, samen met de gebruikers, de requirements opgesteld, het procesmodel in kaart gebracht en de business events geïdentificeerd. Een klant kan online een offerte opvragen, die hij eerder heeft aangevraagd bij het autoleasebedrijf. Deze offerte kan hij vervolgens omzetten naar een bestelling. Zie afbeelding 10 voor het bijbehorende procesmodel met een drietal activiteiten.

Afbeelding 13. Requirements voor activiteit ‘Bestellen’

Na het koppelen van de requirements aan de activiteiten, worden de business events en business use cases bepaald. Een van de business events is dat de klant een bestaande offerte wil opvragen.

ICT zonder risico

Pagina 8 van 10


Bij dit event horen de volgende precondities: 1. Bestaande klant die al is ingelogd. 2. Er is een geldige offerte (de offerte is jonger dan 31 dagen EN op basis van de offerte is nog geen auto besteld). Het business event wordt afgehandeld door een business use case met als titel ‘Bestellen op basis van bestaande geldige offerte’. Het verwachte resultaat ná het uitvoeren van de business use case is: 1. De bestelling is geplaatst. 2. De klant ontvangt een elektronische bevestiging van zijn bestelling. 3. De order wordt doorgestuurd naar het bedrijfsproces “Beheren wagenpark”. 4. De order wordt binnen 24 uur doorgestuurd naar het bedrijfsproces “In/excasseren”. Met voorgaande informatie wordt de template van de BUC ingevuld (zie afbeelding 14). Alleen die requirements die relevant zijn voor de BUC zijn opgenomen. De overige requirements zijn weggelaten.

Afbeelding 14. BUC ‘Bestellen op basis van bestaande geldige offerte

ICT zonder risico

Pagina 9 van 10


Het autoleasebedrijf gebruikt het systeem CARS. In CARS worden schermen toegevoegd om het online verkoopproces te ondersteunen. In afbeelding 15 staat de schermopbouw die hoort bij de BUC uit het voorbeeld.

In CARS komt nieuwe functionaliteit om offertes door klanten te laten beheren en om andere bedrijfsprocessen aan te sturen. Afbeelding 16 geeft dit weer. Links staat het proces met de drie activiteiten. Rechts staan per activiteit de database en systeemfuncties van de ICT-oplossing.

Afbeelding 15. Schermopbouw

Afbeelding 16. Koppeling procesmodel ‘Bestellen o.b.v. bestaande offerte’ met ICT-oplossing

Een klant krijgt binnen CARS een eigen omgeving (MyCars) waarin hij persoonlijke zaken, zoals offertes kan beheren. In het scherm MyOffertes heeft de klant de mogelijkheid om zijn offertes te wijzigen en te verwijderen, maar ook de mogelijkheid om offertes om te zetten in een bestelling.

De informatie uit de schermopbouw, de database en systeemfuncties worden aan de BUC in afbeelding 17 toegevoegd. Ook worden er testinstructies aan de BUC toegevoegd, zodat de tester weet welke stappen hij moet uitvoeren. In het voorbeeld moet de tester in directory c:\CARS\ACC\Outbox controleren dat er XML-berichten zijn aangemaakt die de andere bedrijfsprocessen aansturen.

Afbeelding 17. Volledig uitgewerkt testgeval

ICT zonder risico

Pagina 10 van 10

Whitepaper Process Driven Requirements Testing

Recommend Documents