Invloed van productrisico’s op testen

Het testen wordt wel schematisch weggegeven in de vorm van een piramide. Globaal bestrijkt die piramide de drie niveaus strategisch, tactisch en operationeel. Op strategisch niveau wordt het testbeleid gedefinieerd, op tactisch niveau wordt dit beleid toegepast bij de aansturing van testprojecten. Binnen die projecten worden, op operationeel niveau, de verschillende testsoorten en -typen gestructureerd uitgevoerd met de in het testbeleid gedefinieerde testmethode, -tools en hulpmiddelen. In dit artikel wordt, vanuit de optiek van testvoorbereiding, testontwerp, testuitvoering en rapportage, de samenhang tussen de niveaus dieper uitgewerkt.

Testbeleid

Een testbeleid is een vertaling van de bedrijfsstrategie in richtinggevende voorschriften die een meetbaar kader vormen voor alle testactiviteiten. In het testbeleid wordt vastgelegd aan welke voorwaarden een testproces moet voldoen, volgens welke organisatievorm het testen in het bedrijf wordt ingericht en wat de relatie is met ict- en kwaliteitsbeleid. Een dergelijk, expliciet vastgesteld testbeleid biedt een kader voor het plannen en uitvoeren van alle testactiviteiten. Zo maakt testen dat de producten aansluiten bij de bedrijfsdoelen door te meten of de kwaliteit adequaat is en aan te geven wat de resterende productrisico's zijn.

Het testbeleid is afgestemd op het kwaliteits- en het ict-beleid van de organisatie. Het testbeleid beschrijft de voorwaarden waaraan het testproces moet voldoen. Echter, wat er staat beschreven is niet concreet genoeg om direct binnen de projecten te worden toegepast. Het beleid is een kader waaraan de testactiviteiten worden getoetst.

Een eerstvolgende stap naar een meer concrete toepassing van het testbeleid vinden we in de globale teststrategie. Als we kijken naar het Test Maturity Model Integration (TMMI, 2008), zien we dat op niveau 2 van dat model wordt gesproken over een teststrategie die op basis van het testbeleid wordt opgesteld.

De globale teststrategie beschrijft op hoog niveau hoe binnen de kaders van het testbeleid, het testproces wordt uitgevoerd. Vanuit het testbeleid kan een aantal zaken worden gedefinieerd die van toepassing zullen zijn bij elk testproject dat zal worden uitgevoerd. In de globale teststrategie zal bijvoorbeeld worden vastgelegd welke testsoorten worden gehanteerd.

Ook binnen een testbeleid kunnen verschillende globale teststrategieën worden gedefinieerd. In veel organisaties komen bijvoorbeeld verschillende systeemomgevingen voor, vaak aangeduid als ontwikkelstraten. Zo zullen organisaties nog vaak systemen in gebruik hebben die werken op mainframes waarbij Cobol of PL/1 de ontwikkeltalen zijn. Tevens zien we in deze organisaties nieuwe ontwikkelingen plaatsvinden waarbij client/server, SOA, ERM en andere omgevingen gebruikt worden met toepassing van verschillende ontwikkeltalen. Al deze omgevingen kennen vaak een eigen aanpak voor systeemontwikkeling en beheer. Het kan noodzakelijk zijn om voor elk van deze ‘ontwikkelstraten' een eigen globale teststrategie op te stellen.

In iedere situatie zal de globale teststrategie gelden als leidend voor de binnen de testprojecten op te stellen projectteststrategieën. En hiermee is de relatie gelegd met het tactisch niveau: het testmanagement.

Testmanagement

Testmanagement is het plannen, begroten, monitoren en beheersen van test­acti­vi­teiten (BNTQB, 2007). Risk & requirement based testing (RRBT) is een aanpak voor testmanagement, die wordt weergegeven in het Testmanagementmodel. Het model beschrijft de activiteiten die de testmanager uitvoert om het testproject te besturen, zoals het opstellen van een teststrategie, een begroting en een planning.

