Cruciale bijdrage van de testdisciplines

In het derde artikel van deze reeks heb ik de structuur van een succesvolle testlevenscyclus behandeld. Testuitvoering kan een enorm hectisch proces zijn, een gedegen testplanning en voorbereiding per testfase is daarom onontbeerlijk. Het unieke Test Assessment Framework (TAF), waarvoor wereldwijd octrooi is aangevraagd, ondersteunt de organisatie zowel bij het identificeren als het verbeteren van de testlevenscyclus en de bijbehorende testgebieden: de testplanning, testvoorbereiding en de testuitvoering. TAF geeft een volledige (driedimensionale) indruk van de testvolwassenheid van de gehele test organisatie: eerste dimensie: drie testdomeinen (teststrategie, testlevenscyclus, testdisciplines) omvatten in totaal vijftien testgebieden die worden geëvalueerd op hun testvolwassenheid, tweede dimensie: de evaluatie vindt plaats tegenover de vijf testvolwassenheidsniveaus van het Testing Maturity Model (TMM), ontwikkeld in 1996 aan het Illinois Institute of Technology, via een ‘Quick Assessment’ (kortere periode, meer subjectief) of een ‘Full Assessment’ (langere periode, meer objectief) en derde dimensie: de testvolwassenheid van elk testgebied wordt bepaald via de drie testinvalshoeken in de organisatie: processen, technologie en de mensen. In dit vierde artikel zal ik stilstaan bij het derde en tevens laatste TAF-testdomein: de cruciale bijdrage van de testdisciplines.

Wat zijn testdisciplines?

Als je de teststrategie ziet als ‘wat' je moet testen en de testlevenscyclus ‘hoe' je moet testen, dan zijn de testdisciplines het ‘waarmee' je moet testen. De testdisciplines zijn die testgebieden die een cruciale rol spelen tijdens het testen waardoor de volwassenheid van deze testgebieden dus direct bijdraagt aan de volwassenheid van het gehele testproces.

Je kunt je nog steeds afvragen: waarom negen testdisciplines en geen vijftien of twintig? Het antwoord op deze vraag is niet eenvoudig. Toen ik ongeveer vijf jaar geleden deze testgebieden samen met een toenmalige collega identificeerde, keken we naar die onderdelen van het testproces die we zagen als typische ‘pijnpunten' waar in projecten vaak te weinig aandacht werd geschonken. Het waren gebieden die niet zozeer te maken hadden met het ‘standaard' testproces (zoals beschreven in de testlevenscyclus en tweede TAF-testdomein), maar eerder specifieke gebieden die het testproces zowel positief als negatief konden beïnvloeden en daarmee het succes van het gehele systeem ontwikkeltraject. Uiteraard moest het wel mogelijk zijn om van de geïdentificeerde testdisciplines de verschillende testvolwassenheidsniveaus te beschrijven volgens het Testing Maturity Model (TMM). Dit was geen gemakkelijke opgave, maar heeft wel bijgedragen aan het unieke karakter van het Test Assessment Framework en daarmee de wereldwijde octrooiaanvraag.

Net als de testgebieden binnen de teststrategie (eerste TAF-testdomein) en de testlevenscyclus (tweede TAF-testdomein) worden de testdisciplines binnen TAF beoordeeld op volwassenheid vanuit de drie testinvalshoeken proces, technologie en de mens. Dit vierde artikel zou eerder een boek worden (wat misschien nog wel gaat gebeuren) als ik de inhoud van TAF met betrekking tot de testdisciplines op dezelfde manier zou beschrijven zoals bij de teststrategie en de testlevenscyclus. Ik zal ze daarom op een hoger niveau behandelen en slechts de kernpunten van deze testgebieden beschrijven.

Het derde TAF-testdomein en de bijbehorende testgebieden/testdisciplines bestaan uit:

– TAF-testgebied 7: performancetesten
– TAF-testgebied 8: testbegroting
– TAF-testgebied 9: testmetrieken
– TAF-testgebied 10: projectmanagement
– TAF-testgebied 11: defectmanagement en voorkoming
– TAF-testgebied 12: testautomatisering
– TAF-testgebied 13: testdatamanagement
– TAF-testgebied 14: requirementsmanagement
– TAF-testgebied 15: configuratiemanagement

TAF-testgebied 7: performancetesten

