Variabele testdata bij testscripts en testautomatisering

Het gebeurt regelmatig, maar het mag niet bestaan: variabele testdata. Een testomgeving waar je niet in staat bent om een oude database in een handomdraai terug te zetten. Of waar de testdata automatisch verouderd in de tijd, doordat deze tijdgerelateerd is. Het lijkt soms testautomatisering onmogelijk te maken en regressietesten in het algemeen zeker niet eenvoudiger. Toch zijn er manieren om ook in deze situaties, zowel handmatig als automatisch, een goede regressietest uit te voeren.

De datum in de testdata

Het meest voorkomende probleem en ook het meest eenvoudige is de datum in de testdata. Denk bijvoorbeeld aan personen die jonger moeten zijn dan 1 jaar of een actie die in een bepaalde periode loopt. Bij testen moet je op een bepaald moment een concrete datum invoeren. Maar in je testscript en in je testautomatisering heb je dit liever niet.

Voor een beschreven testscript is dit probleem eenvoudig op te lossen: zet geen concrete datum neer, maar beschrijf de datum. Bijvoorbeeld als "Vandaag + 7 dagen", "21e van de volgende maand" of "Volgende week donderdag". Op deze wijze kan iedereen die het testscript uitvoert, zelf een datum bepalen.

Bij testautomatisering werkt het niet anders, maar wel wat moeilijker. Veel testautomatisering hulpmiddelen zijn uit te breiden via een programmeertaal. En een functie toevoegen om een datum te berekenen op basis van een aantal voorwaarden, is vaak niet het moeilijkste programmeerwerk. Als je een beetje kan programmeren, kan je het zelf. Maar anders kan je met een uurtje tijd van een ontwikkelaar al heel veel functies aan je testautomatiseringstool toevoegen om de datum naar jouw wensen te berekenen en te gebruiken in je automatische testscript.

Voor Selenium IDE kan je bijvoorbeeld een functie maken die bij vandaag een zelf te bepalen aantal dagen optelt. Deze wordt vervolgens in een variabele opgeslagen. Voor diegene die Selenium IDE niet kennen: als je een variabele wil maken, geef je in de ene kolom de waarde op en in de andere kolom de variabele. Bij deze functie wordt in de eerste kolom het aantal dagen na vandaag gezet. Hierna wordt op basis van dit getal een nieuwe datum berekend. Deze datum wordt vervolgens omgezet naar een tekst die in een variabele wordt opgeslagen. Zie hieronder het resultaat.

Variabele testdata voor het testen

Niet elke testomgeving is professioneel genoeg om de testdata stabiel te houden. Je hebt niet altijd de mogelijkheid een oude database terug te zetten. En soms heb je te maken met externe testdata, waar je helemaal geen controle over hebt. In dat geval kan je je testscript, al of niet geautomatiseerd, niet steeds op dezelfde data baseren. Omdat de data in de toekomst anders kan zijn dan vandaag.

Het meest eenvoudig, maar wel het meeste werk, is om een voorbereidingstestscript toe te voegen. In dit testscript maak je alle testdata aan die je voor je test nodig hebt. Bijvoorbeeld een persoon die woont in Amsterdam of een actie die loopt vanaf vandaag voor twee weken. Voor de duidelijkheid is het handig om deze voorbereiding of in een geheel apart testscript te zetten of in het testscript apart te benoemen/markeren.

Omdat dit voorbereidingstestscript snel veel tijd gaat kosten, is het handig dit te automatiseren. Ook als je voor de rest (nog) geen testautomatisering. Het zijn vaak veel tijdrovende handelingen, maar de eisen voor de testautomatisering zijn veel lager. De automatisering voor het aanmaken van de testcase is heel eenvoudig. Elk gratis beschikbare record-and-play tool is geschikt. En je kan meteen je testautomatisering kennis opbouwen. Dus als testautomatisering nog een stap te ver is, overweeg dan serieus of dit misschien wel een stap is die te nemen is.

