Test data Management

Verbeter de beschikbaarheid van je testdata

Testdatamanagement 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 testdata beheren?

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 testdata of het genereren van synthetische testdata. Het belang van maskeren van testdata 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 datamasking kun je deze 15% datagerelateerde problemen in je testdataset behouden om ervoor te zorgen dat deze fouten worden gevonden en opgelost voordat je naar de productie gaat.

Met de juiste manier om testdata te beheren, kun je deze datagerelateeerde testgevallen afleiden, deze maskeren en zo een betere go-to-market strategie voor je projecten creëren.

De tweede reden waarom testdata belangrijker wordt, is de time-to-market. Tegenwoordig duurt het soms tot bijna 5-7 werkdagen voordat een testdatabase 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 testdata 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 (internationaal GDPR genoemd) 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 testdata 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. Testdata genereren voor slechts één systeem met meer dan 100 tabellen is al tijdrovend. Dus het genereren van testdata 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 testdata 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 datamaskering, 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.

Tegenwoordig duurt het 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 testdata te krijgen, is het verkorten van de ververstijd cruciaal zodat je de testdata 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.

Testdata voorziening

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 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 testdatabases biedt je de mogelijkheid om meerdere omgevingen te hebben. Teams hebben geen 100% volledige kopie van een productiedatabase 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 testdatabase 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 datasubsetting kun je dit probleem in de kiem smoren. Omdat je met datasubset alleen de testdata 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

Conclusie

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.

AANMELDEN NIEUWSBRIEF

Ontvang vrijblijvend updates over nieuwe blogs, webinars en tutorials.

Laat ons weten hoe we je kunnen bereiken. We houden je op de hoogte van de laatste ontwikkelingen met betrekking tot testdata, testdatamangement, subsetten en anonimiseren. Je kunt je op ieder moment weer uitschrijven.

Data Masking

DATPROF Privacy

Data Subsetting

DATPROF Subset

Data Provisioning

DATPROF Runtime

Data Discovery

DATPROF Analyze