Test data Management

Verbeter de beschikbaarheid van je test data

Test data management is de nieuwe grote uitdaging waarmee we worden geconfronteerd in de ontwikkeling en kwaliteit van software. Het is belangrijk dat testgegevens goed beschikbaar en gemakkelijk te vernieuwen zijn om de time-to-market van je software te verbeteren. Een andere reden waarom TDM een uitdaging is, zijn de nieuwe wetgevingen zoals de AVG. Dus hoe wil jij je test data beheren?

Wat is test data management?

Over de noodzaak van testen hoeven we het tegenwoordig gelukkig niet meer te hebben. Nagenoeg iedere organisatie is er wel van overtuigd dat je nieuwe producten eerst uit moet proberen om erachter te komen dat het product doet wat we er van verwachten en dat daar geen rare fouten in worden gemaakt die de zorgvuldig opgebouwde naam van het bedrijf ten gronde richt. Testcoureurs rijden om die reden eindeloos rondjes in nieuwe concept auto’s en op dezelfde manier proberen software testers de (laatste versie) van applicaties uit.

Infrastructuur

Een applicatie is, net als een auto, een object dat je een beetje moet helpen wil deze functioneren. Allereerst heb je een infrastructuur nodig. In het geval van een auto is dat een stuk weg. Maar omdat je nog in de testfase zit, wil je een weg hebben waarop je een goede vergelijking kan maken met betrekking tot stabiliteit in bochten, acceleratie, remweg, snelheid en dergelijke. Oftewel, je hebt een testcircuit nodig waarop je eindeloos rondjes kunt rijden. Het testcircuit van de software tester is de testomgeving. Een omgeving waarin je kunt uitproberen of een applicatie reageert zoals verwacht gegeven een bepaalde input. Deze omgeving dient toereikend te zijn voor het doel waarmee getest wordt. Een drag strip dient immers prima om de acceleratie van een auto mee te testen, maar daar zal je niet kunnen testen op de stabiliteit in bochten. Zo zal je voor een unit test ook een ander soort omgeving nodig hebben dan een gebruikersacceptatietest.

De juiste test data

Maar een applicatie heeft ook net als een auto brandstof nodig om te kunnen werken. Een applicatie is namelijk gebouwd voor gegevensverwerking, zonder gegevens geen verwerking en daarmee is er een behoefte aan test data: de brandstof voor een applicatie in een testomgeving.

Er is echter verrassend weinig aandacht voor test data. Die zoekt de tester namelijk wel bij elkaar naar gelang de testgevallen die uitgevoerd moeten worden. De applicatie staat op een testomgeving en in die omgeving is data aanwezig, dus de testen kunnen uitgevoerd worden. Maar zo simpel is het natuurlijk niet.

Om nog een laatste keer de vergelijking met een auto te maken, als je diesel in een benzineauto stopt, komt deze waarschijnlijk niet zo ver als dat je had verwacht. Als je bovendien niet weet dat je dit fout hebt gedaan, ga je waarschijnlijk eerst de hele motor uit elkaar halen om te achterhalen waarom die het niet meer doet om er pas na alles uitgesloten te hebben erachter te komen dat dit aan de brandstof lag. Zo is het ook met testdata. Om het resultaat van de applicatie op juistheid te kunnen toetsen is het noodzakelijk er zeker van te zijn dat de input om dit resultaat te kunnen verkrijgen klopt.

3 variabelen

Je kunt stellen dat testen een gecompliceerd geheel is aan de hand van drie variabelen

  1. test object
  2. omgeving
  3. data 

Wil je het test proces soepel laten verlopen, dus dat je alleen mankementen ten aanzien van het test object vindt, dan moet je beide andere variabelen onder controle hebben en beheersen. Het niet onder controle hebben van test data geeft complicerende factoren tijdens het testen.

Om onder controle te hebben welke test data je in een omgeving hebt wil je test data management inrichten. Test data betreft namelijk niet één object, omgeving of testsoort, maar heeft impact op het geheel aan applicaties en processen in je gehele landschap. Het is daarmee bittere noodzaak dat hier goed over wordt nagedacht en deze met beleid wordt gestuurd.

Waarom test data management?

Er zijn meerdere redenen waarom we met test data management willen beginnen. De twee meest gehoorde redenen zijn:

  • Iets doen met het anonimiseren van data of het genereren van testdata vanwege AVG of andere privacywetten
  • Sneller de markt op kunnen gaan, maar de grote omgevingen houden ons tegen

