Data subsetting een belangrijk maar minder bekend onderdeel van Testdata management

Deze aflevering van mijn serie blogs over Testdata management (TDM) gaat over een onderbelicht subproces binnen TDM het subsetten van data Testdata management is een relatief nieuw vakgebied Dat betekent dat er weinig mensen zijn die weten wat het precies inhoudt Als mensen wel eens wat hebben gelezen over testdata management dan zal het maskeren ervan veel vaker het onderwerp zijn geweest Immers privacy is een hot issue Over het maskeren van data voor testdoeleinden is dus al veel gepubliceerd Dat het gebruik van ongemaskeerde data in het testproces nog wel veel voorkomt is een ander verhaal zie mijn eerdere artikelen Maar nu dus over subsetten Wat is het wat zijn de voordelen en is het moeilijk

Wat is subsetten Zonder dat ik een wetenschappelijke definitie wil geven omschrijf ik het subsetten van data als volgt het proces waarbij kleine selecties van de productiedatabase gekopieerd worden en vervolgens in de niet-productie omgevingen (O T of A) worden geladen Bijvoorbeeld de productiedatabase vol met klanten en transacties is 18 TB groot Daarvan maken we een kloon die 18 GB groot is Die laden we vervolgens in de testomgeving maar hoe doe je dat Dit kan met speciale tools of scripts die hiervoor zijn ontwikkeld door slimme DBArsquoers ldquoMaar wat doen die tools of scripts danrdquo hoor ik je denken Ze verkleinen op een intelligente manier het aantal records in de tabellen van de database bij voorkeur op basis van criteria die de testers opgeven Bijvoorbeeld kies alleen klanten declaraties en vergoedingen uit een verzekeringenadministratie behorend bij polissen met een nummer dat eindigt op 3 In theorie wordt de database dan tien keer kleiner In theorie want zo makkelijk is het niet Laten we eens kijken wat er zo moeilijk is

Is subsetten moeilijk Subsetten lijkt makkelijk Je maakt de juiste selectie en klaar is Kees Was het maar zo Het probleem zit hem in de wijze waarop gegevens in databases worden opgeslagen Die opslag brengt op zijn minst drie grote uitdagingen met zich mee

1 Referentieumlle integriteit Een subset van de productiedatabase is alleen bruikbaar voor het testtraject als de tabellen in die testdatabase referentieel integer zijn Wikipedia legt uit wat referentieumlle integriteit is Referentieumlle integriteit in een relationele database is het uitgangspunt dat de interne consistentie tussen de verschillende tabellen binnen die database wordt gewaarborgd Dat betekent dat er altijd een primaire sleutel in een tabel bestaat als er in een sleutelveld in een andere tabel naar wordt verwezen Het DBMS waarborgt de consistentie en zorgt er voor dat een transactie die de consistentie doorbreekt niet wordt aangebracht Dus als we uit een klantentabel van een productiedatabase 50000 klanten selecteren moeten we zorgen dat we alleen klantenorders uit de ordertabel selecteren die betrekking hebben op die 50000 klanten Doen we dat niet dan krijgen we onbedoelde fouten bij het testen Een postcodetabel aan de andere kant moeten we volledig overnemen omdat we niet weten waar de 50000 klanten wonen

2 Relaties tussen verschillende databases In het vorige punt beschreef ik het belang en de uitdaging van referentieumlle integriteit binnen eacuteeacuten database Maar het kan nog gecompliceerder Stel we hebben een klantendatabase in Oracle en een orderdatabase in MS SQL Server Dat weerhoudt ons niet van de verplichting de data tussen de databases referentieel integer te houden bijvoorbeeld voor het maken van een subset voor testdoeleinden Je zult begrijpen dat dit het proces nog complexer maakt Met name omdat er nu niet eacuteeacuten DataBase Management System (DBMS) is dat de integriteit bewaakt maar meerdere

3 Data in een keten

