4 vragen om te ontdekken of test data management iets voor jou is

1. Gebruik je persoonsgegevens tijdens het testen van software?

Eigenlijk is dit de meest eenvoudige vraag. Want als op deze vraag het antwoord ja is, dan zul je over een test data proces na moeten gaan denken. Er zijn wat mitsen en maren, maar in 90% van alle gevallen zul je een proces moeten gaan opstarten.

Als het antwoord op deze vraag “nee” is, dan kan je alsnog na denken over een test data proces, maar er zijn dan andere beweegredenen. Deze komen later in dit artikel aan de orde.

Als het antwoord ja is, dan zijn er enkele andere vragen die gesteld kunnen worden. Belangrijke vragen zijn:

• In hoeveel systemen worden persoonsgegevens opgeslagen?
• Is er sprake van één kernsysteem en randsystemen?
• Hoe werkt onze keten?
• Welke gegevens willen we beschermen?
• …..

Er zijn nog vele andere vragen die gesteld kunnen worden en daarvoor zou een blik op ons data masking project plan ook kunnen helpen.

2. Zijn er veel en/of grote databases in gebruik?

Veel en groot zijn relatieve begrippen. Echter in grotere organisaties van een kleine 1000 tot meer medewerkers is er vaak sprake van meerdere en grotere databases. Interessant om te weten is om vast te stellen hoeveel databases er voor niet-productiedoeleinden worden gebruikt én hoe groot deze niet-productie databases zijn. Veelal zien wij dat bij grotere organisaties in ieder geval 3 niet-productiedomeinen zijn, naast hun productiedomein, namelijk een ontwikkel-, test- en acceptatiedomein. Maar vaak zien we voor kernsystemen van organisaties dat er wel meer dan één test en ontwikkelomgeving beschikbaar wordt gesteld. Helaas voor organisaties is het zo dat deze kernsystemen van behoorlijke omvang zijn.

Voorbeeld: een organisatie heeft één productie omgeving, één acceptatie, drie testomgevingen en 3 ontwikkelomgevingen. De productieomgeving is in totaal 2,5 terabyte groot. Dat levert in totaal een van 17,5 terabyte aan niet-productieomgevingen op, 700% ten opzichte van productie!

En dit geldt voor slechts één kernsysteem. In grotere organisaties is er sprake van meerdere kernsystemen met de daarbij behorende omvang.

Dit levert uiteraard een kostenpost op voor storage. Maar niet alleen storage is een kostenpost, bij verschillende databaseleveranciers moet je voor test omgevingen of hogere omgevingen ook databaselicenties betalen. De ontwikkel omgevingen vallen in verschillende gevallen onder andere, vaak zeer strikte, licentievoorwaarden.

Als er een van deze situaties van toepassing is op jouw situatie, dan is het de moeite waard om verder onderzoek te doen naar test data management. Er zijn technieken beschikbaar die ervoor kunnen zorgen dat er minder data nodig is in deze omgevingen.

3. Hoe eenvoudig is test data beschikbaar?

Er zijn in algemene zin drie veelvoorkomende situaties bij het testen van software en de beschikbaarheid van test data, namelijk:

1. Er is geen testdata beschikbaar, dus dit moet nog geregeld worden of
2. Er is wel testdata beschikbaar, maar die is niet representatief voor productie
3. Er is testdata beschikbaar en deze is representatief (al dan niet geanonimiseerd)

Voor punt 1 en punt 2 is er naar ons idee dezelfde ‘oplossing’, , namelijk genereren of verversen van de testdata. Kijkend naar punt 2, zien we wel dat er omgevingen beschikbaar zijn bij klanten met testdata. Deze omgevingen zijn niet altijd meer representatief. Er is wel testdata, maar deze is slecht of  niet bruikbaar. Soms bestaat een omgeving al tijden (maanden, zo niet jaren) met alle vervuiling en onbruikbaar geworden testdata. Of de omgeving is gevuld met zelfgemaakte testdata (de Donald Ducks van deze wereld) en dit sluit niet aan op jouw wensen en behoeften. Uiteindelijk is het doel niet om testdata te hebben, maar om test data te hebben die representatief is voor wat in productie zou moeten gaan werken. Kortom: een dataset genereren of je testdata set verversen is in deze situatie een zinvolle actie.

Als er testdata beschikbaar gemaakt moet worden, dan kun je vaak kiezen uit twee opties. De eerste is het zelf genereren van een testdataset. De tweede is het verversen van de testdatabase. Dit kan door opnieuw een kopie van productie aan te vragen. Afhankelijk van wat je wil bereiken is een (geanonimiseerde) kopie maken van een productiedatabase de beste optie. Dan weet je immers zo goed als zeker dat de testdata aansluit op de productiesituatie en dus representatief is. Het nadeel hiervan is dat het proces om een kopie productie te krijgen opgestart moeten worden. Dit is vaak een langdradig (voornamelijk procedureel) proces, want vaak kunnen softwaretesters niet zelf dit proces opstarten. Veelal moeten testers een verzoek indienen bij management, die vervolgens dit verzoek weer elders in de organisatie beleggen, die dit vervolgens weer geven aan een medewerker die dit moet regelen. Uit verschillende onderzoeken blijkt ook steeds dat er veel (3-8) personen betrokken zijn bij dit proces. Gevolg is dat hier bijzonder veel tijd verloren gaat aan procedurele onderdelen, terwijl deze tussenstappen geëlimineerd zouden kunnen worden. Toch?