Om te beginnen met de eerste reden, de AVG. Vanwege privacywetten beginnen veel organisaties na te denken over het maskeren van test data of het genereren van synthetische test data. Het belang van maskeren van test data kan worden gevonden in het feit dat 15% van alle gevonden bugs gerelateerd is aan de data. Deze datagerelateerde problemen doen zich voor bij bijvoorbeeld problemen met datakwaliteit. 

Met data anonimisering kun je deze 15% datagerelateerde problemen in je test data set behouden om ervoor te zorgen dat deze fouten worden gevonden en opgelost voordat je naar de productie gaat. Met de juiste manier om test data te beheren, kun je deze datagerelateerde testgevallen afleiden, deze maskeren en zo een betere go-to-market strategie voor je projecten creëren.

De tweede reden waarom test data belangrijker wordt, is de time-to-market. Tegenwoordig duurt het soms tot bijna 5-7 werkdagen voordat een test database wordt ververst! In de snelle ontwikkeling van software-afleveringen van vandaag zou dat onaanvaardbaar moeten zijn. En om het nog erger te maken, zijn er meer dan 3 personen nodig voor deze verversing. Er is dus veel tijd verspild tijdens je snelle pijplijn voor het leveren van software. Het verkoren van de tijd voor de verversing, zodat je test data op één lijn krijgt met je project, is cruciaal voor succes.

Privacy wetten en test data

Traditioneel maken we kopieën van productie en gebruiken deze voor de ontwikkeling van software. Dus maken we kopieën in niet-productie omgevingen zoals ontwikkeling, test en acceptatie. Vanwege de privacywetgeving zoals de AVG/GDPR, PCI en HIPAA kun je deze kopieën van productie niet meer gebruiken. We zien dan ook dat veel organisaties oplossingen zoeken:

  1. Synthetische testdata genereren
  2. Testdata maskeren, anonimiseren, pseudonimiseren

Wij geloven in het beste van twee werelden. Echte tes tdata engineers zullen je vertellen dat, met de huidige stand van de techniek, synthetische testdata niet alle problemen kan oplossen. Waarom? Omdat het grootste probleem van synthetische testdata in veel gevallen de complexiteit van de systemen is, het aantal applicaties dat compliant moet zijn. Test data genereren voor slechts één systeem met meer dan 100 tabellen is al tijdrovend. Dus het genereren van test data over meerdere systemen is… verschrikkelijk. Maar als je aan het ontwikkelen bent, is niet elke vorm van data beschikbaar in de productie. Je zult dus waarschijnlijk altijd een beetje synthetisch gegenereerde test data nodig hebben.

Het maskeren van testdata, zoals wij het graag noemen – maar je kunt het ook scrambling of depersonaliseren noemen – lost twee bovengenoemde uitdagingen op (technisch gezien is pseudonimisering iets anders dan maskeren). Met data maskering, maskeer je gegevens die al bestaan. Zo worden ook data kwaliteitsproblemen behouden, de vreemde testgevallen blijven bestaan. Vervolgens kun je andere systemen op dezelfde manier maskeren.

Snellere go-to-market met je software

De tweede reden waarom testdata belangrijke wordt, is vanwege de go-to-market tijd. De markt voor softwareontwikkeling verandert snel. Met elke organisatie waarmee we tegenwoordig praten, bespreken we de mogelijkheid om sneller naar de markt te gaan. Om deze doelen te bereiken, praten organisaties over DevOps, Agile en allerlei soorten softwareontwikkeling. In veel gevallen houdt de technische infrastructuur ze echter tegen. De zachte kant van agile is vrij eenvoudig. Het moeilijkste is de infrastructuur. We leven nog steeds allemaal in een watervaltijdperk omdat je testdatabases het aantal agile teams niet aankunnen.

Zoals eerder vermeld, duurt het tegenwoordig soms tot bijna 5-7 werkdagen voordat een database wordt ververst. In de tijd van snelle softwareontwikkeling zou dit onaanvaardbaar moeten zijn. En om het nog erger te maken: er zijn vaak meer dan 3 personen nodig voor deze verversing. Er is dus al snel heel veel tijd verspild. Om de controle over je test data te krijgen, is het verkorten van de ververstijd cruciaal zodat je de test data op één lijn krijgt met je project.

Veelal worden volledige kopieën van productie en implementatie gebruikt in deze DTAP omgeving. Werkbaar, maar de omvang is een probleem. Waarschijnlijk zal de omvang van je databases niet afnemen, eerder toenemen. We zien ook dat er voor één productieapplicatie meerdere kopieën in testomgevingen zijn. Een andere grote uitdaging is het feit dat teams elkaar frustreren. Gefrustreerd omdat je in veel gevallen niet hetzelfde aantal databases hebt als teams. Je hebt waarschijnlijk meer teams dan databases. Je zou dus testcases kunnen vernielen voordat een team een test kan uitvoeren. Dit moet je onder controle krijgen, vooral als je wilt starten met continuous deployment.

Lees ook: Waarom slecht test data management je veel kost – niet alleen geld

Test data automatisering

Het is belangrijk dat het eenvoudig wordt om testdata in verschillende omgevingen in te zetten. In de huidige staat van je test data management ga je waarschijnlijk naar een databasebeheerder en vraag je of een verversing van de database kan worden geregeld. De databasebeheerder heeft het druk en heeft niet echt de tijd (of wil het niet vrijmaken) om je testomgeving te verversen. De eerste minuten zijn dan al verspild.

Als softwareontwikkelteam wil je dus je eigen verversingen beheren, in je testcases rechtstreeks of via een test data management team. Een selfserviceportal en Test Data Automation voor het verversen van testomgevingen is dan de oplossing.

Het juiste moment

Wat lastig is, is dat er vaak niet genoeg databases beschikbaar zijn voor het aantal teams. Dus wat er gebeurt, is dat meerdere teams of mensen in dezelfde database werken.

Software quality engineers zijn allemaal op zoek naar dezelfde testcases en voeren tests uit op het systeem. En tijdens de uitvoering van de tests doen zich de problemen voor: een collega heeft al dezelfde testcase gebruikt en de testgegevens zijn al gemanipuleerd. De testcase werd nutteloos en het zoeken begint helemaal opnieuw. Wederom wordt tijd verspild aan het vinden van juiste testgevallen en testdata.

Dus in dit geval wil je dat testdata eenvoudig worden ververst, zodat je de door jou geselecteerde testcase kunt gebruiken en je over een eigen testdatabase beschikt. Dit laatste deel kan worden bereikt wanneer je begint met het subsetten van testdata. Het creëren van kleinere test databases biedt je de mogelijkheid om meerdere omgevingen te hebben. Teams hebben geen 100% volledige kopie van een productie database nodig, ze hebben alleen de belangrijke testcases nodig. Ze hebben in ieder geval de 15% aan data gerelateerde issues nodig. In dat geval kun je een hele kleine test database maken. Deze zijn gemakkelijk inzetbaar, hebben een hoge beschikbaarheid en zijn gemakkelijk te verversen.

De oplossing

Er is een perfecte oplossing voor dit probleem. In eerste instantie zal het je niet aanstaan, maar blijf even lezen. Een eenvoudige oplossing voor het probleem is: ieder team een eigen database geven. Probleem opgelost, niemand verprutst de testdata en er wordt geen tijd verspild. Maar met deze oplossing introduceren we een nieuw probleem, omdat we nu waarschijnlijk te maken hebben met een opslagprobleem.

Met data subsetting kun je dit probleem in de kiem smoren. Omdat je met data subset alleen de test data hoeft te extraheren die je nodig hebt, krijg je uiteindelijk een kleiner exemplaar van productie. Soms is dit slechts 1% van een kopie op volledige grootte. Dit resulteert in een aantal belangrijke voordelen in het beheer van testdata:

  • Drastisch verminderen van DTAP-omgevingen
  • Teams in staat om software zo snel mogelijk op de markt te brengen omdat je flexibele sets testdata hebt
  • Het terugzetten van een kleine database kan in een kort tijdsbestek worden gedaan
  • Teams frustreren elkaar niet (geen tijdverspilling van je hoogopgeleide mensen)
  • Minder risico’s van datagerelateerde softwarefouten

Test Data Management Software

Het onder controle krijgen van testdata wordt steeds belangrijker. Met behulp van subsetting technologie kun je kleinere sets testdata in een omgeving implementeren. Deze zijn flexibel en de omvang is geen probleem meer. Je kunt teams niet alleen één maar meerdere testdatabases leveren, zodat elk team een eigen testdatabase heeft.

De DATPROF software suite bestaat uit verschillende producten die klanten helpen een test data management oplossing te realiseren. Het hart van de suite wordt gevormd door DATPROF Runtime. Dit is het test data voorzieningsplatform waar de uitvoering van de DATPROF templates plaatsvindt. De meeste test data management implementaties worden ondersteund door de volgende tools:

De gepatenteerde DATPROF-suite is ontworpen om de inspanning (uren) tijdens elke fase van de levenscyclus te minimaliseren. Dit vertaalt zich direct in de hoge implementatiesnelheid en het gebruiksgemak tijdens onderhoud.

Lees ook: Test data management tool kopen of zelf bouwen?

Get in touch with our experts

Contactform

  • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.

Data Masking

DATPROF Privacy

Data Automation

DATPROF Runtime

Data Discovery

DATPROF Analyze