Testdata

Voor het uitvoeren van testen heb je test data nodig. Dit kan input data zijn of data die als startsituatie in de database aanwezig moet zijn.

Bij het gebruiken van test data is er een aantal punten waar je rekening mee moet houden.

• Heeft iedere tester zijn eigen testomgeving
• Kan en mag er gebruik gemaakt worden van productie gegevens
• Op welke wijze kan de test data, die als startsituatie aanwezig moet zijn, opgevoerd worden in het systeem
• Kunnen testers zelf makkelijk een backup en restore maken van de test data
• Heeft het te testen systeem interfaces met andere systemen waar ook test data in aanwezig moet zijn.
• Het onderhouden van de test data

Een testomgeving per tester

De ideale situatie is die waar de tester zijn eigen omgeving heeft, er geen interfaces met andere systemen zijn en je als tester zelf een backup en restore kunt maken van de testdata.

Deze situatie kan zich voordoen bij een nieuw te ontwikkelen applicatie, waarbij je als tester nauw kunt samenwerken met developers. Gezamenlijk is het dan zeker mogelijk de ideale situatie te creëren.

Zit je echter als tester in een beheer situatie, met meerdere testers op een testomgeving of heb je te maken met ketens, dan wordt het een stuk lastiger.

Wanneer niet iedere tester zijn eigen testomgeving heeft zullen er afspraken gemaakt moeten worden over het gebruik en de opbouw van de test data. Dit kan door afspraken te maken over wie gebruik maakt van welke personeelsnummers, BSN’nr, bankrekeningnummers, polisnummers, postcodes, etc. Kies hierbij voor een gegeven of combinatie van gegevens die er voor zorgen dat de test data uniek is te identificeren. Daarnaast moeten er afspraken gemaakt worden over hoe de test data in de database wordt gezet. In deze situatie kun je als tester niet zomaar een database restoren. Voordat je het weet heb je dan gefrustreerde collega testers omdat ook hun test data is teruggezet naar de startsituatie, terwijl ze bezig zijn met testen. Er zullen hierover procedurele afspraken gemaakt moeten worden of er moet, samen met developers en DBA, onderzocht worden of het mogelijk is om maar een deel van de test data terug te kunnen zetten.

Heb je te maken met ketens dan zullen de hiervoor genoemde punten ook gemaakt moeten worden met de testers van de andere systemen. Het afstemmen en vervolgens implementeren binnen ketens kost in de regel veel tijd. Complicerende factoren hierbij kunnen zijn:

• Het vinden van de juiste contactpersonen en het krijgen van toestemming om afspraken te maken
• De beschikbaarheid in tijd en moment van de personen waarmee de afspraken gemaakt moeten worden
• Het krijgen van prioriteit en tijd om de afspraken te implementeren

Het gebruiken van productiedata

Sinds 2016 is de regelgeving voor dataprotectie aangescherpt in de General Data Protection Regulation (GDPR). Deze regelgeving heeft ook impact op het gebruik van productiedata voor het testen. Binnen iedere organisatie is iemand verantwoordelijk voor de implementatie van de GDPR. Ga dan ook in je organisatie op zoek naar het beleid dat is geformuleerd.

Hoe de initiale uitgangssituatie klaarzetten

Wanneer je testen uitvoert zullen er situaties zijn waarbij er al gegevens aanwezig moeten zijn in het systeem om het testgeval uit te kunnen voeren. Denk bijvoorbeeld aan het testen van functionaliteit voor het wijzigen of verwijderen van gegevens.

Er zijn meerdere mogelijkheden om die initiële uitgangssituatie te maken:

Met behulp van SQL

Met SQL kun je data rechtstreeks in een database opvoeren. Deze manier heeft de voorkeur omdat:

• SQL scripts bij iedere testuitvoering opnieuw gebruikt kunnen worden.
• Er geen afhankelijkheid is met de juiste werking van de functionaliteit om gegevens op te voeren in het systeem.
• Met SQL scripts de data sneller in de database kan worden toegevoegd, dan wanneer je dit handmatig moet doen.

Er is wel kennis van SQL en de database structuur nodig om de SQL scripts te kunnen maken. Hier kunnen ontwikkelaars echter goede ondersteuning bieden door bijvoorbeeld templates te maken. Als tester hoef je dan alleen de data op de juiste plek in de SQL toe te voegen. Uiteraard moet je er wel steeds voor zorgen dat je een lege database hebt voordat de SQL scripts worden uitgevoerd.

Met reguliere functionaliteit van het systeem

Het is niet altijd mogelijk om de initiële data met behulp van SQL in de database te plaatsen. Denk hierbij bijvoorbeeld aan een acceptatietestomgeving waarin het niet is toegestaan om de database buiten de applicatie om te benaderen. In die situatie zal de uitgangssituatie gecreëerd moeten worden met de functionaliteit van het systeem zelf. Hierbij loop je het risico dat die functionaliteiten nog niet af zijn of fouten bevatten. Het kan dan gebeuren dat de test zelf niet kan worden uitgevoerd omdat de uitgangssituatie er niet is of fouten bevat. Houd rekening met dit potentiële risico. Bespreek het met de verschillende stakeholders en probeer samen workarounds te bedenken. Dit kan bijvoorbeeld zijn dat de andere functionaliteiten een hogere prioriteit krijgen bij ontwikkelen en testen of dat het testen naar een later moment wordt uitgesteld.

Conclusie

Het maken, gebruiken en onderhouden van testdata is een steeds belangrijker en complexer onderdeel geworden van het testproces. Testdata management (TDM) is zich dan ook steeds verder aan het ontwikkelen. Hierbij moet je denken aan standaard processen voor TDM en tooling die TDM ondersteunen. Zeker met de nieuwe GDPR zal deze discipline nog belangrijker worden.