Maar soms kan je de data niet zelf aanmaken. In dat geval is het verstandig om in je testscript met variabelen te werken. In de testautomatisering werkt dit zeer eenvoudiger. Elke automatische testtool heeft mogelijkheden om variabelen aan te maken en deze verderop in het script te gebruiken. Zie hieronder een voorbeeld in Selenium IDE.

In een handmatig testscript zijn er meerdere opties. Als je handig bent met Excel, dan kan je de testdata in een apart tabblad zetten. Vervolgens gebruik je dit veld in je testscript wanneer je de waarde wilt gebruiken.

Heb je deze handigheid niet, dan kan je bovenin je testscript de testdata zetten. Wanneer je deze dan vervangt, gebruik je de "Vervang tekst" functionaliteit in je programma. De bovenin weergegeven testdata gebruik je om te weten wat de huidige data is. En wanneer je deze tekst vervangt voor de nieuwe waarde, vervang je deze meteen voor het hele testscript.

Als laatste kan je ook gebruik maken van variabelen in je testscript, bijvoorbeeld op de volgende wijze: "[Achternaam]". Deze variabelen kan je dan in een ander document een waarde geven. Deze laatste heeft als groot nadeel dat je twee documenten nodig hebt bij het testen. Maar deze methode is wel minder foutgevoelig dan het automatisch vervangen van tekst.

Vind de methode die bij jou en je bedrijf past. En maak het beste van variabele testdata.

Twee Agile testscript voorbeelden

Het standaard testscript is in de vorm van lange tabellen. Tabellen waarin elke stap onder elkaar wordt uitgewerkt. Hoewel ik het zelf vaak gebruikt heb, heb ik al snel ervaren dat het template niet voldeed aan mijn eisen. Ik wilde een testscript dat snel aanpasbaar was, waar ik niet hoefde te zoeken naar de te wijzigen plaatsen. En hoe meer ik Agile ging testen, hoe groter deze behoefte werd. Dus door de jaren heen ontwierp ik mijn eigen, nieuwere vorm van het testscript.

De belangrijkste wijziging is dat de stappen niet meer onder elkaar staan. De te volgen stappen staan in kolommen naast elkaar. Als gevolg hiervan kan je, als een stap wijzigt, de volledige kolom snel controleren. Daarnaast kan je eenvoudig een kolom toevoegen, als er een onderdeel in de applicatie wordt toegevoegd.

Ik heb twee verschillende basisvormen: het entiteiten testscript en het stappenplan testscript. Het entiteiten testscript is vooral bedoeld voor veel invoer, maar weinig controle. Het stappenplan testscript voor weinig invoer, maar veel controle.

Het entiteiten testscript

Elke kolom staat voor een entiteit (een losstaand object), in dit geval de reiziger, zijn abonnement en de gemaakte reis. In de laatste kolom wordt vastgelegd welke controles er uitgevoerd moeten worden. Bij dit testscript maakt het niet uit hoeveel schermen er nodig zijn om bijvoorbeeld de reis in te voeren. Dit kunnen er 3 zijn, maar 1 kan ook. Ik ga ervan uit dat iedereen die dit testscript uitvoert, weet welk gegeven van de reis in welk scherm ingevoerd moet worden.

Stel dat het tijdstip van de reis bij verdere uitwerking van de testcases ook van belang blijkt te zijn. In dat geval kan je de kolom Reis controleren en verder aanvullen. En als de vervoerder van belang wordt, bijvoorbeeld omdat deze verschillende regels hanteren, kan je deze met een nieuwe kolom toevoegen.

Het stappenplan testscript

