The test data bottleneck

Alle inspanningen in Agile, Scrum, DevOps, Artificial Intelligence zijn allemaal gericht op concurrentievoordelen. We starten virtualisatie of testautomatisering. We gebruiken low-cost softwareontwikkelingssystemen om snel aan nieuwe situaties aan te passen. Organisatorische veranderingen worden geïmplementeerd, zoals agile softwareontwikkeling. En de agile ideologie veranderde organisaties. Tegenwoordig werkt iedereen in teams of in tribes. Deze teams zijn soms zelfs zelfregulerend. Maar er is een groot probleem waar we vaak niet aan denken: de bottleneck van testdata.

Teams zijn multidisciplinair: softwareontwikkelaars, operations, software quality engineers, engineers voor testautomatisering. En je hebt waarschijnlijk meerdere van deze teams. 10-30 teams? Soms minder, soms meer. Eén ding is zeker, er zijn veel teams. En al deze teams ontwikkelen en testen en produceren softwarecode. Meestal is er slechts één testdatabase op 5-10 teams. En dan heb je geluk.

Je verliest kostbare tijd, omdat:

1. Je allemaal in dezelfde omgeving in dezelfde database werkt
2. Het zoeken naar test cases in 100% is moeilijk
3. Je testdata wordt niet beheerd

Survival of the fittest

Meerdere teams werken met een beperkt aantal databases. En dat is logisch, want helaas zijn veel kernsystemen gebouwd op DB2 Databases of Oracle Databases of als je een beetje geluk hebt op MS SQL Server Databases. Misschien gebruik je Postgress of MySQL. Maar deze zijn opkomend. Deze database-softwaresystemen zijn niet gratis. Dus het aanmaken van nieuwe grote databases is duur! Groot is hier belangrijk, omdat ze je in veel gevallen niet echt het aantal databases in rekening brengen – ze brengen je kosten in rekening op basis van de omvang. Het aantal CPU-kernen is een manier om een factuur te verzenden, de omvang van terabytes is een andere manier. Grootte doet er dus echt toe.

Vanwege de grootte zijn er een beperkt aantal databases. Dus je werkt met meerdere teams in één database. In veel organisaties betekent dit ‘survival of the fittest’. Moge het beste team winnen. Als jouw team als eerste de juiste testgegevens vindt, kan jouw team als eerste beginnen met het ontwikkelen en testen op basis van de juiste testgegevens. Wat we ook zien is dat databases worden ‘ingepland’. Team 1 kan testen tijdens periode x. Team 2 daarna en team 3 na team 2. Dat is niet agile, dat is bijna prehistorisch en zorgt voor een serieus knelpunt.

Zoeken naar test cases

Zoeken naar testcases in een 100% kopie van de productie is verschrikkelijk. Als team wil je de juiste testcase-dekking. Als je over de juiste dekking van de testcase beschikt, begrijp je de impact voordat je naar de productie gaat. Maar het hebben van de juiste testcase-dekking is een uitdaging. Als je een systeem hebt dat al meerdere jaren oud is, dan kan dit moeilijk worden omdat je veel historische of gemigreerde data hebt. Het vinden van de juiste testcases voor vandaag of morgen is waarschijnlijk eenvoudig, maar hoe zit het met het verleden. Een klant van een paar jaar geleden zou dezelfde service moeten hebben als je nieuwe. We moeten er dus voor zorgen dat deze testcases ook worden behandeld. En dit wordt al moeilijk, vooral als je testcases probeert te vinden in tientallen terabytes.

We komen databases tegen met 30 terabytes aan gegevens, soms zelfs 100 terabyte. Tegenwoordig is er een enorme wens om data op te slaan. Dus het vinden van juiste testgevallen in deze hoeveelheid terabytes… Nou, dat is een uitdaging om het op zijn minst te zeggen. Geen wonder dat uit onderzoek blijkt dat bijna 50% van de testtijd verloren gaat door het zoeken naar en vinden van de juiste testgegevens. En wanneer (of als) je het vindt, kan het zijn dat een collega de testcase heeft gemanipuleerd omdat jullie met dezelfde database werken.

Manage je test data