En dan blijft het technische element over van de verversing zelf. Het prettige van techniek is dat dit te automatiseren is. Kortom: met een slim testdata-portaal zijn deze processen door softwaretesters zelf op te starten. Dan blijft de doorlooptijd van de verversing over. Deze doorlooptijd is met slimme subsettechnologieën en een slimme architectuur tot zeer acceptabele niveaus te krijgen, zeker in vergelijking met de huidige werkwijze.

Een alternatieve oplossing is het gebruiken van testdata generatie. Het voordeel daarvan is dat je geen groot proces hoeft te veranderen. Het nadeel is dat de representativiteit van de testdata toch altijd twijfelachtig zal blijven.

Samenvattend: als het beschikbaar stellen van testdata langdradig of ingewikkeld is, dan is het zeker de moeite waard om het proces goed te beoordelen en te onderzoeken waar verbeteringen te behalen zijn. Soms is het laaghangend fruit, soms heeft het meer impact. Maar er is zeker een business case te maken als beschikbaarheid een uitdaging is.

4. Hoeveel software teams werken er in de organisatie?

Een volgende interessante vraag, waarvan het antwoord een indicatie geeft voor of test data management verbeteringen oplevert in het testproces. Eigenlijk moet de vraag specifieker gemaakt worden: hoeveel software teams werken er tegelijkertijd op één testdatabase? Is het zo dat elk team toegang heeft tot een eigen testomgeving? Of zijn er meer teams dan testomgevingen of -databases? In veruit de meeste gevallen zien wij dat er minder testomgevingen beschikbaar zijn dan dat er teams zijn. Met als gevolg conflicten. Als meerdere teams in verschillende projecten dezelfde applicatie nodig hebben met de daar bijbehorende testdata dan leidt dit in alle gevallen tot problemen. En daardoor wordt de applicatie onvoldoende getest wat uiteindelijk leidt tot productieverstoringen.

In een ideale wereld zou elke software tester zijn eigen systeem onder test hebben en zijn eigen testdatabase. Waarom zien we dat dan zo weinig gebeuren? Vaak heeft dit te maken met technische belemmeringen en de kostenverhogende effecten. De belangrijkste technische belemmeringen hebben we ook al even genoemd in de vorige paragraaf. Te denken valt aan: de omvang van de database en de tijd die het kost om een database beschikbaar te maken. De kostenverhogende effecten zal niet enorm lastig uit te leggen zijn, als iedere testers een eigen 100% kopie productie krijgt, dan zullen de kosten fors hoger worden.

Maar dan moet je ook de vraag stellen, heb je een 100% kopie productie nodig om te kunnen testen? Uiteindelijk heeft testen te maken met risico mitigerende maatregelen. Je wil zeker zijn dat wanneer de software naar productie gaat, dat de software doet wat het zou moeten doen. Daarvoor is vaak ook een OTAP architectuur ingesteld. In elke stap van het proces vangen we mogelijke fouten op. In die zin is software testen soms niet heel anders dan door middel van een steekproef iets te zeggen over een volledige populatie. Met een steekproef kunnen we zeggen met een bepaalde mate van zekerheid (risico – ook mitigerend, want we kunnen dit risico groter en kleiner maken) dat dit representatief is voor de werkelijkheid.

Kortom: als je in staat bent om op een slimme manier testdata te onttrekken uit een kopie productie, dan is daar een enorm voordeel te halen. Met ‘slim’ bedoelen we dat je niet zomaar een paar rijen uit je tabellen kunt selecteren om die vervolgens in je testomgeving te zetten. Alle onderlinge relaties tussen tabellen moeten uiteraard ook in stand blijven om je tests goed te kunnen uitvoeren. Daarnaast wil je misschien ook bepaalde randgevallen en eventuele vervuiling in je testdataset hebben. Die moet je dan eerst wel weten te vinden. Inzicht in je data(model) is hier dus zeker van belang.

Conclusie

Er wordt vaak gekeken naar test data management wanneer er een behoefte is voor geanonimiseerde test data. Echter, test data management houdt veel meer in dan alleen data-anonimisering. Het helpt ook bij het beheren en verdelen van test data. Dus niet alleen als je met persoonsgegevens werkt, maar ook als er minder testomgevingen of -databases zijn dan testteams, dan loont het de moeite om de mogelijkheden van test data management verder te ontdekken.