Performancetesten is een vaak onderschatte discipline in projecten. In het beste geval wordt het nieuwe informatiesysteem daadwerkelijk getest op performance, maar dan? Als (of beter gezegd: zodra) de resultaten van de performancetest niet voldoende zijn, is het vaak te laat om er nog iets aan te doen. De technische architectuur blijkt niet toereikend, het technisch ontwerp van het systeem moet opnieuw onder de loep worden genomen omdat deze de verwachte lading (Engels: ‘load') omtrent gebruikers en processen niet tegemoet zal kunnen komen, etc. 

Volwassen testorganisaties zien performancetesten als een unieke testdiscipline die vanaf het begin tot aan het eind van het project wordt gepland, voorbereid en uitgevoerd. We spreken hier ook wel van ‘performance engineering': het plannen en begroten van alle factoren die de performance van het uiteindelijke informatiesysteem kunnen beïnvloeden. Denk bijvoorbeeld aan functionele factoren zoals (einde)jaarsacties bij systemen die productverkopen ondersteunen, gebruikersfactoren zoals de hoeveelheid en locatie van gebruikers die gelijktijdig het systeem willen benaderen, of netwerkfactoren zoals bandbreedte die allemaal de performance van het informatiesysteem negatief kunnen beïnvloeden. Ook de verschillende typen performancetesten zullen moeten worden gepland, voorbereid, en uitgevoerd. Voorbeelden hiervan zijn volumetesten, loadtesten, stresstesten en duurzaamheidtesten.

TAF-testgebied 8: testbegroting

Net als de begroting van het project zal ook de hoeveelheid testwerk moeten worden ingeschat. Dit is geen eenvoudige opgave, testen heeft vaak een uniek karakter binnen het soort project waarin het plaatsvindt. Zo wordt er bijvoorbeeld minder en anders getest bij een pakketoplossing (bijvoorbeeld SAP of Oracle) dan bij een maatwerkoplossing (bijvoorbeeld Java/internet). Volwassen testorganisaties maken vaak gebruik van een geavanceerd testbegrotingsmodel om tot de juiste testbegroting te komen. Een testbegrotingsmodel gebruikt inschattingsfactoren die de uiteindelijke testbegroting kunnen beïnvloeden. Voorbeelden zijn het aantal businessrequirements, het aantal use cases (functionele specificaties), de complexiteit van de use cases, het aantal verwachte testscenario's, etc.

Testbegroting zal moeten worden uitgevoerd voor alle testfasen. Dit kan door middel van een ‘top-down' aanpak of ‘bottom-up' aanpak. In het eerste geval wordt er een testbegroting gemaakt voor al het testwerk, waarna deze via zogenaamde relativiteitsfactoren wordt verdeeld over de verschillende testfasen. In het tweede geval wordt de testbegroting opgesteld per testfase, waarna de totale testbegroting wordt berekend. Het maken van een testbegroting is een complexe activiteit en het is belangrijk dat deze continu wordt aangepast en verbeterd binnen de context van de organisatie. Het is onwaarschijnlijk dat de begroting volledig correct zal zijn als deze voor het eerst wordt gemaakt. Daarom is het belangrijk dat het model continu wordt bijgehouden aan de hand van de werkelijk gespendeerde testuren op het project.

TAF-testgebied 9: testmetrieken

Hoe staan we ervoor? Hoeveel moeten we nog testen? Hoe snel worden de defects opgelost? Menig tester zal ooit zijn en wordt waarschijnlijk nog dagelijks geconfronteerd met deze vragen. Je kunt deze vragen vanuit twee oogpunten bekijken: het project moet uiteraard over de mogelijkheid beschikken geavanceerde testmetrieken op te slaan, te verwerken en te rapporteren, maar het is ook noodzakelijk dat de testmetrieken het project in staat stelt de juiste beslissingen te nemen zodra dit nodig is. We hebben hier dus te maken met twee uitdagingen: een technologische en een organisatorische uitdaging.

Allereerst zullen testmetrieken moeten worden gemodelleerd en samengebracht in een framework of dashboard. Het ontwikkelen van een testmetriekendashboard is geen eenvoudige taak, de metrieken zullen allereerst gestandaardiseerd moeten worden binnen de testorganisatie. Ze zullen ook moeten worden geïntegreerd met de testtools van waaruit de input voor de metrieken wordt gegenereerd. Nadat het testmetriekenmodel en het bijbehorende dashboard is gecreëerd en de metrieken kunnen worden gerapporteerd, zal moeten worden nagedacht over de boodschap zelf.

In het tweede artikel (teststrategie) in deze reeks heb ik een voorbeeld aangekaart over een geavanceerd testmetriekendashboard dat ik had ontwikkeld voor een grote testorganisatie bij een bank. Nadat het dashboard was ontwikkeld, getest en uitgerold bleek de organisatie maar moeilijk in staat om de geavanceerde metrieken te vertalen naar effectieve acties die het testproces moesten bijsturen. Naast een probleem met de testmetrieken bleek dat de organisatie dus ook hulp nodig had bij het trainen van alle betrokkenen in het interpreteren van de testresultaten. Vaak adviseer ik organisaties om een zogenaamde testmetriekenprogramma op te starten, waarbij zowel de ontwikkeling van het testmetriekendashboard en de training van alle betrokkenen worden geïntegreerd zodat projecten beter in staat zijn de testmetrieken te vertalen naar concrete acties die het testproces kunnen controleren en verbeteren.

TAF-testgebied 10: projectmanagement

Waarom staat projectmanagement in de lijst van testdisciplines? Ik kan hier kort over zijn: ik kan me geen project voorstellen waar projectmanagementprocessen onvolwassen zijn, maar waar het testproces volwassen is en uitstekend verloopt. Omgekeerd lijkt me ook onwaarschijnlijk (maar niet geheel onmogelijk): een volwassen projectmanagementstructuur en bijbehorende processen in combinatie met een onvolwassen testproces.

Testen vindt altijd plaats in de context van een overkoepelende (management)structuur. Dit kan een project zijn met een bepaalde eindfase of een managementorganisatie die zich bezighoudt met het continu onderhouden van informatiesystemen. In beide gevallen zal de volwassenheid van deze overkoepelende organisatie van invloed zijn op het testen en daarom heb ik projectmanagement als testgebied toegevoegd aan de testdisciplines.

Ik zal in dit artikel projectmanagement (uiteraard) niet in zijn geheel gaan bespreken, maar enkele aspecten zijn belangrijk om te noemen in relatie tot testen. Het is allereerst belangrijk dat een project een business case kent; de reden voor het bestaan van het project. Daarnaast mag je verwachten dat projecten in staat zijn de volledige voortgang te meten, dit heeft betrekking op het (resterende) budget, het tijdschema, risico's en issues. Kwaliteitsmanagement is een projectmanagementdiscipline die gedurende het gehele testproces een belangrijke rol speelt (bijvoorbeeld tijdens het analyseren van de businessrequirements bij de testvoorbereiding).

Ook speelt verandermanagement (Engels: change management) een sleutelrol wanneer tijdens systeem-, integratie-, maar vooral gebruikersacceptatietesten (noodzakelijke) veranderingen naar boven komen die van invloed zullen zijn op het project budget en/of de tijdslijnen. Naast deze procesgerelateerde onderdelen zal een project ook zorg moeten dragen voor de juiste werkomgeving en ondersteunende tools en organisatorische aspecten zoals communicatie en benodigde training.

TAF-testgebied 11: defectmanagement en voorkoming

Defectmanagement en voorkoming is een testdiscipline waar bijna altijd wel aandacht aan wordt geschonken, onafhankelijk van de volwassenheid van de testorganisatie. Het is echter een testdiscipline die wel degelijk vijf volwassenheidsniveaus kent. Vaak worden op projecten de defects wel bijgehouden, maar is het proces ongestructureerd. Het is niet duidelijk wie verantwoordelijk is voor het gehele proces of het is niet duidelijk wie het defect van de ene naar de andere status mag brengen (als er hiervoor al een proces is).

Ik heb eens op een project gewerkt waar projectmanagement had besloten de autorisatie voor statusverandering van defects niet te configureren en vast te leggen. Het project gebruikte overigens wel een zeer geavanceerd defectmanagementtool. De reden hiervoor was dat men zich zorgen maakte dat de defects niet snel genoeg werden opgelost als groepen gebruikers (bijvoorbeeld ontwikkelaars) alleen maar specifieke statusveranderingen van defects konden doorvoeren. Het eindresultaat was precies het tegenovergestelde: het duurde veel te lang voordat de defects werden opgelost, vele vergaderingen werden wekelijks en soms zelfs dagelijks belegd om de status van de defects door te nemen en het project raakte achter op schema.

Momenteel werk ik op een groot programma waar ik het tegenovergestelde heb opgezet: een gestructureerd defectmanagementproces met vooraf gedefinieerde gebruikersgroepen en duidelijke verantwoordelijkheden binnen het proces. Tijdens de eerste paar dagen van het testen moesten de gebruikers (ontwikkelaars, testers, testmanagers) wel even wennen, maar al heel snel werd het voor iedereen ‘business as usual' en kon men zich volledig concentreren op het testen. Het defectmanagementproces werkte in plaats van verstorend juist ondersteund door het hertesten van defects en testscripts sneller mogelijk te maken.

TAF-testgebied 12: testautomatisering

Testautomatisering wordt wel eens gezien als de ‘silver bullet' van het testen: het testen kost teveel tijd, is te duur, te ongestructureerd en dus wil men het testen automatiseren zodat het allemaal sneller en goedkoper zal gaan. Uiteraard werkt het in de praktijk niet zo. Ook testautomatisering kent vijf volwassenheidsniveaus.

Allereerst is het noodzakelijk de business case voor testautomatisering op te stellen. Onderdeel hiervan is ook het uitvoeren van een zogenaamde ‘proof of concept'. Hier kan bijvoorbeeld zijn dat het ontwikkelen van geautomatiseerde testscripts aan de hand van de reeds ontwikkelde handmatige testscripts veel extra tijd en dus teveel geld gaat kosten. Testautomatisering kent naast het testen zelf ook een belangrijk deel systeemontwikkeling. Het ontwikkelen van software dat testscripts automatisch gaat uitvoeren is niet zoveel anders dan het ontwikkelen van software dat gebruikers in staat stelt informatie te gebruiken! Dit betekent dus dat er bugs in de automatische testscripts kunnen zitten die er moeten worden uitgehaald door het (uiteraard handmatig) ‘testen van de testscripts'.

Naast het ontwikkelen van de automatische testscripts zullen deze ook continu moeten worden bijgehouden. Testautomatisering is met name bedoeld voor regressietesten, het testen van die onderdelen van de software waarvan wordt geacht dat deze geen veranderingen hebben ondergaan door aanpassingen elders. Echter, alle software is vroeg of laat wel degelijk onderhevig aan veranderingen en dus zullen de automatische testscripts ook moeten worden bijgehouden, getest en uitgerold. Testautomatisering kan interessante kostenbesparingen met zich meebrengen, maar het is van cruciaal belang dat deze ondersteund wordt door een gestructureerd en volwassen proces, omgeving en tools en organisatie.

TAF-testgebied 13: testdatamanagement

Het belang van testdatamanagement wordt vaak onderschat op projecten. Als je de testscripts ziet als het ‘wat' je test, is de testdata het ‘waarmee' je test: een gestructureerd en volwassen testdatamanagementproces is dus net zo belangrijk als een gestructureerd en volwassen proces voor de testplanning, testvoorbereiding en de testuitvoering. Testdata moet representatief zijn voor het informatiesysteem wanneer het in productie is. Om dit te kunnen bereiken is het noodzakelijk dat wordt nagedacht over het identificeren van de testdata, het verkrijgen, het conditioneren en het opslaan en onderhouden van de testdata.

Waarom moet testdata worden geconditioneerd? Vanwege nationale en internationale wetgeving op gegevens is het vaak noodzakelijk dat testers en andere betrokkenen in het testproces niet zomaar productiegegevens kunnen inzien. Hier zijn tegenwoordig goede oplossingen voor beschikbaar in de vorm van geavanceerde testdatamanagegenttools die deze data kunnen versleutelen, transformeren, en maskeren (denk bijvoorbeeld aan creditcardgegevens). Soms kiest een organisatie voor de kortste weg en wordt productiedata direct gekopieerd naar de testomgeving om te worden gebruikt als testdata. Het is hierbij van essentieel belang dat er wordt gecontroleerd of de gevolgde processen in lijn zijn met de geldende regelgeving en dat de benodigde controles hierop worden uitgevoerd en bijgehouden.

TAF-testgebied 14: requirementsmanagement

Van alle testdisciplines is dit wellicht een van de belangrijkste. Requirements komen altijd om de hoek kijken tijdens het testen; in het begin van het proces als de scope en de testplanning van het testen worden bepaald, daarna als tijdens de testvoorbereiding als de testcondities, testscenario's en testscripts worden geschreven en tenslotte tijdens de testuitvoering als de business wil weten in hoeverre het nieuwe informatiesysteem gereed is om in productie te gaan. Juist deze laatste fase wordt vaak onderschat op projecten; vaak wordt er teveel aandacht geschonken aan alleen de voortgang van de testuitvoering en het oplossen van de defects, terwijl testmanagement het belang van het nieuwe informatiesysteem voor de business uit het oog verliest.

Dit laatste kan voorkomen worden door requirements traceerbaarheid goed te definiëren tijdens de testplanning, te bouwen tijdens de testvoorbereiding en deze continu te meten en te rapporteren tijdens de testuitvoering. Je kunt hierbij denken aan businessrequirements en use cases waaraan de teststatus van de testscenario's en testscripts wordt gekoppeld tijdens de testuitvoering zodat het duidelijk is of een use case en de stappen hierin succesvol of niet succesvol zijn getest. Tegenwoordig geven geavanceerde testmanagementtools goede ondersteuning voor requirementstraceerbaarheid; deze moet dan uiteraard wel worden geconfigureerd en toegepast op het project.

TAF-testgebied 15: configuratiemanagement

Laat ik eerst beginnen met de definitie van configuratiemanagement. Iedereen heeft wel eens gehoord van versiebeheer (van softwarecode, maar ook van testscripts, testdata, etc.), releasemanagement (het bijeenvoegen van alle componenten van een informatiesysteem tot een nieuwe release) en changemanagement (het kunnen controleren, bouwen en testen van changerequests binnen de scope van het project en het te ontwikkelen informatiesysteem). De combinatie van deze drie componenten vormen de testdiscipline configuratiemanagement.

Menig tester of testmanager (en zeker projectmanager) zal zijn geconfronteerd met de vragen ‘waarmee gaan we live?' of ‘welke changerequests gaan live in deze release en welke in de volgende?'. Een gestructureerd configuratiemanagementproces stelt het project en de testorganisatie in staat om continu deze vragen te beantwoorden tijdens het testen zodat het voor de business duidelijk is of er voldoende is getest en of het nieuwe informatiesysteem de verwachte voordelen kan bieden zodra het in productie is. Configuratiemanagement is een van de moeilijkste, technische processen binnen het gehele systeemontwikkeltraject. Daarom is het gebruik van een of meer configuratiemanagement tools onontbeerlijk.

Sinds kort zijn er geavanceerde testmanagementtools op de markt die het project een geïntegreerde oplossing geven voor de testlevenscyclus (testplanning, voorbereiding en uitvoering), requirementsmanagement en configuratiemanagement. Hierdoor kun je in een keer de impact zien van een changerequest op requirements en de bijbehorende testscenario's en testscripts. Hiervan kunnen ook meerdere versies worden bijgehouden en vergeleken zodat het altijd mogelijk is om eventueel terug te vallen op een vorige versie.

Volgende en laatste artikel

De doelstelling van het vierde artikel in deze reeks was om indruk te geven over de cruciale bijdrage van de testdisciplines. Deze testgebieden spelen een dermate belangrijke rol binnen het testproces dat ze afzonderlijk kunnen worden beschreven en beoordeeld op testvolwassenheid. TAF ondersteunt de organisatie zowel bij het identificeren als het verbeteren van de belangrijkste test- en ontwikkeldisciplines zoals projectmanagement, requirementsmanagement en configuratiemanagement aangezien deze een directe- of indirecte relatie hebben met het testen en de daarmee samenhangende capaciteit van de organisatie om geavanceerde informatiesystemen voorspelbaar te ontwikkelen en toe te passen. Het resultaat: langdurig concurrentievoordeel.

In het volgende en tevens laatste artikel van deze reeks zal ik ingaan op een onderzoek dat enige tijd geleden is ingesteld naar de voordelen van testcentralisatie en de verbetering van testvolwassenheid. In dit onderzoek komen interessante feiten naar voren die onderschrijven dat langdurig concurrentievoordeel voor bedrijven en instellingen daadwerkelijk wordt ondersteund door het verbeteren van testvolwassenheid.