Het eerste deel over computer aided software testing toonde het gemak van relationele databases. Het testen van software kan verder worden vereenvoudigd door het gebruik van tools ‘die in staat zijn tot automatische interpretatie van uitvoer’. Aldus Jan Erik van der Laan in zijn tweede artikel.
Dagelijks nemen wij onvoorstelbaar veel beslissingen; vaak bewust, maar nog vaker onbewust. Bij deze beslissingen laten we ons benvloeden door allerlei factoren waar we dan ook nog eens verschillende betekenissen aan koppelen. De ene dag nemen we als het regent een paraplu mee naar buiten, terwijl we de andere dag lachend zonder plu in de regen gaan staan. De factoren die bij zo’n beslissing een rol spelen zijn legio, zoals: draag ik een kostuum of een zwembroek, bevind ik mij in het centrum van de stad of in mijn achtertuin, is de buitentemperatuur onder de 15 of boven de 30 graden, enzovoorts. En zelfs àls u tijdens een stortbui in uw zwembroek in uw achtertuin staat bij een temperatuurtje van 33 graden, kunt u in een dolle bui besluiten om "ter lering ende vermaak" van de buurt een rondje met uw paraplu en een bolhoed door de tuin te paraderen.
We zijn (gelukkig) nog een heel eind verwijderd van de computer die dit soort ‘onvoorspelbare’ beslissingen neemt. Een computer neemt tenslotte beslissingen op basis van factoren, of zo u wilt parameters, welke volgens de programmeur bij het beslissingsproces moeten worden betrokken. Wanneer we nu op eenvoudige wijze (beslissings-)factoren kunnen toevoegen aan het geautomatiseerde testproces, wordt de weg geopend naar een interessante ontwikkeling.
Financiële applicatie
Stel u bent zelf handmatig aan het testen. U heeft een financiële applicatie waarin u bijvoorbeeld een overzicht kunt opvragen van de totaal betaalde huur voor uw bedrijfspand tot op de huidige datum. In uw testscript staat beschreven wat u moet doen om de gegevens op uw scherm te krijgen. Tevens is in de uitvoerverwachting beschreven dat het getoonde saldo gelijk dient te zijn aan het aantal maanden maal de huurprijs per maand. Het is februari en de huurprijs per maand bedraagt 4.000 gulden. U berekent dat het saldo nu 36.000 gulden moet zijn (9 * 4.000) en u vergelijkt dat met het op het scherm getoonde saldo. U interpreteert hiermee de getoonde gegevens en valideert deze, indien correct, als juist.
Dit is een zeer simpel voorbeeld (zie figuur 1) 
dat we iets gecompliceerder kunnen maken door de datum van betaling in de interpretatie mee te nemen. Stel dat de datum waarop de huur wordt betaald is vastgesteld op de 21e van de maand (zon- en feestdagen laten we buiten beschouwing). Dit is tevens in uw testscript beschreven. De test wordt uitgevoerd in september. U verwacht in eerste instantie een saldo van 36.000 gulden; er wordt echter een saldo van 32.000 gulden getoond. U checkt de datum en ziet dat het vandaag de 19e is en dat de huur voor de maand september dus nog niet betaald is. U heeft nu een additionele factor bij uw interpretatie van de uitvoer betrokken.
Voor een menselijke tester is het bovenstaande simpel genoeg. Wanneer er echter gebruik gemaakt wordt van een tool voor computer aided software testing (cast), zal het bovenstaande simpele voorbeeld vaak problemen opleveren. Nu zult u misschien zeggen dat dit in de praktijk niet voorkomt omdat de testomgeving altijd met één en dezelfde datum werkt, en dat het saldo dus ook altijd gelijk zal zijn. Wanneer u in die omstandigheid verkeert, mag u zichzelf gelukkig prijzen.
Voor veel organisaties is het echter niet mogelijk om de huidige datum (=systeemdatum) ten behoeve van de test aan te passen. Denk bijvoorbeeld aan een mainframe-omgeving waar veel gebruikers gelijktijdig actief zijn. Wanneer één gebruiker dan de systeemdatum aanpast om zijn test te kunnen draaien, wordt hij waarschijnlijk door zijn collega’s uit het raam gekieperd. Z�j hebben namelijk wèl de huidige datum nodig.
Een andere truc kan zijn dat de applicatie de huidige datum niet afleidt van de systeemdatum, maar dat er een variabele is die normaliter de systeemdatum bevat maar die voor testdoeleinden een andere datum kan bevatten. U kunt zich echter voorstellen dat deze oplossing door EDP-auditors en accountants niet wordt toegejuicht, vooral niet wanneer het financiële toepassingen betreft!
Overigens komt deze problematiek ook om de hoek kijken bij applicaties en/of systemen waarbij de datum wel kan worden aangepast; denk maar aan voortschrijdende tests.
Dynamisch karakter
Een cast-tool kan onder voorwaarden interpretaties, zoals die hiervoor beschreven, automatisch uitvoeren. Het tool dient hiervoor de mogelijkheid te bieden om variabelen te definiëren en over de logica te beschikken om beslissingen te nemen op basis van de inhoud van deze variabelen. Daarnaast moet het mathematische bewerkingen kunnen uitvoeren op basis van deze variabelen.
De door het cast-tool te nemen beslissingen worden gedefinieerd op basis van de uitvoerverwachting.
De volgende variabelen en logica zijn nodig om het hiervoor beschreven voorbeeld over het huursaldo te kunnen interpreteren.
De statische variabele HUUR dient vooraf te zijn gevuld. De dynamische variabelen MAAND en DAG worden tijdens de test gevuld aan de hand van de op het scherm getoonde systeemdatum. Het cast-tool dient dus te beschikken over de mogelijkheid om dynamisch gegevens uit het applicatiescherm te lezen en deze op te slaan in daarvoor gedefinieerde variabelen.
De dynamische variabelen SALD1 en SALD2 worden gevuld aan de hand van de inhoud van de variabelen HUUR en MAAND.
Het cast-tool dient dus tevens te beschikken over de mogelijkheid om variabelen te vullen op basis van de inhoud van andere variabelen en mathematische regels.
Naast de bovenstaande mogelijkheden dient het cast-tool de logica in huis te hebben om tijdens het testen beslissingen te nemen op basis van de actuele uitvoer. Het verloop van de test van het beschreven voorbeeld zou er kunnen uitzien, zoals weergegeven in figuur 2. Wanneer het huurbedrag per maand in één van de gepasseerde schermen wordt getoond, zouden we het dynamische karakter van de test nog kunnen uitbreiden door deze waarde in HUUR te laten inlezen.
In het bovenstaande voorbeeld wordt van de variabelen SALD1 en SALD2 gebruik gemaakt om de bij ‘Saldo’ in het applicatiescherm getoonde uitvoer te valideren. Is het cast-tool zo geavanceerd dat het de waarde die in een variabele is opgeslagen tevens als invoer kan gebruiken, dan kunnen we zelfs het verloop van de test volledig dynamisch maken.
Let hierbij echter wel op! Het cast-tool dient dan ook een dynamisch testpad te kunnen aflopen; anders zou de uitvoer niet overeenkomen met de verwachting. Er kan dan op een scherm gevraagd worden wat de uitvoer in een bepaald veld (of velden) is, waarna op basis van die waarde een bepaalde invoer gegeven wordt. Deze functionaliteit kan tevens worden gebruikt om een test tijdens uitvoering te herstellen (recovery). Wanneer tijdens het uitvoeren van de bovengenoemde test blijkt dat er na het intoetsen van een letter geen gegevens op het scherm verschijnen terwijl deze wel worden verwacht, kan men een ander testpad kiezen, dat ervoor zorgt dat de gegevens in het bestand worden ingevoerd. Hierna kan de test weer verder gaan of opnieuw aanvangen. Het is hiermee zelfs mogelijk om, in het geval er tijdens een test problemen optreden (of juist wanneer de test zonder problemen verloopt), de verantwoordelijke tester op te ‘piepen’ en hiervan in kennis te stellen.
Programmeurs weg
De meeste cast-tools bieden de hierboven beschreven functionaliteit niet. En indien dat wel het geval is, kon dat alleen door op zeer technische wijze te programmeren.
Het grote nadeel van de noodzaak tot programmeren of scripten in een cast-tool is dat deze programma’s of scripts zelf ook weer getest moeten worden.
Slechts enkele cast-tools zijn er die deze functionaliteit standaard bieden zonder dat er veel technische kennis en of programmering vereist is. Deze tools bieden geïntegreerde variabelen en recoveries waarmee de hier beschreven functionaliteit eenvoudig kan worden gebruikt. Hiervoor is dan geen programmering vereist, waardoor cast niet meer alleen voorbehouden is aan programmeurs. In feite dienen z�j zich ook niet met cast bezig te houden, maar speciaal opgeleide testers en quality assurance personeel. Waarom dat zo is, wordt duidelijk in het derde en laatste deel van deze serie over ‘computer aided software testing’.
Jan-Erik van der Laan is werkzaam als general manager/QA-consultant bij QES/Europe te Joure.