Ook de activiteiten tijdens de uitvoeringsfase van een testproject komen aan bod. Denk hier aan voortgangsmanagement, bevindingenbeheer en het rapporteren aan de opdrachtgever en de stakeholders. Alle activiteiten in het Testmanagementmodel zijn aan elkaar gekoppeld en vormen zo een integrale aanpak.

Fases binnen testmanagement

Het Testmanagementmodel is globaal in twee delen te verdelen: de testprojectvoorbereiding en de testprojectuitvoering. De testprojectvoorbereiding zal in de meeste gevallen eenmalig plaatsvinden en bestaat uit de volgende stappen:

– Risicoanalyse & teststrategie. Dit is de fase die de basis vormt van RRBT. Welke productrisico's zijn er en met welke prioriteiten?
– Begroting. Hoeveel middelen (geld, mensen) zijn nodig voor het uitvoeren van het testproject?
– Planning. Welke tijdslijnen kunnen voor het project worden gedefinieerd? Welke producten worden opgeleverd?
– Testorganisatie. Wie gaat er uiteindelijk testen? zijn dit systeemontwikkelaars? Of wordt gebruik gemaakt van een interne of externe pool van testers of wordt het testen geheel uitbesteed?

De rechterzijde van het testmanagementmodel beslaat de besturing van de daadwerkelijke testuitvoering. Testuitvoering omvat het voorbereiden van de testgevallen en het daadwerkelijk uitvoeren van de tests. De testmanager heeft hierbij een besturende verantwoordelijkheid en treedt op als contactpersoon met de stakeholders. Hij voert daarbij de volgende activiteiten uit:

– Voortgangsbewaking. De testmanager bewaakt of het project volgens de planning verloopt aan de hand van rapportages over besteding van uren, aantal uitgewerkte/uitgevoerde testgevallen en kwaliteit van het te testen systeem.
– Bevindingenbeheer. Tijdens de testuitvoering komen de testers situaties tegen die afwijken van de verwachte situaties. De testmanager treedt in overleg met stakeholders over de afhandeling van deze bevindingen.
– Rapportage & advies. De testmanager stelt testfaserapporten op aan het eind van iedere testsoort. Aan het eind van het gehele testproject stelt hij een testeindrapport op dat een advies bevat over het al dan niet accepteren van het geteste systeem.
– Evaluatie & overdracht. Aan het eind van het testproject wordt teruggekeken naar de gang van zaken gedurende het project. Wat ging er goed en wat kan beter. Gegevens met betrekking tot metrieken worden vastgelegd. Tevens worden alle testproducten overgedragen aan de beheerafdeling voor archivering of beheer voor hergebruik.

Bij alle genoemde fasen zullen het testbeleid en de globale teststrategie de leidraad vormen en de basis zijn voor beslissingen. In de volgende paragrafen wordt de productrisicoanalyse als een van de belangrijkste onderdelen verder uitgediept. Reden hiervoor is dat hier de koppeling met de testanalyse en uitvoering ligt en daarmee dus het testen al daadwerkelijk begint.

Testprojectvoorbereiding

Product- en projectrisico's

Het beheersen van risico's speelt een belangrijke rol in de managementpraktijk. Bij een testproject gaat het om testprojectrisico's en productrisico's. De testprojectrisico's hebben te maken met situaties die het testproject in gevaar kunnen brengen. Inzicht in de productrisico's is belangrijk als beslissingen genomen moeten worden om een informatiesysteem al dan niet in productie te nemen. In het kader van dit artikel ligt de nadruk op de product­risico's.

De productrisicoanalyse

Productrisico's zijn de risico's die voortvloeien uit het gebruik van een systeem door een bedrijf of organisatie. Om tot een juiste productrisicoanalyse te komen is input van de stakeholders noodzakelijk. Stakeholders zijn functionarissen of afdelingen die een eigen belang hebben bij de juiste werking van een informatiesysteem. De stakeholders voeren, samen met de testmanager de productrisicoanalyse uit.