Het klinkt vanzelfsprekend, maar als er geen test data management is, kun je je testdata niet controleren. Als een test slechte resultaten oplevert, weet je niet of dit aan de code of aan de data ligt. Onze ervaring leert dat organisaties die met test data management werken, eindelijk de controle krijgen over hun testdata. Meer controle betekent meer zekerheid. Daarna weet je zeker dat als je een softwarefout vindt, dit een fout in de code is. En met dat inzicht kun je betere feedback geven, wat betere code betekent, wat een snellere implementatie betekent (of lopen we nu wat te hard van stapel).

De bottleneck oplossen met synthetische testdata?

Een mogelijke oplossing is om synthetische testdata te genereren. Het genereren van synthetische testdata helpt je bij het oplossen van de knelpunten in de testgegevens. De resultaten worden groen en je testtools laten de resultaten zien om naar staging of zelfs naar de productie te gaan! Maar daarna begint het probleem, omdat je softwarefouten tegenkomt die eerder hadden moeten worden gevonden. Omdat je productiegegevens complexer zijn dan je testdata generator dacht…

Synthetische testgegevens zijn mooi en helpen je misschien bij een eerste paar tests, zoals bijvoorbeeld unit tests. Maar voor wat duurzamere tests en wat meer definitieve antwoorden, zijn synthetische testgegevens problematisch. Het genereren van testdata voor een eenvoudige testcase, die aan de voorkant van een systeem kan worden gegeven, is goed! Maar aan de achterkant zijn er nog veel meer testgevallen. Een test met het toevoegen van een nieuwe klant is prima, maar het bewerken van klanten is al moeilijker, laat staan het wijzigen van een product bijvoorbeeld. Je zou voor alle tabellen synthetische testgegevens moeten genereren. Maar hoeveel tabellen heeft je systeem? 100 als je geluk hebt. Systemen met 2000 tot 10.000 tabellen zijn niet ongewoon. En als ze meerdere kolommen hebben, heb je misschien een beetje een uitdaging. En dan hebben we slechts één systeem besproken, hoe zit het met alle andere systemen die je waarschijnlijk zult hebben…

Als je de bottleneck van testdata wilt oplossen, moet je een combinatie van meerdere technieken gebruiken. Je zult moeten gebruiken:

• Subset technologie voor het creëren van kleinere omgevingen;
• Maskeer technologie om compliant te worden;
• Synthetische testdata om niet-bestaande testgevallen te creëren.

Je test data subsetten

Subsetten heeft vele voordelen en slechts een klein aantal nadelen. De voordelen van subsets voor het softwarekwaliteitsproces zijn:

• Mogelijkheid om nieuwe database-omgevingen te creëren met lage kosten;
• Creëren van nieuwe omgevingen met subsets van testgegevens in minuten;
• Invloed hebben op jouw testgegevens in jouw testomgeving;
• Het hebben van representatieve testdata in je omgeving;
• Vermindering van datalek problemen;
• Verhoog de snelheid van testautomatisering;
• Minder downtime door te wachten op de testdatabase.

We zien het vaak gebeuren. Softwareontwikkelingsteams zijn afhankelijk van procedures en databasebeheerders voordat een nieuwe testdatabase wordt geïmplementeerd voor testen en ontwikkelen. Als zo’n verversing zelfs mogelijk is. In veel gevallen duurt de verversing van een database tot wel 3,5 personen en bijna een werkweek voordat deze wordt ingezet. Er gaat dus veel tijd verloren. De tijdverspilling voordat een database wordt vernieuwd, is gedeeltelijk te wijten aan de omvang. Omdat het vanwege de omvang tijd kost. Maar het kost ook tijd, want je moet toestemming hebben om een database te kopiëren voor testdoeleinden. DBA moet enige tijd vrijmaken om een kopie te maken. Maar het is niet hun core business, dus ze geven er geen prioriteit aan. Dus er begint een wachtspel.

Representatieve testdata

We hebben teams zien werken met een 10 jaar oude testdatabase. 10 jaar. Dat is geen grap. Je zou kunnen denken, is dat een probleem? Nou misschien ook niet. Maar we zijn bezig met het maken van software van de hoogst mogelijke kwaliteit. We willen ervoor zorgen dat software het juiste niveau heeft om in de productie te presteren. Is een 10 jaar oude testdatabase representatief vergeleken met productie? Of een 5 jaar oude? Of een 1 jaar oude? Het zou nuttig zijn om bij elke release tot productie een nieuwe testdatabase te maken. Zo wenselijk elke dag als je elke dag naar productie gaat. Het zou kortgezegd je releasekalender moeten volgen. Maar zelfs als we dat doen, kost het verversen van een grote database veel tijd…

Het verversen van 10 TB kost tijd, alleen het proces zelf kan tot 12 uur duren. Dus uiteindelijk – zelfs als we alle procedurele verwerking elimineren – houden we nog steeds een proces van minstens 12 uur over. Hoe kunnen we deze cijfers nog verbeteren? Subsetten is een zeer interessante volgende stap. Het kan databases reduceren tot slechts 1 promile percentage. Dus een 10 terabyte productiedatabase wordt 10 gigabyte. Wat dacht je daarvan? Hoe snel kun je een database van 10 gigabyte verversen? Dit heeft een enorme impact. Met de mogelijkheid om opslag met subsetten te verminderen, kun je nu binnen enkele minuten databases verversen en back-uppen.

Het laatste deel van de bottleneck

Om helemaal eerlijk te zijn, is er nog één probleem. Want is een subset vanaf het begin 100% perfect? Het antwoord is nee. Dat betekent dat zelfs met onze oplossing de subset niet 100% perfect of representatief voor productie zal zijn. Maar we kunnen je controle geven. Als analyse leidt tot een dataprobleem, kun je je nu gemakkelijk aanpassen. Je kunt eenvoudig nieuwe testdatacases toevoegen aan je eerste subset. Dus bij elke nieuwe subset-run zijn de testgegevens die ontbraken in de eerste run nu beschikbaar in je subset. Bij elke run krijg je meer en meer vertrouwen dat je met elke test naar de productie kunt gaan.

Maskeer je testdata

In je zoektocht naar de beste testdata in een DevOps-wereld, eindigen we bij het maskeren van data. Omdat het gebruik van een subset het gebruik van productiegegevens betekent. Het gebruik van productiegegevens is immers de meest representatieve manier om ervoor te zorgen dat de ontwikkelde software van de juiste kwaliteit is. Maar we kunnen productiegegevens niet meer gebruiken. Vanwege AVG en andere voorschriften is het ons niet toegestaan productiegegevens met privacygevoelige informatie te gebruiken. Dus je maskeert of anonimiseert het. En in welke volgorde je deze stappen uitvoert, is ook belangrijk. In veel gevallen adviseren we om te beginnen met maskeren en vervolgens te subsetten op basis van de gemaskeerde database. Het grote voordeel hiervan is dat al je gesubsette databases al gemaskeerde gegevens bevatten.

Het maskeren van testdata kan een uitdaging zijn. De echte uitdaging is om testgegevens zo representatief mogelijk te houden en ervoor te zorgen dat je het echte individu niet kunt herleiden. Dus het toevoegen van de juiste maskeerregels aan gegevens is cruciaal.

It’s a DevOps world

De laatste stap bij het oplossen van de test data bottleneck is het gebruik van synthetische testdata. Het lost de laatste belangrijke stap naar een DevOps-wereld op. Omdat je softwareontwikkelingsteam met synthetische testgegevens in staat is om hun testcases perfect af te stemmen op hun testdata. Nieuwe producten kunnen worden aangemaakt, nieuwe vreemde achternamen kunnen worden ingezet, nieuwe IBAN-bankrekeningnummers kunnen worden gegenereerd. En op basis van synthetische testdata zijn ze nu in staat om de tests perfect af te stemmen op de testgegevens.

Nu ben je er bijna. 1) Je kunt testgegevens binnen enkele minuten met subsets implementeren, 2) je kunt testgegevens maskeren om compliant te worden en 3) je kunt synthetisch testgegevens genereren om testcases perfect af te stemmen op je tests en je testdata. De laatste stap is ervoor zorgen dat je het implementatiemoment in de hand hebt. Je bent niet afhankelijk van 3,5 personen maar je bent in staat om al deze stappen te automatiseren. Je team heeft eindelijk de controle.