Data subsetting: een belangrijk, maar minder bekend onderdeel van Testdata management

donderdag 13 november 2014

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 DBA’ers. “Maar wat doen die tools of scripts dan?”, 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. Referentiële 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 referentiële integriteit is: Referentiële 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 50.000 klanten selecteren, moeten we zorgen dat we alleen klantenorders uit de ordertabel selecteren die betrekking hebben op die 50.000 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 50.000 klanten wonen.

  2. Relaties tussen verschillende databases
    In het vorige punt beschreef ik het belang en de uitdaging van referentiële integriteit binnen één 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 één 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 referentiële 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 één belangrijk voordeel nog niet genoemd: de doorlooptijd van het anonimiseren van testdata is vele maken korter. Daarover in mijn volgende blog(s) meer...