In een teststrategie staat welke stappen de testmanager gaat nemen om de testcapaciteit optimaal in te kunnen zetten en om binnen de beschikbare tijd, met de beschikbare middelen, de productrisico's af te dekken of inzichtelijk te maken, voordat het informatiesysteem in productie gaat. Het gaat daarbij niet alleen om de productrisico's maar ook om een prioriteitstelling binnen die productrisico's. Als prioriteiten zijn bepaald, kan de testinspanning gericht worden op die onderdelen van het systeem waarmee de organisatie de grootste productrisico's loopt. Hierbij zijn de inhoud van het testbeleid en die van de globale teststrategie mede bepalend omdat daar op hoger abstractieniveau vastligt welke risico's met welke diepgang moeten worden getest.

Omdat in de teststrategie duidelijk staat wat niet en wel getest wordt met welke diepgang en bovendien de acceptatiecriteria bevat, vormt de teststrategie de basis voor de begroting en de planning van het testproject en het uitgangspunt voor het testteam bij het opstellen en uitvoeren van de test. De productrisicoanalyse is daarmee een van de eerste testactiviteiten en misschien wel de belangrijkste. Aan de hand hiervan wordt de focus van de testactiviteiten bepaald; een verkeerde productrisicoanalyse, verlaagt de efficiëntie van alle (test)activiteiten die volgen.

Risicoprioriteit

Wanneer de risico's zijn vastgesteld volgt een volgende niet minder belangrijke stap: het toekennen van een prioriteit aan alle risico's. Het doel hiervan is, om tijdens het opstellen van de teststrategie te kunnen bepalen welke testtechnieken worden toegepast (hoe hoger het risico hoe zwaarder de testtechniek). Tevens dienen deze prioriteiten voor het vaststellen van de volgorde waarin de test zal worden voorbereid en uitgevoerd: de belangrijkste risico's eerst. De prioriteit van productrisico's wordt aangegeven met MoSCoW:

Must test         moet worden getest, anders wordt niet geaccepteerd,

Should test     belangrijk dat deze functie wordt getest, mag worden overgeslagen na overleg met stakeholders,

Could test       als er nog tijd over is zullen we kijken en

Won't test        dit testen we niet.

De prioriteit van een risico wordt, naast de bekende faalkans en impact, gevormd uit het belang dat de eigenschap voor de organisatie heeft, het afbreukrisico dat een organisatie loopt indien een bepaald deel niet goed wordt afgehandeld en regelgeving van buiten de organisatie. De prioriteit die aan een productrisico wordt toegekend noemen we de testprioriteit.

Matchen van Productrisico's en Requirements

Productrisico's en requirements zijn onlosmakelijk met elkaar verbonden; elk risico zal moeten worden beperkt door het definiëren van een of meer requirements. We kunnen de productrisicoanalyse gebruiken als eerste test om te controleren of de verzameling van gedefinieerde requirements compleet is. (let wel, we testen nog niet of alle requirements juist zijn gedefinieerd).

Voorwaarde voor een juiste uitwerking van dit proces is, dat de risico's en de requirements niet in één sessie en liefst niet door dezelfde medewerkers worden bepaald en opgesteld. Immers voorkennis van de requirements zal tijdens het risicoanalyseproces de deelnemers in een bepaalde richting sturen.

Requirements en prioriteiten

Wanneer we alle requirements tegen de productrisico's hebben gehouden en een sluitende lijst hebben gevormd hebben de requirements twee soorten prioriteiten.

De testprioriteit, afgeleid van de risicoprioriteit zoals deze is vastgesteld gedurende productrisicoanalyse en de functionele prioriteit. De functionele prioriteit geeft aan hoe belangrijk de functionaliteit is voor de stakeholders. De mogelijkheden voor de functionele prioriteit zijn:

Must have             het is onmisbaar,

Should have         bijna onmisbaar; het zou heel fijn zijn als deze functionaliteit geleverd wordt,

Could have           misbaar maar zouden we wel kunnen gebruiken, bijvoorbeeld verfraaiing en

Won't have            misbaar, eigenlijk niet nodig

De testprioriteit en de functionele prioriteit staan los van elkaar. Ze kunnen, maar hoeven niet overeen te komen. Een aspect van een systeem dat niet zo belangrijk is om te hebben kan, indien het wordt geïmplementeerd, wel een hoog productrisico vormen. Naast de productrisico's kunnen ook andere zaken zorgen voor een hoge testprioriteit, bijvoorbeeld:

– De complexiteit van een systeemdeel.
– De samenstelling van de systeemontwikkelingsorganisatie.
– De toepassing van nieuwe methode of technieken.

 Voor de verdere uitwerking tijdens het testproces wordt de testprioriteit gebruikt.

De project-teststrategie

De project-teststrategie is een verbijzondering van de globale teststrategie. De testmanager legt in de project-teststrategie vast hoe het systeem zal worden getest waarbij de inhoud van de globale teststrategie leidend is. Denk aan de indeling over testsoorten, de volgorde enzovoort. Daarvoor zal hij een aantal zaken ordenen en indelen. Een eerste stap is het ordenen van de productrisico's. Binnen RRBT wordt gegroepeerd op basis van de kwaliteitsattributen zoals die worden onderkend in de standaard ISO-9126 (ISO, 2001). De productrisico's en dus ook de requirements worden verdeeld over die categorieën attributen. De project-teststrategie bevat een clustermatrix en een aantal clusterkaarten. Een clustermatrix is een overzicht waarin de testmanager de stakeholders, de kwaliteitsattributen en testsoorten bij elkaar zet. Per testsoort wordt per stakeholder de verantwoordelijkheid voor kwaliteitsattributen vastgelegd. Per onderdeel in de clustermatrix wordt een clusterkaart opgesteld. Deze bevat alle informatie die van belang is voor de testers om voor een specifiek cluster de testen op te stellen zoals de te gebruiken testbasis, testtechnieken en de testprioriteit. De clusterkaart is het testcontract met de testcoördinator of -analist.

Testprojectuitvoering

De productrisicoanalyse, de clustermatrix en de clusterkaarten liggen vast in de project-teststrategie. Dit document is, naast natuurlijk de planning en de begroting, het vertrekpunt voor de testprojectuitvoering. De testprojectuitvoering bestaat uit een aantal min of meer sequentieel te doorlopen fasen, de testsoorten. Per testsoort die in de project-teststrategie is gedefinieerd zal een testtraject worden ingericht. Hierbij vormen de clusterkaarten de feitelijke overgang van testprojectvoorbereiding naar testprojectuitvoering.

De rechterzijde van het Testmanagementmodel van RRBT wordt meer dan eens doorlopen, voor elke gedefinieerde testsoort eenmaal. Hierbij heeft de testcoördinator de dagelijkse leiding binnen een testsoort en de testmanager de besturing over de testsoorten heen: de testcoördinator rapporteert aan de testmanager over de voortgang binnen de testsoort en stelt het fase- of testsoortrapport op. Hierbij vormt de testprioriteit de leidraad voor deze rapportage.

Testvoorbereiding

De testcoördinator zal op basis van de clusterkaarten en het door de testmanager opgestelde project-testplan een detailtestplan opstellen. In dit detailtestplan ligt vast welke clusterkaarten, afhankelijk van de testprioriteit, met voorrang worden uitgewerkt. De testcoördinator verdeelt de clusterkaarten over de testanalisten die in zijn team zitten. Wanneer de clusterkaarten een groot gebied bestrijken kan de testcoördinator besluiten om voor die clusterkaarten een onderverdeling te maken in meerdere, kleinere clusters. Deze clusters vormen dus de werkpakketten voor de testanalisten.