Elke kolom is de invoer in een scherm of de controle van een scherm. Als dit nodig is, kan je zelfs een kolom gebruiken voor de invoer of controle van een deel van een scherm. Doordat dit testscript door de opdeling in stappen al meer beschrijvend is, hoeft diegene die de test uitvoert over minder kennis te beschikken. Daarnaast kan de controle en de invoer direct in de juiste stap gedaan worden.
Als er nu bijvoorbeeld standaard administratiekosten berekend gaan worden, is het controleren van de kolom "Controle kassabon"  en "Controle bevestigingsmail" voldoende. En als er een stap wordt toegevoegd om zelf je afhaalpunt te kiezen, dan kan je een kolom "Afhaalpunt" toevoegen.

Een Agile testscript

Het schrijven van een testscript komt vaak overeen met het schrijven van allesomvattende testdocumentatie. Of het bijdraagt aan werkende software is vaak de vraag. Agile en testscript lijken dan in tegenspraak met elkaar. Maar het testscript is toch niet voor niets uitgevonden? Kan het binnen Agile testen dan niet een waardevol middel zijn?

In een Agile omgeving is het van belang dat het werk van teamleden overgenomen kan worden door andere teamleden. Van de ene tester in het team naar de andere tester in het team. En soms zelfs van een tester naar een ontwikkelaar. Daarnaast kom je ook als tester in een Agile omgeving de volgende situatie nog steeds tegen: ingewikkelde processen testen kost veel tijd, als je bij de start van het testen er geen kennis over hebt. Als je het kennis vergaren eerder kan doen, kan je de testuitvoering flink in tijd verkorten. Oplossing voor beide situaties: het testscript. Wanneer iedereen in het team een testscript kan begrijpen, kan het ook door iedereen uitgevoerd worden. En als complexe processen alvast voorbereid zijn met een testscript, dan kan je, na het afbouwen, sneller de testen uitvoeren. Zodat je team sneller weet hoe de kwaliteit is en dichter op de bouw eventuele fouten op kan pakken.

Dat betekend niet dat het verstandig is om meteen hele grote, uitgebreide, gedetailleerde testscripts te schrijven. In je team kan je uitgaan van een zekere basiskennis van de applicatie. Al je teamleden zouden in staat moeten zijn om in b.v. een loonadministratie een nieuwe medewerker in te voeren en een loonbatch te starten. Waar het om gaat, is dat je als tester die informatie vastlegd, die ze niet weten: jouw testkennis. En wat is die kennis? Die kennis zijn de testcases, die door jou, op basis van je ervaring en je kennis als tester zijn opgesteld. Die testcases leg je vast in een testscript. Zodat iedereen in het team, ook zonder jouw kennis en ervaring, goed kan testen.

Welke gegevens leg je vast en welke gegevens niet? De gegevens die je minimaal vastlegd, zijn de gegevens die leiden tot het gewenste te controleren resultaat. Als je dus wilt controleren of een medewerker recht heeft op een bepaalde 50+ regeling, dan is het niet nodig in het testscript vast te leggen wat de naam, het adres en de functie van een medewerker is. Wat je wel vast moet leggen, is welke geboortedatum je invoert. Zo kan je bijvoorbeeld ervoor zorgen dat iedereen de juiste randgevallen test. In dit geval 49, 50 en 51 jaar.

Daarnaast leg je datgene vast wat je wil controleren. Stel dat bij iemand van 50+ op het scherm een speciale 50+ merkteken getoond wordt. Leg dan alleen vast dat hierop gecontroleerd moet worden. Het controleren van alle andere gegevens is niet nodig, dat ben je op dit moment niet aan het testen.

Houdt de beschreven invoer en de beschreven controles op deze wijze zo kort mogelijk, zodat de documentatie compact blijft. Je kan zelf bepalen of je de beschrijving van de invoer op logisch (<50, 50, >50) of fysiek niveau (49 jaar, 50 jaar, 51 jaar) vastlegt. Dit kan van de te testen procedure, de uit te voeren test en/of van het team afhangen. Als je twijfelt, kies dan voor de meest voorschrijvende methode, het fysieke niveau. Dit is vaak nauwelijks meer werk en wordt in ieder geval altijd goed overgenomen.

