Testen met persoonsgegevens is niet geoorloofd

Binnen de AVG moet iedere organisatie die persoonsgegevens verwerkt vooraf formuleren welk doel deze verwerking heeft. Dat doel kan bijvoorbeeld zijn: aan een wettelijke verplichting voldoen of om pakketjes op het juiste adres bezorgd krijgen. Maar persoonsgegevens om te testen? Dat mag niet zomaar meer. Consensus is dat software ontwikkelen en testen geen doelen zijn die verenigbaar zijn met het doel waarvoor persoonsgegevens worden verzameld. Daarnaast zijn organisaties verplicht om aan te tonen dat zij de verwerking van persoonsgegevens zoveel mogelijk beperken, ook op ontwikkel- en testomgevingen. Het is goed om te weten dat er alternatieven voor testen met persoonsgegevens voorhanden zijn. Maar ook dat elk alternatief zijn voor- en nadelen heeft.

Behoefte aan geanonimiseerde productiegegevens? Weet je het zeker?

In de praktijk zien we dat organisaties die gewend zijn om te testen met productiegegevens aan hun AVG verplichting voldoen door deze productiegegevens voor testdoeleinden te anonimiseren.

Binnen deze aanpak wordt een kopie van productiegegevens gemaakt. In deze kopie worden privacy-gevoelige gegevens gehusseld, gemaskeerd of vervangen door fictieve gegevens. Hierdoor gaat de herleidbaarheid met natuurlijke personen verloren. Als de herleidbaarheid zodanig gewijzigd wordt dat hij niet meer hersteld kan worden, spreken we niet langer over persoonsgegevens. Omgevingen die voorzien zijn van geanonimiseerde productiedata vallen daarmee buiten de scope van de AVG. Door deze aanpak te hanteren hoeven organisaties de bestaande testaanpak niet grondig te wijzigen. Anonimiseren lijkt van een afstandje dan ook de kortste slag om bijtijds klaar te zijn voor de AVG.

Parallel aan de door de AVG ingegeven wijzigingen in de testdatastrategie loopt binnen veel organisaties het initiatief om de digitale dienstverlening optimaal aan te laten sluiten bij de steeds veranderende behoefte van de markt. Binnen deze aanpak is het frequent releasen van kleine softwarewijzigingen cruciaal.

Graag wil ik 5 argumenten aanvoeren waarom organisaties die groeien richting Continuous Delivery bij het zoeken naar een manier om AVG-compliant te zijn af zouden moeten zien van het gebruik van geanonimiseerde productiedata.

1. Zuivere testen in de Continuous Delivery pipeline

Binnen een werkwijze waarin frequent software wordt opgeleverd omarmen teams de snelle feedback van hun testautomatiseringsoplossing. Ze gebruiken deze feedback als een thermometer voor de kwaliteit van de gewijzigde software. Een ‘groene build’ is een belangrijke indicatie dat de gemaakte wijzigingen productierijp zijn. Maar een team ontwikkelt alleen vertrouwen in zo’n groene build als aan twee belangrijke randvoorwaarden voldaan is:

• de feedback komt razendsnel
• de testautomatisering is zo rubuust dat de resultaten betrouwbaar zijn: een falende test wijst in alle gevallen op een softwarefout, niet op een fout in de test

Deze situatie is alleen te bereiken als automatische checks in de deployment pipeline geoptimaliseerd zijn op performance en robuustheid. In bijna alle gevallen betekent dit dat er veel kleine checks zijn die ieder uitspraak doen over de correcte werking van een klein stukje code of functionaliteit. Om deze checks snel en robuust genoeg te maken is het noodzakelijk om voor iedere check specifieke testdata te ontwerpen.

Natuurlijk is het technisch gezien prima mogelijk om testen te ontwikkelen op basis van productiedata, maar deze aanpak is in de context van Continuous Delivery suboptimaal. Als een snelle en robuuste feedback van testautomatisering belangrijk voor je is, is het geen goed idee om productiedata te gebruiken. Ook niet als die productiedata geanonimiseerd is.

 2. Frequent releasen zorgt voor onbruikbare testdata

