Hulpmiddelen bij testautomatisering mogen zich verheugen in een snel groeiende markt. Toch vallen de resultaten vaak nog tegen, vooral ten aanzien van flexibiliteit en toegankelijkheid. Dergelijke bezwaren doen zich volgens CMG-consultant Hans Buwalda niet voor bij zijn nieuwe aanpak voor automatisch testen. Die onderscheidt zich ondermeer doordat de vastlegging van testgegevens plaatsvindt buiten het cast-tool, namelijk met ‘actiewoorden’ in spreadsheets.
Testen wordt vaak onderschat. Dit onderdeel van het ontwikkelproces evenaart het programmeren vaak in omvang of overtreft het zelfs, met name als ook alle ‘verborgen’ testactiviteiten worden meegerekend, zoals het testen van de eigen programma’s door programmeurs. Testactiviteiten slokken 30 procent of meer van de totale automatiseringskosten op. Bij projecten betreffende de Euro-conversie en de ‘jaar 2000’- problematiek kan dat zelfs oplopen tot 50 procent of meer.
Testen is echter nodig. Niet testen betekent dat fouten niet worden gevonden, en fouten zijn risico’s voor de productiefase van een systeem. Zelfs één fout kan er al toe leiden dat bijvoorbeeld een hele productierun van een salarisverwerkend systeem mislukt. De kosten daarvan kunnen aanzienlijk zijn.
Desondanks is testen niet populair. De manager vindt het duur. Voor de tester is het vervelend werk, vooral als dezelfde tests steeds moeten worden herhaald.
Het is dus logisch dat testautomatisering veel belangstelling trekt. De eenvoudigste en waarschijnlijk meest toegepaste vorm van testautomatisering is het ‘schaduwdraaien’ van nieuwe versies van voornamelijk batchsystemen. Daarbij krijgt de nieuwe versie dezelfde gegevensbestanden te verwerken als de al in gebruik zijnde versie. De uitkomsten moeten vervolgens ook identiek zijn, althans voor die gegevens die niet bij de systeemwijziging waren betrokken. Dit is soms vast te stellen door uitvoerbestanden met elkaar te vergelijken met behulp van een hulpprogramma. Soms ook moeten verschillen handmatig worden vastgesteld door geprinte uitvoerlijsten met elkaar te vergelijken. Schaduwdraaien is een redelijk bruikbare techniek, maar niet erg flexibel. Ze is alleen toepasbaar in situaties waarbij de functionaliteit van een systeem weinig verandert. Er kan veel werk gemoeid zijn met het verklaren van verschillen tussen de uitvoerresultaten, ook als deze niet het gevolg zijn van fouten in het nieuwgebouwde systeem.
‘Record & playback’
Een techniek die op dit moment erg in de belangstelling staat is ‘record & playback’, ofwel opnemen en afspelen. Bij deze werkwijze, vooral toepasbaar voor online systemen, wordt gebruik gemaakt van een geautomatiseerd testhulpmiddel: een ‘cast-tool’ (computer aided software testing). Er zijn veel van dit soort cast-tools op de markt. De meeste draaien op standaard PC’s, maar er bestaan ook pakketten voor mainframes of Unix-systemen. Hun voornaamste functie is het opnemen en naderhand weer afspelen van gebruikershandelingen in de vorm van ’testscripts’. Het cast-tool is daarbij zelf onzichtbaar voor zowel de gebruiker (de tester) als het te testen systeem. Het te testen systeem kan op de PC zelf draaien, maar ook op een minicomputer of mainframe, waarbij de aansturing plaatsvindt via een terminalprogramma. De gebruiker kan het opnameproces onderbreken om een ‘check’ aan te maken. Bij het afspelen van de test controleert het cast-tool dan zelf of op het scherm een waarde staat, identiek aan de waarde die er op het corresponderende moment bij het opnemen stond.
In tegenstelling tot het schaduwdraaien moet ‘record & playback’ als techniek voor testautomatisering eigenlijk dringend worden afgeraden. De opgenomen testscripts zijn erg afhankelijk van specifieke eigenschappen van de systeeminterface, zoals de indeling van de gegevens over de schermen. De kans dat zelfs een kleine systeemaanpassing grote delen van de opgenomen tests onbruikbaar maakt, is onaanvaardbaar hoog. Ook zijn opgenomen testscripts moeilijk toegankelijk. De testscripts worden weliswaar in de meeste cast-tools vastgelegd in de vorm van een soort scripttaal die met een programma editor is te bewerken, maar het betreft gegenereerde code. Zeker voor een niet-automatiseerder is moeilijk af te leiden wat er op functioneel niveau precies in de test is gebeurd.
Een betere variant is ‘gegevensgestuurde record & playback’ (data driven record & playback). Daarbij wordt een met ‘record & playback’ opgenomen script handmatig aangepast, zodat deze een serie van soortgelijke transacties kan verwerken. Er wordt dus bijvoorbeeld een test opgenomen waarbij een klant met de naam ‘J. Jansen’ wordt ingevoerd, gevolgd door een aantal gegevens, zoals geboortedatum en saldo. Daarna verwijdert een programmeur deze ‘harde’ gegevens uit het opgenomen testscript en vervangt ze door een soort variabelen, die vervolgens seriegewijs worden ingelezen uit een bestand. Deze werkwijze vermindert de hoeveelheid inspanning om de tests in te brengen en om ze aan te passen als er in het te testen systeem wijzigingen zijn. Een nadeel is echter de moeilijke beheersbaarheid van het proces. Er moet als het ware een systeem naast het systeem worden gebouwd en het blijft voor een buitenstaander lastig om te zien wat er nou precies gebeurt. Dit geldt vooral als behalve invoer ook uitvoerverwachtingen vanuit een bestand ingelezen moeten worden. Verder is de vorm van de records van het testbestand min of meer vast. Daardoor is het moeilijk om complexere scenario’s te bepalen waarbij verschillende gegevens na elkaar worden vastgelegd, bijvoorbeeld een werknemer met een aantal kinderen en een lease-auto in een personeelsinformatiesysteem.
Alternatieve cast-methode
Om een goed resultaat te verkrijgen moet automatisch testen niet alleen worden gezien als een kunstje om tests handig uit te voeren. De hele werkwijze, van testplanning tot testbeheer, moet erop worden aangepast. Dit is te vergelijken met de komst van auto’s op de markt, een eeuw geleden. De eerste modellen leken op een koets met een motor in plaats van paarden. Hoewel de motor ook bij de huidige auto maar één van de onderdelen is, is wel het hele ontwerp erop aangepast en lijkt de auto absoluut niet meer op een koets.
Volgens dit principe is de methode ‘CMG:cast’ ontwikkeld. Testautomatisering vormt daarvan een essentieel onderdeel, waarop het veel grotere geheel van activiteiten is afgestemd.
Hier kijken we vooral naar de wijze waarop de testgevallen worden vastgelegd en geautomatiseerd worden uitgevoerd, omdat dit de basis is voor alle overige activiteiten in de methode. Daarbij wordt een aantal uitgangspunten gehanteerd die afwijken van de eerder genoemde werkwijze met opgenomen scripts. De belangrijkste daarvan volgen hieronder.
Er wordt een scheiding gemaakt tussen testontwikkeling en testuitvoering. Verder vindt de vastlegging van de testgegevens plaats buiten het cast-tool, namelijk in spreadsheets – ook wel ’testclusters’ genoemd; de rijen in de spreadsheets heten ’testregels’. Elke testregel begint met een speciaal veld in de A-kolom: het ‘actiewoord’, op te vatten als een opdracht aan het cast- tool. Deze actiewoorden zijn specifiek voor de toepassing die wordt getest. Tenslotte wordt voor de uitvoering van de tests wel gebruik gemaakt van een standaard cast-tool. In de script-taal van het cast-tool wordt een soort test-interpreter gebouwd: het ‘navigatiescript’.
Testclusters en actiewoorden
Hoewel de cast-tool niet meer gebruikt wordt om de testgegevens zelf vast te leggen, speelt deze dus nog wel een belangrijke rol, namelijk bij het uitvoeren van de door de actiewoorden gespecificeerde acties op het onderliggende systeem. Die acties kunnen zijn: het invoeren van gegevens, het starten van een verwerkingsslag of het vergelijken van een uitkomst met een verwachte waarde. Voorbeelden van actiewoorden zijn: ‘voer op cliënt’, ‘check saldo’ of ‘start einde-dag verwerking’. Bij elk actiewoord hoort een vaste procedure die door het cast-tool moet worden uitgevoerd – echter met steeds andere gegevens. Die zijn te vinden in de kolommen B, C enzovoort. Dat kunnen in te voeren gegevens zijn, zoals de adresgegevens van een klant, maar ook verwachte uitkomsten. Een voorbeeld daarvan is een eindsaldo of zelfs de tekst van een foutboodschap die moet optreden omdat er met opzet een fout is ingevoerd om aldus een schermcontrole te testen. Het aantal kolommen is afhankelijk van het actiewoord en zal dus per testregel verschillen. Afhankelijk van het te testen systeem worden de acties �f online uitgevoerd, waarbij het cast-tool allerlei schermhandelingen verricht, �f batchgewijs. Daarbij zet het cast-tool de gegevens in één of meer invoerbestanden, start een batchproces op en voert, na afronding daarvan, controles uit op de resulterende uitvoerbestanden.
Figuur 1 toont een fragment van een eenvoudig testcluster voor een systeem voor betalingsverkeer van een denkbeeldige bank. In dit voorbeeld is een aantal van de soorten actiewoorden te zien die in de praktijk voorkomen. Allereerst wordt een aantal zogeheten ‘documentaire’ woorden gebruikt, namelijk ‘cluster’, ‘auteur’, ‘versie’ en ‘datum’. Deze woorden hebben geen directe invloed op het testproces zelf, maar zijn bedoeld voor het beheren van de cluster en, na uitvoering van de test, van het resulterende rapport. Vervolgens wordt een aantal voor deze test benodigde basisgegevens ingevoerd met het actiewoord ‘voer op cliënt’. Daarna wordt een overboeking gedaan met ‘boek over’ en worden controles uitgevoerd met ‘check saldo’. Kolom A bevat steeds de actiewoorden. De kolommen B tot en met D bevatten de bij de actiewoorden behorende gegevens, waarvan de aard en het aantal afhankelijk zijn van het actiewoord. Als er geen actiewoord in kolom A staat, wordt de betreffende regel bij uitvoering van de test overgeslagen, zodat er kopregels boven de gegevens te gebruiken zijn ter verbetering van de leesbaarheid. Ook de in het testcluster gebruikte lay out-kenmerken, zoals het benutten van verschillende lettertypen, dienen alleen de leesbaarheid en hebben geen invloed op het testproces.
Voor het realiseren van de individuele actiewoorden binnen het cast-tool is eventueel de ‘record & playback’-methode te gebruiken. Bij grotere tests is het echter doelmatiger om voor het realiseren van de actiewoorden een speciale functionaris aan te wijzen: de ‘navigator’. Deze taak moet worden opgenomen binnen een project en, na oplevering van het systeem, de status krijgen van permanente taak binnen de organisatie. De navigator zorgt voor de installatie en bediening van het cast-tool en implementeert de actiewoorden. Een ander onderdeel van de taak is ervoor te zorgen dat voor vergelijkbare acties steeds dezelfde actiewoorden gebruikt worden.
Toegankelijk
Een belangrijk aspect van de methode is de toegankelijkheid van het testproces voor niet-automatiseerders. Zowel de clusters als de rapportages zijn door het ontbreken van technische details goed leesbaar voor niet-automatiseerders, zoals eindgebruikers die bij een functionele acceptatietest worden betrokken of edp-auditors (electronic data processing) die een oordeel over de tests moeten geven. Ook het rapport dat bij het uitvoeren van de tests door het navigatiescript wordt aangemaakt, is toegankelijk voor niet-automatiseerders. De methode is te gebruiken voor allerlei soorten tests, zoals programmatests, systeemtests, prestatietests en acceptatietests. Met name bij acceptatietests worden behalve navigators ook nog ’testanalisten’ ingezet: mensen met een bedrijfskundige achtergrond, die in samenwerking met eindgebruikers de testclusters opstellen. Het ontwikkelen van deze clusters is grotendeels een eenmalige activiteit. Ook als er op het laatste moment nog wijzigingen in een systeem worden aangebracht – wat maar al te vaak gebeurt in projecten – kan de navigator die meestal opvangen door een beperkt aantal actiewoorden aan te passen. Het veel grotere aantal testregels dat met de betreffende actiewoorden begint, zal vervolgens zonder problemen weer werken. Ook in de onderhoudsfase is de testverzameling op dergelijke wijze steeds actueel te houden. Nieuwe inspanningen voor de testclusters zijn alleen nodig als er functionele wijzigingen in een systeem plaatsvinden, en ook dan zijn de inspanningen beperkt.
Het uitvoeren van de tests en het interpreteren van de resultaten kan bij een nieuw systeem overigens nog een aanzienlijke inspanning met zich meebrengen. Als een werkelijke uitkomst afwijkt van de verwachte, kan immers ook de test onjuist zijn. Zelfs de navigatie kan voor onterechte afwijkingen zorgen, hoewel dit verschijnsel beperkt is door het relatief beperkte aantal actiewoorden.
Toepassing in de praktijk
Met de methode is inmiddels aanzienlijke praktijkervaring opgedaan. Ondermeer bij financiële instellingen, handel en industrie wordt de methode veel ingezet – ook in het buitenland. Om de methode te introduceren wordt meestal eerst een pilot gedaan, zodat de organisatie de werkwijze in de praktijk kan leren kennen. Dit is nodig omdat invoering van de methode een volledig nieuwe manier van werken betekent, waaraan de direct betrokkenen eerst moeten wennen. Toch wordt het werken met clusters en actiewoorden snel populair, omdat inspanningen om tests te ontwikkelen slechts eenmalig gepleegd hoeven te worden. Bovendien valt het vervelende werk van steeds opnieuw met de hand invoeren van testgegevens weg. Ook het uitvoeren van de tests gaat veel sneller, waardoor het mogelijk is zelfs bij kleine wijzigingen alle functionaliteit van een systeem opnieuw te testen. Hierdoor worden de beruchte ‘knock on’ fouten, waarbij een wijziging in één deel van een systeem een fout in een andere gedeelte tot gevolg heeft, opgespoord.
De meeste organisaties starten met het toepassen van de methode binnen één van de lopende systeemontwikkelingsprojecten, vaak het systeem waarop ook de pilot is uitgevoerd. Nadat de methode in één of enkele projecten is geïntroduceerd, ontstaat de behoefte aan coördinatie, met name op het gebied van kennisopbouw rond de methode. Dit kan het best gebeuren bij een centrale afdeling, zoals het geval was bij drie grote banken. Vanuit deze afdeling worden procedures ontwikkeld en ervaringen verzameld. Ook de externe contacten met bijvoorbeeld de leverancier van het cast-tool worden vanuit dit punt gecoördineerd.
Een gestructureerde aanpak is voor de toepassing van automatisch testen nog belangrijker dan voor een handmatig testtraject. Het schema in figuur 2 kan helpen om de gedachten te bepalen. Hierin is de fasering van de methode weergegeven. De fasen lopen van het bepalen van de testorganisatie en testprocedures tot het beheren en onderhouden van de testverzamelingen (clusters en navigatiescript). Achter al deze fasen zit een aantal technieken en hulpmiddelen, zoals diverse methoden voor het bepalen van testgevallen, standaardmodules voor het navigatiescript en algemene componenten, zoals een richtlijn voor risico-analyse. Eén van de activiteiten is het selecteren van het cast-tool. De methode is niet gebonden aan één bepaald tool. De meeste op de markt verkrijgbare tools zijn inzetbaar. De keuze is vooral afhankelijk van de technische randvoorwaarden, bijvoorbeeld gebruikte besturingssystemen en ontwikkelomgevingen.
Kostenbesparing
De methode is inmiddels populair en leidt vaak tot positieve resultaten. Het aantal projecten breidt zich snel uit. Voorbeelden van toepassingen waarvoor geautomatiseerde tests zijn ontwikkeld, zijn: een handelssysteem voor een beurs, een hypotheeksysteem bij een grote bank, een groot batchsysteem voor betalingsverkeer bij een andere financiële instelling, een levenverzekeringssysteem bij één van de grote verzekeringsmaatschappijen, een ‘jaar 2000’-project bij een grootwinkelbedrijf en een logistiek systeem voor een groot koeriersbedrijf. Ook in een aantal landen buiten Nederland is inmiddels een snelle groei in de projecten waar te nemen. De redenen om de methode in te zetten lopen uiteen van betere beheersbaarheid van het testproces tot kostenbesparingen, omdat tests steeds weer opnieuw te gebruiken zijn.
Tot slot is een woord van voorzichtigheid op zijn plaats. De gepresenteerde aanpak kan een goede bijdrage leveren, maar moet niet worden beschouwd als een wondermiddel: testen blijft moeilijk en kost altijd geld en tijd (testen is per definitie iets dubbel doen, anders is het geen testen meer). Ook is deskundige begeleiding een absolute voorwaarde om tot een succesvolle inzet te komen.
Een volgend artikel beschrijft hoe de hier beschreven methode is toegepast op de Euro- en ‘jaar 2000’-projecten van een aantal grote banken.
Drs. H.W.J. Buwalda is senior management consultant bij CMG Finance.
