Test management: van cruciaal belang voor succesvolle IT-resultaten

Een veelvoorkomend probleem binnen softwareprojecten is dat bedrijven vaak niet goed begrijpen wat test management inhoudt. Dit gebrek aan kennis kan leiden tot onderschatting van de benodigde tijd en resources voor adequaat testen, wat weer resulteert in onrealistische verwachtingen en projectdoelstellingen. Gestructureerd testen kost een aanzienlijke inspanning, maar levert op het eind een hoop voordelen op. Betrouwbaar en gecontroleerd live-gaan zonder stress en onzekerheden is onbetaalbaar. 

Daarnaast werken teams vaak in isolatie, zonder een duidelijk overzicht van de totale projectketen. Dit is geen onwil. Elk team focust zich zo goed mogelijk op zijn eigen deel, met het succesvol voltooien van unit tests en component tests. Echter, zonder integratie van deze onderdelen in het grotere geheel, blijven de snijvlakken vaak ongetest. Dit kan leiden tot kritieke fouten wanneer verschillende systemen en modules samen moeten komen, wat weer leidt tot onnodig uitstel van een live-gang. 

Effectief test management overbrugt deze kloof. Het omvat niet alleen het testen van afzonderlijke onderdelen maar zorgt ook voor de noodzakelijke tests van de interfaces tussen verschillende systemen en modules. Hier zijn drie sleutelcomponenten die een uitgebreid testmanagement moet omvatten: 

Functionele Acceptatie Test (FAT): FAT is gericht op het testen van software om te verzekeren dat het voldoet aan alle gespecificeerde vereisten. Dit wordt meestal uitgevoerd in een ontwikkelomgeving voordat de software wordt vrijgegeven voor externe testing door eindgebruikers. Vaak wordt hier alleen de “happy flow” getest, d.w.z. het proces zonder fouten of uitzonderingen, maar hier al moet in overleg met de business ook mét fouten en uitzonderingen worden getest om niet meteen bugs te krijgen tijdens de GAT. 

Gebruikers Acceptatie Test (GAT): GAT vindt plaats in de 'echte wereld', waar eindgebruikers de software testen in hun eigen operationele omgeving. Deze eindgebruikers zijn de experts binnen het bestaande proces of software, zodat zij een duidelijke mening kunnen geven of de wijzigingen de beoogde voordelen opleveren. Een GAT verzekert dat het systeem voldoet aan de gebruikersvereisten en in de praktijk functioneel is. Het is hier van belang dat de test scripts zijn gebaseerd op de werkinstructies van de klant. De werkinstructies zijn een weerspiegeling van de operationele werkelijkheid en moeten ten alle tijden zijn bijgewerkt als onderdeel van het software change proces. 

Platform Acceptatie Test (PAT): Tijdens het ontwikkelen van nieuwe software wordt vaak niet meteen gedacht aan hoe de software straks in beheer moet draaien. Tijdens PAT worden hardware, software, en netwerkconfiguraties uitvoerig getest om te controleren of het platform aan alle technische vereisten en specificaties voldoet. Dit type testen is cruciaal voor het identificeren van problemen die specifiek zijn voor de omgeving waar het systeem zal draaien, en helpt om dure downtime of herconfiguraties na de live-gang te voorkomen. 

Ook de afspraken rondom SLA en monitoring & alerting moeten in samenspraak met de beheerorganisatie worden gemaakt, zodat bij een escalatie duidelijk is hoe de melding moet worden opgepakt. 

Testen zijn zo goed als de scripts die worden gebruikt. Stel: jouw testscripts testen alleen of er iets op het scherm te zien is en gaan niet in op of wat er op het scherm te zien is ook het juiste is. Je kunt je voorstellen dat de kwaliteit van de test alsnog laag zal zijn. Goede test scripts omvatten in ieder geval het volgende: 

• Een uniek referentienummer, zodat altijd specifiek aan een bepaald testscript kan worden gerefereerd. Bijvoorbeeld “VO1” bij een test met een verkooporder. 
• Duidelijke stappen met één verwachte uitkomst. Dit maakt bij een bug duidelijk waar in het proces het precies misgaat. 
• Pre- en postconditie. Dit zijn de voorwaarden waaraan de inregeling van het systeem moet voldoen om aan de test te beginnen. Een voorbeeld van een preconditie is “Er is een verkooporder met een waarde > 1000 euro” en een voorbeeld van een postconditie is “De voorraad van product X is 5”. 
• Modulariteit. Een goed testscript kan gemakkelijk worden aangepast voor andere scenario’s. 
• Automatiseerbaarheid. Een goed script is zo opgesteld dat het gemakkelijk te automatiseren is, wat tijd bespaart en menselijke fouten vermindert bij herhaalde tests. 