Zijn we er dan Nee de praktijk is nog weerbarstiger Vrijwel elke organisatie maakt deel uit van een keten Bovendien is elke ketenpartner een bron van gegevens die relaties hebben met de gegevens in de eigen database Een bekende externe bron is bijvoorbeeld de Gemeentelijke Basisadministratie (GBA) Als we willen ketentesten met een subset van onze eigen gegevens zullen we onze ketenpartners moeten vragen een referentieel integere subset van hun gegevens aan te leveren Met alle afstemmingsuitdagingen van dien

Waarom subsetten wat zijn de voordelen Als subsetten dan zo moeilijk is door zoveel kans op onbedoelde fouten tijdens het testen waarom zouden we het dan doen Het antwoord op die vraag is simpel organisaties kunnen er een aantal belangrijke business doelstellingen mee behalen

Het testproces verkorten door met kleinere testdatasets te werken Het testen van batchruns gaat sneller en het klaarzetten van testdata is niet langer de bottleneck in een testproces

En als het testproces de bottleneck is in de time-to-market dan verkort het dus ook de time-to-market Nieuwe systemen kunnen eerder in productie worden gebracht

Wil een organisatie werken volgende de principes van continuous development -delivery of integration dan is het inrichten van subsetten essentieel Zonder een dagelijkse verse subset van testdata kan niet goed en snel worden getest

Kosten verlagen met kleinere datasets die minder opslag en minder systeembronnen vereisen en lagere DBMS-licentiekosten vragen

Ontwikkelingscycli verkorten door vooraf gedefinieerde subsettingscripts die snel en op afgesproken tijden beveiligde datasubsets maken waarbij de referentieumlle integriteit behouden blijft

Samenvattend kunnen we zeggen dat een onderzoek naar de mogelijkheden van data subsetting voor iedere organisatie interessant en waardevol is Subsetten kan moeilijk zijn maar het levert (veel) geld op en testen gaat sneller en beter Dan heb ik eacuteeacuten belangrijk voordeel nog niet genoemd de doorlooptijd van het anonimiseren van testdata is vele maken korter Daarover in mijn volgende blog(s) meer Wil je meer weten over dit onderwerp Klik hieronder voor meer informatie

Auteur Boris de Hingh

Waarom subsetten wat zijn de voordelen Als subsetten dan zo moeilijk is door zoveel kans op onbedoelde fouten tijdens het testen waarom zouden we het dan doen Het antwoord op die vraag is simpel organisaties kunnen er een aantal belangrijke business doelstellingen mee behalen

Het testproces verkorten door met kleinere testdatasets te werken Het testen van batchruns gaat sneller en het klaarzetten van testdata is niet langer de bottleneck in een testproces

En als het testproces de bottleneck is in de time-to-market dan verkort het dus ook de time-to-market Nieuwe systemen kunnen eerder in productie worden gebracht

Wil een organisatie werken volgende de principes van continuous development -delivery of integration dan is het inrichten van subsetten essentieel Zonder een dagelijkse verse subset van testdata kan niet goed en snel worden getest

Kosten verlagen met kleinere datasets die minder opslag en minder systeembronnen vereisen en lagere DBMS-licentiekosten vragen

Ontwikkelingscycli verkorten door vooraf gedefinieerde subsettingscripts die snel en op afgesproken tijden beveiligde datasubsets maken waarbij de referentieumlle integriteit behouden blijft

Samenvattend kunnen we zeggen dat een onderzoek naar de mogelijkheden van data subsetting voor iedere organisatie interessant en waardevol is Subsetten kan moeilijk zijn maar het levert (veel) geld op en testen gaat sneller en beter Dan heb ik eacuteeacuten belangrijk voordeel nog niet genoemd de doorlooptijd van het anonimiseren van testdata is vele maken korter Daarover in mijn volgende blog(s) meer Wil je meer weten over dit onderwerp Klik hieronder voor meer informatie

Auteur Boris de Hingh