Testanalyse

De testanalist is verantwoordelijk voor het daadwerkelijk analyseren van de testbasis, het ontwerpen van de testcondities en testgevallen en het opstellen van de testdata. De testanalist heeft daartoe een hiërarchie van producten tot zijn beschikking bestaande uit testclusters, testcondities en testgevallen. De testprioriteit geldt als uitgangspunt voor de volgorde voor het opstellen van testcondities.

Testuitvoering

De testuitvoering vindt plaats op basis van de resultaten van de analyse: het testcluster, de testcondities en de testgevallen. Het testcluster doet nu dienst als testdraaiboek en geeft de volgorde voor de uitvoering van de verschillende testgevallen aan. De testuitvoerder zal stap voor stap alle testgevallen uitvoeren die voor de test zijn geselecteerd. Daarbij neemt hij als eerste de clusters die horen bij de productrisico's met de hoogste testprioriteit. Van deze clusters voert hij de testgevallen uit in de volgorde zoals in het cluster is vastgelegd. Hierdoor kan zo snel mogelijk een uitspraak worden gedaan over de kwaliteit van het betreffende deel van het informatiesysteem.

Rapportage

De testmanager zal regelmatig inzicht moeten geven in de voortgang, de kwaliteit van het informatiesysteem en eventuele perikelen rond het testproject. Door regelmatig te rapporteren, blijft het testproject onder de aandacht van de opdrachtgever en de stakeholders. Zij weten dan welke productrisico's en daarmee samenhangende requirements al zijn afgedekt en welke risico's nog getest moeten worden. Met deze informatie kunnen zij een beslissing nemen om over te gaan naar een volgende testsoort of om het informatiesysteem in productie te nemen.

In de teststrategie is vastgelegd wat wordt getest en wat niet en dus welke productrisico's afgedekt zullen worden in het testproject. Het project-testplan en de detailtestplannen beschrijven hoe de testmanager het testproject heeft ingericht. Tijdens de looptijd van het testproject zal de testmanager de opdrachtgever en alle stakeholders op de hoogte moeten houden over de voortgang van het testproject. Zij zijn immers betrokken geweest bij het opstellen van de teststrategie en het testplan en zij zullen willen weten hoe het staat met de kwaliteit van het te testen informatiesysteem.

Testproducten en de relatie met de teststrategie en het testbeleid

Productrisicoanalyse

De productrisicoanalyse wordt mede op basis van de inhoud van het testbeleid opgesteld. Immers, in het testbeleid ligt vast welke onderdelen van de informatiesystemen van primair belang zijn voor de organisatie. Dus bij de uitvoering van een productrisicoanalyse wordt de inhoud van het testbeleid als leidraad geberuikt.

Testclusters

In de teststrategie heeft de testmanager clusterkaarten vastgelegd die betrekking hebben op één kwaliteitsattribuut of, wanneer de attributen goed verenigbaar zijn, een aantal nauw met elkaar verwante kwaliteitsattributen. De testclusters krijgen dezelfde testprioriteit als die, die in de clusterkaart is vastgelegd. Rekening houdend met deze testprioriteit zal de testanalist de volgorde van de verdere uitwerking bepalen; de hoogste prioriteit als eerste.

Testcondities

Testcondities vormen een belangrijk middel voor communicatie met de stakeholders. Testcondities zijn zeer sterk gerelateerd aan de requirements bij een systeem en krijgen dezelfde testprioriteit als die, die deze requirements krijgen toegewezen gedurende de productrisicoanalyse. De testprioriteit bepaalt in welke volgorde testcondities worden uitgewerkt. De testanalist zal beginnen met de must test testcondities. Daarnaast is het vanzelfsprekend van belang dat de testcondities zijn goedgekeurd door de stakeholders. De stakeholders weten via de testcondities dus exact wat er getest gaat worden.

Testgevallen