Tip 1: Bij een klant bestond een testscenario uit complexe combinaties van klant- en objectgegevens met wel 30 variabelen! Zet in dat soort gevallen de klant- en objectgegevens op een aparte plek en refereer ernaar met een uniek ID in de preconditie. Zo voorkom je veel onnodig knip- en plakwerk. 

Tip 2: Bij een klant bestond een testscenario uit complexe combinaties van klant- en objectgegevens met wel 30 variabelen! Zet in dat soort gevallen de klant- en objectgegevens op een aparte plek en refereer ernaar met een uniek ID in de preconditie. Zo voorkom je veel onnodig knip- en plakwerk.   

Tip 3: Bij een andere klant moesten verschillende afdelingen veel verschillende scenario’s testen. In plaats van allerlei losse documenten te beheren, hebben we testmanagementsoftware ingezet om een centraal overzicht te creëren van alle testscripts. Deze konden vervolgens in verschillende test suites worden toegekend aan de diverse afdelingen. 

Natuurlijk moeten ook de resultaten van al deze testen helder en gestructureerd worden gerapporteerd. Een testverslag moet ene goed overzicht geven van de uitgevoerde werkzaamheden zonder in technisch detail te gaan. Hier zijn enkele belangrijke elementen die een testverslag effectief maken: 

• De naam van testers 
• De datum van de test. Dit geeft ook aan welke versie van de testscripts zijn gebruikt. 
• Een overzicht van welke testen zijn uitgevoerd met referentienummers. Vaak wordt niet de gehele keten iedere keer volledig uitgevoerd. 
• Per test een uitkomst of aan de verwachtingen is voldaan. Zo niet, dan wordt genoteerd bij welke stap het is misgegaan en wat er dan wel is geconstateerd. Hier kan eventueel ook een beeldopname bij worden gedeeld. 
• Eventuele aanbevelingen voor verbetering voor de volgende testcyclus. 

De testverslagen zijn een essentieel onderdeel voor de testmanager om zijn of haar oordeel op te baseren en een goed advies uit te kunnen brengen richting projectmanagement. 

Naast de FAT, GAT en PAT is het ook van belang om ketentesten uit te voeren. Dit zijn tests die plaatsvinden op de punten waar verschillende systemen en modules integreren. Het is cruciaal dat deze integraties vlekkeloos verlopen om de functionaliteit van het volledige systeem te garanderen. Ketentesten zorgen ervoor dat alle onderdelen naadloos samenwerken en eventuele discrepanties vroegtijdig worden geïdentificeerd. Ook zijn de werkinstructies van cruciaal belang. De werkinstructies bevatten, als het goed is, de overdracht van het proces naar andere afdelingen en kunnen zo worden gebruikt om de kritieke punten te identificeren. 
Ook voor ketentesten gelden dezelfde voorwaarden voor een goed testscript en testverslag. 

Tip 1: Onderzoek of bij asynchrone processen, zoals handmatige goedkeuringen, of er mogelijkheden zijn deze stappen meteen door te zetten. Je wilt niet vast komen te zitten tijdens het ketentesten. Maak bijvoorbeeld gebruik van mailboxen waar alle testers bij kunnen om communicatie af te vangen. 

Tip 2: Als er meerdere afdelingen betrokken zijn bij een keten zorg er dan voor dat deze personen samen in één ruimte zitten. Zo kan de hand-over soepel verlopen en wordt de testtijd zo optimaal mogelijk benut. 

Test management is een kritische component van elk softwareproject. Het stelt teams in staat om niet alleen individuele modules te testen, maar ook de integratie van verschillende onderdelen, waardoor de algehele kwaliteit en prestaties van het project worden verbeterd. Elke hertest of bug die hiermee kan worden voorkomen, bespaart tijd en geld. 

Door een robuuste teststrategie toe te passen, inclusief FAT, GAT, PAT en ketentesten, kunnen projecten niet alleen technische fouten minimaliseren maar ook voldoen aan de verwachtingen van de klant en de uiteindelijke gebruikers. Dit alles verhoogt de kans op succes van het project en versterkt het vertrouwen van de stakeholders. 

Bij het aanpakken van uitdagingen en zelfs bij grote IT change trajecten, is het verleidelijk om in stoeptegels te denken. Maar wat je aan de voorkant aanraakt, heeft impact op de rest van de keten. Zo zijn jouw markt, de business en IT nauw met elkaar verbonden, evenals alle applicaties in jouw landschap. Wij geloven in de kracht van het samenbrengen van verschillende business en IT-professionals, die hun inzichten met elkaar, met de mensen in jouw organisatie en met externe leveranciers verbinden. Risico's en obstakels vang je daardoor vroegtijdig af. Door vanuit alle invalshoeken naar een IT-deliverable te kijken en het echt SAMEN te doen, lever je bovendien een duurzaam goed resultaat op dat door iedereen wordt gedragen.