De discussie over testdata in een notendop

Voor wie zich nog niet echt in de complexiteit van testdata heeft verdiept; hier is een simpele introductie! De algemene vraag is; hoe kom ik aan de best bruikbare data om mee te testen?

Optie 1: Je kunt testdata zelf bedenken


Het voordeel hiervan is dat het volledig voorspelbaar is wat je als invoer hebt en dus ook volledige controle hebt over wat je testuitvoer is. Een voordeel dat hieruit volgt is dat je lekker kunt variëren met invoer die je normaal gesproken niet tegenkomt. Achternamen met 51 letters, of mevrouw Des’ree Çőgürcű – Sørensen.

Optie 2: Je kunt letterlijk de data uit de live omgeving gebruiken


Het voordeel hiervan is dat je er meteen heel veel van hebt en dat er veel variatie in zit. En niet alleen de ‘leuke’ variantie; er kunnen ook vanuit historie fouten in zitten, zoals velden die vroeger leeg zijn gelaten terwijl ze tegenwoordig verplicht zijn bij nieuwe invoer. Mooi om te testen hoe stevig (ofwel robuust) je software is. En ook prettig; de live data neemt historie mee, zoals een verzekering die al 26 jaar schadevrij loopt. Dat kun je niet zomaar opvoeren, tenminste niet netjes via de gebruikersschermen. En nog een voordeel; je weet vrij zeker dat de gegevens door de hele keten van applicaties gelijk zijn.

Het nadeel is dat je met gebruik van ‘echte’ gegevens heel voorzichtig moet zijn. Niet alleen is dat een verplichting vanuit de wet, het kan ook flinke financiële schade en imago schade opleveren. Het gaat dan vooral om gegevens die naar individuele personen terug te leiden zijn en om getallen en bedragen die niet openbaar zijn. Daarom is er een derde categorie.

Optie 3: Je kunt data uit de live omgeving anoniem maken


Anonimiseren, depersonaliseren. Het zijn niet echt lekker klinkende begrippen, maar het is erg nuttig en wordt vaak toegepast. Er zijn heel veel trucs voor te bedenken, van vrij basaal (zoals alle huisnummers in de database 10 regels naar beneden zetten, zodat er een ander adres ontstaat) tot heel verfijnd (met allemaal speciale software). Op deze manier hou je de voordelen van live data en verklein je de risico’s zoals hierboven beschreven. Deze categorie noem ik graag ‘productiegelijke’ data.

Tips

  • Als je fictieve of geanonimiseerde data gebruikt, zorg dan dat je ze via de bron invoert en alle koppelingen laat lopen. Zo heb je door het hele systeem heen dezelfde data. En bovendien; het zou niet voor het eerst zijn dat geanonimiseerde data via een koppeling weer ‘netjes’ rechtgezet wordt.
  • Wees voorbereid op controles binnen je applicaties. Een combinatie van postcode en huisnummer wordt vaak gecontroleerd en afgevangen als het niet bestaat. Net als IBAN rekeningnummers, waar overigens tools voor zijn om het controlegetal kloppend te krijgen.
  • Er zijn niet alleen tools om te anonimiseren, maar ook om random data te genereren. Je klanten of gebruikers heten dan niet allemaal ‘Piet Jansen’, maar bijvoorbeeld variaties zoals Piet Jansenixyyz. Grammaticaal niet geweldig, maar Piet Jansenixyyz is wel snel gevonden als zijn foutgelopen bestelling moet worden geanalyseerd.
  • Mocht je toch vertrouwelijke productiedata willen gebruiken in de testomgeving, kijk dan niet alleen wie er toegang hebben tot de applicatie of de database zelf. Kijk ook waar exports en rapportages worden opgeslagen en kijk hoe je gegevens over de email worden uitgewisseld.

En als het na dit alles een beetje begint te duizelen, dan is dat een goed teken! Want dit soort afwegingen zijn complex en verdienen de nodige aandacht!

door Sander Mol op zondag 11 mei 2014 in Van alles

Plaats als eerste een reactie!

Naam*: E-mail*: