Testen met productiedata

Veel organisaties hebben een testomgeving die is verbonden met testdatabronnen; een database met testdata. Sommige van deze testdatabases bevatten dummy data, samengesteld door QA-engineers. Deze nepdata wordt met de hand geproduceerd of door zelfgebouwde scripts. Ja; dit lijkt behoorlijk achterhaald, maar we zien het nog steeds gebeuren. Deze methode veroorzaakt echter bepaalde problemen: veel productieproblemen zijn te wijten aan het ontbreken van realistische testdata. De dummy data bevat niet de dataproblemen die wel in de productiedata voorkomen. Dit resulteert in slechte of zelfs nutteloze testresultaten.

Productiedata voor tests

Om software te creëren van zo hoog mogelijke kwaliteit, moet de testomgeving zo synchroon mogelijk lopen met productie. Dat is de reden waarom veel QA-teams complete kopieën van productie gebruiken, zodat de meeste (liefst alle) problemen kunnen worden ondervangen. Maar er zijn een paar punten om te overwegen wat betreft deze methode:

1. Bevat de data privacygevoelige informatie? Als dit het geval is, moet je deze gegevens maskeren, filteren of simpelweg verwijderen vanwege de privacyreguleringen.
2. Kan de testomgeving zoveel data verwerken? Als dit niet het geval is, moet je dus de data ‘opbreken’ of iets dergelijks…
3. Wat gebeurt er als je een nieuwe kopie van productie nodig hebt en deze de eerdere wijzigingen overschrijft? Zal dit je test kapot maken? Je zou een soort verversingsoptie nodig hebben.
4. Zijn er afhankelijkheden tussen de data? Dan moet je alle mogelijke omstandigheden of instellingen testen.

Risico’s van het gebruik van productiedata

Bovenstaande aandachtspunten laten zien dat testen met (een kopie van) productiedata niet zo eenvoudig is als het klinkt. Vanwege privacygevoelige informatie kan het zelfs zeer riskant zijn om productiedata naar je testomgeving te kopiëren. Ook opslag- en databaselicentiekosten kunnen een serieus probleem worden. Als je meerdere kopieën maakt (één exemplaar voor elk team), wordt de omvang snel groter en loopt ook de rekening hoog op.

Maar betekent dit dat je geen productiedata kunt gebruiken voor tests? Gelukkig niet!

Het is vrij eenvoudig om productiedata in je testomgeving te gebruiken, zolang je rekening houdt met privacygevoelige data en de omvang. Voor deze twee problemen zijn zeer goede oplossingen: maskeren van privacygevoelige data met DATPROF Privacy en subsets maken met DATPROF Subset.

Maskeer productiedata

Met DATPROF Privacy maskeer je je testdata eenvoudig. Door de gegevens te anonimiseren, kun je met DATPROF software privacygevoelige informatie maskeren zodat deze niet meer herleidbaar is naar een natuurlijke persoon. Je kunt bijvoorbeeld voor- en achternaam in willekeurige volgorde plaatsen, velden leegmaken (blank), een nieuwe BSN genereren, IBAN nummers genereren, je eigen maskeerregels maken etc. Het zorgt er ook voor dat de data consistent is over meerdere applicaties en databases.

Subset productiedata

Met het gepatenteerde algoritme, haalt DATPROF Subset specifieke selecties (zelfs minder dan 1%) uit de productiedatabase. Je kunt filteren en specificeren welke data je beschikbaar wilt hebben in je subset. Je kunt extra filters toevoegen, data transformeren met kolomexpressies en extra afhankelijkheden of aangepaste foreign key. Op deze manier bevat de subset alle problemen die aanwezig zijn in productie, maar is opslag geen probleem meer. Met subsets kun je elk team een eigen testdataset geven.

Productie data vs test data

Nepdata helpt je niet om software van hoge kwaliteit te maken. Het bevat niet de problemen die wel in productie voorkomen en die je wilt ontdekken en testen. Dus, moet je productiedata gebruiken voor het testen? Absoluut, maar dan op voorwaarde dat je je testdata maskeert en subset voordat je het voor testdoeleinden gebruikt. Anders kom je in de problemen vanwege privacyregelgeving en/of opslagproblemen.

Wil je weten hoe DATPROF jouw test data management kan verbeteren? Neem vrijblijvend contact op. We helpen je graag verder!