Teams die frequent wijzigingen doorvoeren aan hun software in productie, wijzigen in de regel ook regelmatig de structuur van het datamodel: tabelletje erbij, kolommetje eraf. Dit zijn vrijheden die een team moet hebben om de zo belangrijk geachte wendbaarheid te bieden. De afhankelijkheid van actuele productiedata om software te ontwikkelen en testen maakt dat er constant behoefte is aan een verse kopie van productiedata. Immers: de productiekopie van gisteren is niet meer compatible met de software die vandaag op de testomgevingen staat.

3. Data anonimiseren is duur en werkt vertragend

De behoefte aan het continu maken van back-ups van productie, het anonimiseren van deze back-up en eventueel nog maken van subsets is een bewerkelijk en tijdrovend proces dat zich moeilijk laat schalen. Neem daarbij dat we steeds meer data gaan verzamelen en sets steeds groter worden. De doorlooptijd die dit vraagt staat in de weg van voortgang op ontwikkel- en testwerkzaamheden. De kosten van het constant maken, bewerken en opslaan van data stapelen zich op. Eventuele licentiekosten van de anonimiseringssoftware zijn dan nog buiten beschouwing gebleven, maar een handig ontwikkelteam kan prima zijn eigen data anonimiseren.

4. ‘Privacy by design’-principes verhogen testbaarheid en privacy

De Autoriteit Persoonsgegevens noemt op zijn website het belang van een zorgvuldige en verantwoorde omgang met persoonsgegevens tijdens de ontwikkeling van softwareproducten en diensten. Naast privacy verhogende maatregelen geldt het principe van dataminimalisatie: alleen de persoonsgegevens die noodzakelijk zijn voor de verwerking mogen worden opgeslagen.

Bij de ontwikkeling van een applicatie rekening houden met de mogelijkheid om testdata voor het systeem eenvoudig te kunnen genereren en muteren maakt een systeem beter (automatisch) testbaar en dat is een goede eigenschap van software in een CD-omgeving.

Daarnaast is het binnen deze aanpak niet nodig om persoonsgegevens van productiesystemen te halen om een systeem te kunnen testen. Want ook in het proces van het maken van een back-up en het anonimiseren van de data kunnen datalekken zitten. Bij het gebruik van synthetische data is de kans op het lekken van persoonsgegevens uitgesloten. Maar goed, dat argument geldt natuurlijk ook als Continuous Delivery geen doelstelling is.

 5. Verstop je niet achter de illusie dat alles testbaar is

Een veelgehoord argument voor het gebruik van (geanonimiseerde) productiegegevens bij het ontwikkelen- en testen van software is dat de productiedataset situaties kent die onvoorspelbaar applicatiegedrag op kunnen leveren. Deze situaties laten zich lastig voorspellen.

Als deze situatie zich voordoet, is het verstandig om je niet te verstoppen achter de schijnzekerheid die een serie testen biedt. Geen enkele testaanpak kan namelijk uitsluiten dat er een systeem in productie onverwacht gedrag gaat vertonen. Het is verstandiger om een analyse te maken van de situaties die onvoorspelbaar zijn en voor die situaties testen toe te voegen op basis van synthetische data.

Door frequent kleine releases te doen en het gedrag van het systeem in productie goed te observeren, kan een team leren waar de testaanpak geoptimaliseerd kan worden. Met goede productiemonitoring, de mogelijkheid om problemen snel te fixen of wijzigingen terug te draaien en de wil om steeds een beetje beter te worden kan een team steeds wijzigingen in productie blijven nemen, ook al is de context nog zo complex.

Mijn collega Maarten Piepers vertelt in zijn blog ‘fast feedback: testen in productie’ over het leren van de feedback van productiesystemen om zowel het product als de ontwikkel- en testaanpak te verbeteren.

Wat zegt jouw testdatastrategie over het succes van de deployment pipeline?

Nu testdata dankzij de naderende AVG voor veel ontwikkelorganisaties een hot-topic is, zou het zonde zijn om niet even stil te staan bij het effect van testdata op het succes van de implementatie van Continuous Delivery. Bedrijven moeten beseffen dat geanonimiseerde productiegegevens in een deployment pipeline waarschijnlijk voor problemen gaan zorgen.

Dat maakt niet dat het anonimiseren van productiegegevens in alle gevallen een slechte oplossing is, maar wel dat het gebruik van deze gegevens in een deployment pipeline wat vragen op zou moeten roepen. Ik heb er vast 5 genoemd, maar kijk er naar uit om met je mee te denken over hoe jouw organisatie met softwarekwaliteit in de context van continuous delivery kan omgaan.