Testdata management wordt vaak beschreven vanuit de ideale omgeving. Je hebt een database, waarin je de testdata inricht. En vervolgens, elke keer als je de testdata opnieuw wil gebruiken, zet je een kopie van de ingerichte database terug. Daarna kan je al je testdata opnieuw gebruiken. Zelf heb ik nooit gewerkt in een omgeving, waar de testdata zo ideaal was. Zelfs als het mogelijk was een kopie van de database terug te zetten, was testdata in de verloop van tijd niet meer bruikbaar. De testdata lag teveel in het verleden.
Maar goed omgaan met testdata kan onder alle omstandigheden, niet alleen bij het ideaal. Ja, soms is het eenvoudiger, soms moeilijker, maar het is altijd mogelijk om een goed testdata proces te hebben. Mijn belangrijkste criterium: elke testcase moet zeer eenvoudig herhaald kunnen worden, waarbij het herhalen van de testcase hetzelfde testresultaat oplevert. En dit kan alleen met een goede keuze van testdata.
De belangrijkste problemen zijn als volgt samen te vatten:
- Het is niet mogelijk een database terug te zetten
- Testdata kan niet aangemaakt worden
- Testdata heeft een beperkte geldigheid door een tijdsaspect
- Testdata kan slechts 1 maal gebruikt worden, doordat het te testen proces de data verandert of blokkeert
- Testdata kan niet aangemaakt worden (2) EN heeft een beperkte geldigheid (3) of bruikbaarheid (4)
Database terugzetten niet mogelijk
In nog heel veel organisaties zijn er geen volledig professionele testomgevingen. Hierdoor is de mogelijkheid om een database terug te zetten soms niet aanwezig. In dit geval is het belangrijkste, om testdata aan te maken of te vinden, die herbruikbaar is. Het meest ideaal is, om je eigen testdata aan te maken. Maar soms kost dit heel veel tijd of heb je de kennis niet om dit te doen. In dit geval kan je ervoor kiezen om bestaande data te gebruiken. Het belangrijkste is echter: leg vast welke testdata je gebruikt voor een testcase. En leg daarnaast vast waarom je deze testdata hebt gekozen. Met dat laatste bedoel ik: aan welk criterium moet de testdata voldoen?
Waarom is het vastleggen zo belangrijk? Een van de belangrijkste nadelen als je geen testdatabase kan terugzetten, is dat iedereen de testdata kan aanpassen. Mocht dit gebeuren en je test faalt daardoor, dan moet je heel simpel kunnen nagaan of je testdata nog klopt. Maar als je niet meer weet, waarom de testdata gekozen was, wordt dit een hele klus. Stel je hebt een relatie uitgekozen, omdat deze in Duitsland is gevestigd. Iemand anders heeft echter een test, waarbij het land gewijzigd moet worden. Dus zonder dat je het weet, is je relatie opeens naar Frankrijk verhuist. Wanneer je je gegevens goed hebt vastgelegd, kan je bij het falen van je test snel nagaan: "Wacht even. De relatie is niet meer in Duitsland, maar in Frankrijk".
Testdata kan niet aangemaakt worden
Meestal gebeurt dit, doordat testdata van een externe leverancier komt. Soms is het een beperking in de te testen applicatie. Maar er zijn situaties, waar je niet alle testdata zelf kan aanmaken. In dat geval ben je verplicht om te kiezen uit bestaande testdata.
In deze situatie is het heel handig zijn om je testcases in heel kleine testcases te schrijven. Combineren kan later. Dus als je moet testen op relaties in verschillende landen, met wel of geen fax en waarvan al wel of geen contracten bekend zijn, maak de testcases klein. Maak geen testcase voor een bepaald land, met faxnummer en contracten. Nee, schrijf alle varianten los van elkaar uit. Maak een lijst met de landen, die je wil testen. Maak een aparte lijst voor wel of geen faxnummer. En nog een lijst met wel of geen contracten. Kies daarna een relatie. En streep alle varianten af, waaraan deze relatie voldoet. Noteer ook bij de relatie aan welke criteria deze voldoet. Kies daarna nog een relatie. Streep opnieuw af. En ga zo door, totdat je alle criteria hebt gedekt.
Testdata beperkte geldigheid of 1 x te gebruiken
Sommige testdata is erg gerelateerd aan een bepaalde periode. Denk hierbij bijvoorbeeld aan aanbiedingen met een uiterste geldigheidsdatum, contracten met een einddatum, dagplanningen of reisaanbod. Voor deze testdata heeft het altijd de voorkeur om zelf de data aan te maken. Als het mogelijk is, creëer je testdata zo, dat deze heel lang te gebruiken is.
Data, die slechts 1 x te gebruiken is, vraagt eigenlijk om dezelfde oplossing. Het meest duidelijke voorbeeld is hierbij factureren. Als een opdracht eenmaal gefactureerd is, is het vaak onmogelijk deze nogmaals te factureren. Ook deze testdata moet daarom bij voorkeur steeds opnieuw aangemaakt worden.
Als het nodig is de data steeds opnieuw aan te maken, is er 1 ding heel belangrijk: leg genoeg informatie vast. Hierbij gaat het om alle gegevens, die nodig zijn om snel invoeren mogelijk te maken. Als het niet uitmaakt welke relatie je kiest, hoef je dit niet vast te leggen. Maar moet de relatie uit Duitsland komen, leg dan vast welke relatie uit Duitsland je hebt gebruikt. Als het niet uitmaakt, welke datum je invoert, hoef je niets vast te leggen. Maar als de datum minimaal een week in de toekomst moet liggen, leg dit dan vast. Leg je testdata en (indien nodig) de criteria zo vast, dat je zonder veel tijd de benodigde testdata opnieuw kan aanmaken. Maar leg niet vast, wat niet uitmaakt. Dat zorgt ervoor dat overtypen alleen nodig is, als dit voor de test nodig is.
Beperkte geldigheid of 1 x te gebruiken, maar geen aanmaken mogelijk
Heel soms kom je in de situatie, waarin je zowel niet kan aanmaken, maar je testdata ook nog eens beperkt geldig is of niet aangemaakt kan worden. Dit is vooral het geval, als je testdata afkomstig is van externe bronnen, waar je geen invloed op hebt, maar je wel te maken hebt met een wisselend assortiment of een geheel te testen proces. Wat doe je dan?
Dit zal altijd een wat langer proces blijven. Wat hier het belangrijkst is: maak het jezelf zo simpel mogelijk. Probeer zoekcriteria vast te leggen, die het vinden van juiste testdata simpeler maken. Als je een zonvakantie zoekt, heb je in Spanje een grotere kans, dan in Noorwegen. Grote klanten hebben vaker een geldig contract, dan kleine klanten. Maar elk domein heeft zijn eigen zoekcriteria.
Leg deze zoekcriteria goed vast. En leg ook vast aan welke eisen je testdata moet voldoen. Probeer deze eisen zo laag mogelijk te houden, zodat het vinden niet te moeilijk is. Door deze combinatie kan je je testtijd flink beperken. Echt snel is en blijft moeilijk. Maar verbeteren kan zo wel.