De testcondities worden uitgewerkt in testgevallen. Testgevallen beschrijven hoe en met welke waarden handelingen worden uitgevoerd om aan te tonen dat wat is beschreven in de testcondities correct is geïmplementeerd. In de project-teststrategie heeft de testmanager vastgelegd welke testtechnieken worden toegepast bij het opstellen van testgevallen. Dat is afhankelijk van de productrisico's en de regels die vastliggen in het testbeleid.

Bevindingenbeheer

Een bevinding die wordt gedaan tijdens een testtraject, is een afwijking ten opzichte van een verwacht resultaat. Dit kan een geconstateerde afwijking in het informatiesysteem en de infrastructuur zijn, maar ook een afwijking in documentatie zoals de basis- en detailontwerpen. Ook bij bevindingen speelt het productrisico en de bijbehorende testprioriteit een belangrijke rol. De prioriteit van de bevinding is mede afhankelijk van de testprioriteit. Een bevinding bij een testgeval dat is gerelateerd aan een productrisico met hoge prioriteit zal hoogstwaarschijnlijk eerder worden opgelost dan een met een lagere prioriteit.

Samenvatting

Het testbeleid is nauw gerelateerd aan het ict- en het kwaliteitsbeleid van die organisatie en ondervindt invloed van buiten de organisatie als gevolg van wet- en regelgeving. Het testbeleid zet de kaders voor de globale teststrategie, de aanpak op hoofdlijnen voor het testen van systemen, eventueel verbijzonderd binnen een ontwikkelstraat. In deze globale teststrategie ligt bijvoorbeeld vast welke testsoorten worden toegepast en welke methoden en technieken worden gehanteerd bij het definiëren van testgevallen.

Daar ligt gelijk de connectie met risk & requirement based testing (RRBT). De testmanager die volgens deze methode werkt, gebruikt de inhoud van het testbeleid en de globale teststrategie als uitgangspunt voor het besturen van het testproject. De testmanager stelt samen met de stakeholders de productrisicoanalyse op en in de project-teststrategie legt hij vast welke risico's met welke prioriteit en op welke wijze worden getest. Die afspraken worden in clusterkaarten vastgelegd.

Aan de hand van de project-teststrategie worden een of meer testsoorten als deelproject gepland en uitgevoerd. De clusterkaarten vormen het vertrekpunt van deze deelprojecten. Onder leiding van een testcoördinator wordt de testsoort door testanalisten verder uitgewerkt. De clusterkaarten worden uitgewerkt in testclusters, testcondities en testgevallen. De testclusters en testcondities "erven" de testprioriteit die via de productrisico's aan de requirements is toegekend. Deze testprioriteit bepaalt de volgorde voor de verdere uitwerking, de toe te passen testtechnieken en de volgorde van testuitvoering.

Tijdens het uitvoeren van de test zullen ongetwijfeld bevindingen optreden; afwijkingen tussen verwachte en gevonden resultaten. Bij het beheer van de bevindingen spelen de productrisico's opnieuw een rol.

De testmanager doet op vaste momenten en wanneer hij het noodzakelijk acht op andere momenten, verslag van de voortgang van het testproject. Hij rapporteert over de status van het project en de kwaliteit van het systeem. Dit doet hij aan de hand van de productrisico's die bij de testcondities horen. Daarbij zal het gaan over het percentage van de verschillende risico's dat is afgedekt door het testen. Aan de hand van deze informatie kan de testmanager adviseren om naar een volgende testsoort te gaan of om het systeem al dan niet in productie te nemen.

En daarmee is de cirkel rond: de productrisico's bepalen mede hoe het testproject wordt uitgevoerd. Ze bepalen in ieder geval in welke volgorde en met welke diepgang de test wordt voorbereid en uitgevoerd. Tenslotte geeft de voortgangsrapportage inzicht in de status van het systeem in relatie tot de productrisico's. Deze rapportage is uiteindelijk de basis voor de beslissing om in productie te gaan.