Goede testdata zijn ondergeschoven kindje

Productiedata zijn nog steeds de meest gebruikte data om applicaties mee te testen. Vaak mag dat wettelijk niet. Er zijn alternatieven.

Wereldwijd gebruikt 80 procent van de organisaties een kopie van de productiedata voor het testen van software. Dat berekende analistenbureau Gartner in 2011, maar de cijfers zijn nog actueel, zegt managing consultant Boris de Hingh van Valori. ‘Misschien is in Nederland het percentage wel hoger. Ik ken eigenlijk geen organisatie die geen gebruik maakt van productiedata voor hun testproces.’ Cto Joachim Vandecasteele van Coolprofs herkent de cijfers ook, maar ziet de mate waarin de productiedata worden gemaskeerd, stijgen. ‘De veranderde wet- en regelgeving zet steeds meer organisaties aan het denken.’

De huidige privacywetgeving verbiedt het gebruik van persoonsgegevens voor andere doeleinden dan waarover is gecommuniceerd met de betrokken personen. Softwareontwikkeling of -testen is dus geen legitiem doel, als hierover niet expliciet gecommuniceerd is. ‘Dat zou nog kunnen worden afgedekt als bedrijven in de regelementen zouden vermelden dat ze de persoonsgegevens ook hiervoor gebruiken’, zegt data privacy officer Edwin van Vliet van Suprida. ‘Maar ik ken geen bedrijf die dat in de regelementen heeft staan.’

Bovendien is er de toegevoegde wet Meldplicht Datalekken. Per 1 januari 2016 riskeren bedrijven die persoonsgegevens lekken een boete. De Hingh: ‘Een organisatie moet nu kunnen aantonen dat ze maatregelen hebben getroffen om datalekken te voorkomen. Productieomgevingen zijn vaak uitstekend beveiligd. Dat geldt vaak niet voor testomgevingen. Als daar dezelfde productiedata in wordt gebruikt – vaak nog door externe partijen – is de kans op een datalek dus nog groter.’

Dat het gebruik van productiedata als testdata beveiligingsissues oplevert, is jammer, vindt Van Vliet. ‘Ik zeg altijd: de mooiste testdata zijn productiedata. Het is niet zo dat één stukje software met één database moet worden getest. Vaak gaat het om een keten van applicaties, zeker bij grote bedrijven. Dat betekent dat data consistent aan elkaar moeten zijn en dat is moeilijk na te maken.’

Vandecasteele is dat niet per se met hem eens. ‘Productiedata hoefen geen extremen, complexe gevallen of risicogevoelige elementen te bevatten. Bij een systeem voor kredietverlening bijvoorbeeld bevat de data niet per se de minimale of maximale kredieten. Daarom is productiedata wel maatgevend voor het testen van de performance en de load, maar niet afdoende om de volledige kwaliteit van het systeem te kunnen testen.’

Testdata die het dichtst in de buurt komen van de data die in productie gaan worden gebruikt, zijn de gemaskeerde of geanonimiseerde productiedata. Volgens Van Vliet is maskeren een hele goede oplossing. ‘Persoonsgevoelige gegevens worden veranderd. Dat kan op basis van een formule. Naam, adres en woonplaats worden door elkaar gehusseld.’

Anonimiseren of maskeren is een complex traject, meent De Hingh. ‘Zeker als de data voor het testen van een softwareketen worden gebruikt. Als het systeem met geanonimiseerde data gaat communiceren met andere systemen, waar die data niet in worden gebruikt, heb je kans op onbedoelde fouten of corrupte data.’

Een andere optie is synthetische of gegenereerde testdata. Testdata worden dan vanaf scratch opgebouwd, een tijdrovend proces. ‘Bovendien worden deze data door gebruikers zelf bedacht en missen daardoor vaak de extreme gevallen of de uitzonderingen’, zegt De Hingh. Synthetische data kunnen handmatig via de voorkant worden ingevoerd. ‘Dat werkt uitermate traag. Het duurt net zo lang als een medewerker nodig heeft om data in te voeren’, zegt Van Vliet.

Testdata zijn ook automatisch te genereren. Dat is ook bedachte data, maar deze data worden automatisch verveelvoudigd. Ook die data missen de extreme gevallen. Vandecasteele denkt dit te ondervangen door wat zijn organisatie ‘seed data’ noemt. ‘Zoek in de productiedata wat voorkomens zijn, bijvoorbeeld voorvoegsels of productcodes. Gebruik die voorkomens als mogelijke waarden en genereer op deze manier de rest van de testdataset.’

Een nadeel bij synthetische of gegenereerde data blijft het missen van historische data. Die zijn wel deels in te vullen in velden, meent Vandecasteele, maar vooral als data worden gebruikt voor het testen van een workflow is het lastig. ‘Dan moet je goed nadenken over de volgorde van de bedachte data.’

Voor organisaties met een eigen ontwikkelafdeling is het verkrijgen van goede testdata – op welke manier dan ook – relatief gemakkelijk te organiseren. Bovendien kennen deze organisaties het belang van beveiliging en privacy vaak wel. Lastiger wordt het als organisaties een applicatie kopen van een externe leverancier. De geïnterviewden vinden dan de softwareleverancier verantwoordelijk voor de data. Van Vliet: ‘Maar in de praktijk leveren bedrijven de software af, bijvoorbeeld aan ziekenhuizen, en moet de organisatie zelf voor testdata zorgen. En die testdata zijn dan vaak productiedata, de klant weet niet beter.’

Het vergaren van testdata moet deel uitmaken van de teststrategie, en moet daarom aan het begin van het ontwikkel- en testproces worden geregeld. Als dat niet goed gebeurt, dan kan het gebrek aan testdata zorgen voor vertraging. Zeker bij Agile ontwikkeltrajecten. De Hingh: ‘Vaak was en is het verkrijgen van testdata de meest tijdrovende activiteit. Als we als testers bij sprints van twee weken een week nodig hebben voor het vinden van de juiste testdata, dan worden testers al snel de vertragende factor in een project.’

Dit artikel is ook verschenen in Computable Magazine, jaargang 49, nummer 5, mei 2016.