Test data management: hoe organiseer je dat nou? Een stappenplan

In veel organisaties staat test data management (TDM)

intussen hoog op de agenda, omdat de voordelen

overduidelijk zijn. Voor de organisaties die nog niet overtuigd

zijn, benoem ik hieronder - zonder volledig te willen zijn - nog

even kort een aantal business doelen die we kunnen bereiken

met TDM.

Bescherming van privacy:

Door het anonimiseren van gegevens voorkom je dat privacygevoelige gegevens via

de minder veilige testomgevingen op straat komen;

Kostenreductie:

Door het subsetten (verkleinen) van productiedatabases voordat ze naar de

testomgevingen worden gekopieerd, reduceer je sterk de kosten van storage,

hardware en DBMS-licenties;

Verkorting van de Time to Market:

De doorlooptijd van het testen wordt sterk verlaagd als het TDM proces goed is

ingericht: de testers beschikken altijd snel over goede, veilige en kleine sets van

testdata. Dus geen gezoek, gemopper of gehannes meer om testdata te verkrijgen.

Én geen batchtestgevallen meer met een doorlooptijd van drie weken!

Goed, de business voordelen zijn duidelijk. Maar hoe organiseren we dat nou? Welke

processen moeten we implementeren, welke mensen hebben we nodig, welke hardware en

welke tools zijn er nodig? Om antwoord te vinden op deze vragen moeten we een proces

door dat eigenlijk heel simpel is.

Allereest achterhalen we wat de eisen en wensen van de organisatie zijn (1). Vervolgens

maken we een plan met de activiteiten, de benodigde mensen en de soft- en hardware om

TDM in te richten (2). Als de planning akkoord is maken we een detailontwerp (3). We

bepalen exact wat er moet gebeuren, door wie en met welke middelen. Daarna voeren we

het ontwerp uit (4). Na uitvoering stellen we zaken bij, breiden we met andere onderdelen uit

en onderhouden we TDM (5).

Laten we de stappen eens verder uitwerken. Ook hier geldt dat mijn opsomming niet

uitputtend is. Elke organisatie is anders en iedereen heeft zijn eigen werkwijze. Beschouw

deze lijst daarom als handige leidraad.

Stap 1: Analyse van de eisen en wensen

Om de eisen en wensen met betrekking tot TDM te verzamelen moeten we de volgende

activiteiten uitvoeren:

Interviews onder stakeholders, hierbij kun je denken aan:

o De security officer, de CISO of de IT auditor. Bezig met beleid en/of

handhaving omtrent security of privacy;

o De DBA’ers. Verantwoordelijk voor de continuïteit, de betrouwbaarheid en

inhoudelijke kwaliteit van data;

o En de testers die als klant gebruikmaken van testdata.

Beschrijven van de huidige situatie, zodat de knelpunten duidelijk worden.

Vaststellen en benoemen van contactpersonen per belanghebbenden.

Beschrijven en/of vastleggen van het applicatielandschap, de gegevensarchitectuur

en de hardware.

Nadenken en opstellen van SLA’s. Over het algemeen is het handig om hier vroeg

mee in het traject te starten omdat SLA’s ook vol staan met expliciete of impliciete

eisen en wensen.

Stap 2: Planning

In dit geval bedoel ik met planning zeker ook planvorming. Dus wanneer, moet wat, door wie

gebeuren?

Voer een gap analyse uit: waar zitten de verschillen tussen de huidige en gewenste

situatie?

Maak een data cataloog: welke data hebben we in huis? Wie is eigenaar en waar is

de data opgeslagen?

Formeer een team dat zich met TDM gaat bezighouden.

Definieer een eerste pilot of Proof of Concept (PoC).

Leg belangrijke deadlines vast. Zijn andere projecten direct afhankelijk van de

invoering van TDM of moeten we voldoen aan veranderende wet- of regelgeving?

Stap 3: Ontwerp

Na de planvorming moeten we antwoord krijgen op de vraag: hoe gaan we TDM invoeren,

wanneer zijn we tevreden?

Bepaal de TDM strategie en welke TDM processen worden ingericht:

o Subsetting: een kleinere versie van de productiedatabase opnemen in de

testomgeving.

En/of:

o Anonimiseren: zorgen dat er geen natuurlijke personen meer herleidbaar

zijn in de data in de testomgeving.

En/of:

o Datageneratie: het genereren van fictieve data op basis van criteria.

Bepaal wie verantwoordelijk wordt voor de processen en wie ze daadwerkelijk gaat

uitvoeren.

Bepaal welke hardware nodig is.

Bepaal welke tooling nodig is. Maken we het zelf of schaffen we tools aan?

Stel een coördinatie- en communicatieplan op.

Bepaal voor de eerste pilot of PoC welke datasources nodig zijn.

Overleg met de eigenaar van de datasource en met de testers welke data nodig is,

welke data privacygevoelig is en op basis van welke criteria een subset van de data

kan worden gemaakt.

Stel criteriavast op basis waarvan we bepalen of en wanneer de pilot of PoC is

geslaagd. Met andere woorden: maak meetbaar wanneer de doelstellingen zijn

behaald.

Stap 4: Uitvoering

Nadat we alle keuzes hebben bepaald, gaan we uitvoeren. Hierbij moeten we rekening

houden met de volgende aandachtspunten:

Zorg voorafgaand aan de uitvoering voor goede back-ups. Mocht het onverhoopt

fout gaan, dan moeten we alles kunnen terugdraaien.

Door te zorgen voor uitgebreide logging kunnen we precies zien wat er gebeurt.

Bedenk of het verstandig en nodig is om een eerste run buiten kantoortijden uit te

voeren.

Stap 5: Bijsturen, uitbreiden, onderhouden

Na de uitvoering gaan we evalueren of de pilot of PoC geslaagd is:

Kunnen de testers uit de voeten met de testdata? Is de data nog referentieel integer,

is de dekkingsgraad voldoende en treden er geen onverwachte fouten op in de

applicatie?

Zijn ook de mensen die vooral belang hebben bij het privacy aspect van TDM

tevreden? Voldoen de technische en organisatorische maatregelen aan de Wet

Bescherming Persoonsgegevens en de nog veel strengere Europese

privacywetgeving?

Blijven de systemen gewoon draaien tijdens het draaien van de kopie, de

anonimiserings- of subsettingsrun? Of slokken de runs teveel machinecapaciteit op?

Zit alles organisatorisch goed? Hebben we TDM efficiënt ingericht of vraagt het

onevenredig veel tijd van mensen in de organisatie?

Is iedereen voldoende en op tijd ingelicht?

Als we deze antwoorden hebben verkregen, kunnen we op basis van de evaluatie bijsturen.

Hebben we nieuwe templates nodig? Andere SQL scripts?

Moeten we de criteria voor anonimisering of subsetting aanpassen?

Hebben we te lichte hardware of juist te zware, ofwel te dure hardware?

Moeten we andere mensen of expertises bijschakelen?

Klaar is kees?

Nou, en dan zijn we er. De pilot of PoC is geslaagd, dus we kunnen door: we gaan ook

andere databases, sectoren of domeinen aanpakken, zodat op een zeker moment de gehele

organisatie kan testen met veilige, consistente en efficiënte data. Is het dan klaar? Nee!

Zodra er eerste wijzigingen op de databases komen, nieuwe eisen aan privacy worden

gesteld of de interne security richtlijnen worden aangepast, zullen we ook onderhoud moeten

plegen op de TDM zaken. Denk aan het aanpassen van scripts of templates en wellicht het

creëren van testdata in plaats van kopiëren. Er blijft dus genoeg te doen.

Te omslachtig, te complex, te duur?

Zoals ik in mijn inleiding al schreef: bij veel organisaties staat TDM hoog op de agenda.

Andere organisaties zijn minder overtuigd van TDM en vinden het veel te omslachtig, te

complex en daardoor te duur. Wellicht dat dit artikel - met een simpel stappenplan voor

invoering - dit beeld verandert. Als dat niet zo is, blijf mijn artikelenreeks dan volgen, want ik

ben ervan overtuigd dat er voor elke organisatie een valide business case is voor TDM. Als

kostenbesparing niet voldoende is voor een valide business case, dan is het wel de steeds

strenger wordende wetgeving. In één van mijn volgende artikelen zal ik de laatste twijfelaars

daarvan overtuigen…

Hoe staat het ervoor bij jouw organisatie? Staat test data management al op de agenda?

Waarom wel of niet?

Wil je meer weten over dit onderwerp? Klik hieronder voor meer informatie

Auteur: Boris de Hingh