Een testscript schrijven voor Agile kan dus handig zijn. Vooral als overdragen mogelijk moet zijn of om testtijd te besparen in het latere deel van het traject. Maar houd je document zo compact mogelijk, door alleen die gegevens vast te leggen die je teamleden minimaal nodig hebben om de test uit te voeren. Ga ervan uit dat je teamleden de te testen applicaties goed zullen kennen. Dan zal je testcript leiden naar goed werkende software en niet naar alles omvattende documentatie.

Agile testen als het antwoord "Nee" is

In de wereld van het Agile testen, vooral binnen Scrum, lijkt testen soms synoniem geworden aan automatisch testen. Je testomgeving moet ook goed op orde zijn, je testdata goed te beheren. Handmatig testen en Agile testen lijken soms bijna vijanden. Als je handmatig test, vooral niet met een testscript. Nee, het moet met exploritory testing. Terwijl veel testers juist met deze vorm van testen flink worstelen. En over eventuele problemen rond testomgevingen, documentatie, werkoverdracht, geen geld, geen tijd, geen kennis, tja..... ik kan er in ieder geval weinig informatie over vinden.

Ik ben geen testcoördinator. Ik ben geen testconsultant. Ik heb nooit op conferenties gestaan. Ik heb geen officiële complete Agile of Scrum opleiding gehad. Ik heb weinig collega's gehad om kennis mee uit te wisselen. Wat ik vooral heb, is ervaring. Ervaring in verschillende bedrijven, waarbij ik met vallen en opstaan heb geleerd wat werkt en wat niet. En het geluk om af en toe personen tegen te komen waarmee ik mijn ervaringen kan uit te wisselen. Personen waarvan ik kan leren. Soms testers, soms testcoördinatoren, soms scrummasters, soms ontwikkelaars, soms andere mensen. Of dit genoeg is om een blog te schrijven over Agile testen, laat ik ter beoordeling aan de lezer over. Maar ik zou zeggen, geef het een kans. Niet gelezen, altijd gemist.

Om nu naar het onderwerp terug te gaan: ja, de ideale testwereld is ook de ideale testwereld voor een Agile tester. Als het maar enigszins mogelijk is, moet je als Agile tester altijd streven naar een betere testwereld. Betere testautomatisering, betere testomgevingen, betere informatie over de gebouwde software.... Iedere tester kan het lijstje zelf wel aanvullen. Maar.... het is geen voorwaarde om een goede Agile tester te zijn.

Zowel bij Agile als bij de veel gebruikte methode Scrum is nergens vastgelegd dat testautomatisering of een goede OTAP straat voorwaarden zijn. Juist Agile en Scrum gaan, naar mijn mening, uit van verandering en verbetering. Niet alleen in de te maken software, maar ook in het proces. Voor de gestelde eisen zijn ook geen bijzondere middelen nodig, wat gevraagd wordt is vooral motivatie en samenwerking. Juist daarom zijn Agile en Scrum uitstekend geschikt om te gebruiken als de testwereld bij jou in het bedrijf nog ver van het ideaal ligt.

Laat me duidelijk zijn: dit is geen makkelijke weg. Maar zeker niet onmogelijk. Het belangrijkste: probeer niet alles in een keer te bereiken, maar deel wat je wil bereiken op in kleine stapjes. En als iets (nog) niet kan, sta open voor minder ideale alternatieven. Als b.v. een automatische regressietest nog een stap te ver is, voer dan gerust een handmatige regressietest in. Die verdere stap kan je later altijd nogmaals proberen te bereiken. Beter een halve stap vooruit, dan stil blijven staan.

De belangrijkste boodschap: geef niet op als het antwoord "Nee" is. Ga op zoek naar de halve stap vooruit, als de hele niet wil lukken. Blijf geloven dat ook in een niet perfecte testwereld Agile kan werken. Nee, verkeerd geformuleerd: Agile juist zal werken!!