AVG en testen: ben je een scepticus of een gokker?

Vorige week publiceerden we een blog waarin we pleiten voor de volgende generatie in Test Data Management (TDM), namelijk Test Data Automation (TDA). We hebben besproken waarom de traditionele aanpak van masken, subsetten en klonen niet meer voorziet in de behoefte van de Agile teams.

In de blog van deze week gaan we dieper in op het voordeel van TDA, bekeken vanuit het perspectief: hoe kunnen we voldoen aan de huidige wetgeving rond gegevensbescherming en de juiste testdata op het juiste tijdstip leveren? In deze blog lees je meer over welke gevolgen de algemene EU-verordening inzake gegevensbescherming (AVG) heeft voor het testen. En hoe met behulp van TDA deze nageleefd kan worden en tegelijkertijd de testsnelheid en -kwaliteit kan worden gemaximaliseerd.

Test Data Compliancy: een probleem dat niet zal verdwijnen

Het voorstel voor de AVG is al in 2012 ingediend en is in 2016 goedgekeurd. Hier zagen we op hoofdlijnen twee reacties op, namelijk:

  1. De scepticus: “Grote organisaties zullen zich eenvoudigweg groeperen en zich hier tegen verzetten in de rechtbanken. In de praktijk zal er niets veranderen en er is geen enkele manier waarop de Autoriteit Persoonsgegevens (AP) zo snel verandering kan eisen, of dat ze hoge boetes kan
  2. De gokker: “Boetes worden alleen opgelegd na opvallende datalekken. Er is geen enkele manier waarop instanties regelmatig audits gaan uitvoeren, laat staan dat ze mijn bedrijf gaan controleren. Bovendien is de kans dat we te maken krijgen met een datalek erg klein, dat is namelijk nog nooit eerder gebeurd!”.

2019: een issue dat niet kan worden genegeerd

Een kijkje in de toekomst, zeg over vijf jaar: De implementatieperiode is inmiddels voorbij. De AVG is al een tijdje van kracht en de substantiële boetes werpen twijfel op bij zowel de scepticus als de gokker. De zware straffen die onlangs zijn opgelegd herinneren ons aan de reële dreiging van datalekken, maar ook aan een serieuze intentieverklaring met betrekking tot de handhaving van de AVG.

Een paar voorbeelden:
In juli 2019 legde het Engelse AP een recordboete van £183 miljoen op aan British Airways, in verband met het verzamelen van gegevens van 500.000 klanten door hackers. Dit komt overeen met ongeveer 1,5% van de wereldwijde jaaromzet van British Airways.

Een dag later kwam de aankondiging van een voorgenomen boete van £99,2 miljoen voor Marriott International, in verband met het op straat komen te liggen van de informatie van ca. 339 miljoen gasten. 30 miljoen van deze hotelgasten zijn Europeanen, dus kreeg Marriott een boete, ondanks dat het een Amerikaans bedrijf is. Dit neemt de twijfel weg over het vermogen van de AP om de wereldwijde reikwijdte van de AVG af te dwingen.
De AP wijst instanties in elk geval op een gebrek aan onvoldoende veiligheidsmaatregelen en ook op de verantwoordelijkheid van organisaties voor de gegevens die zij verwerken. Hoe verhoudt zich dit tot de testtrajecten in de praktijk? Hoe kan testen en specifiek TDA bijdragen om dit risico te beheersen?

Misschien toch maar eens kijken naar TDA

Vanuit testperspectief is het gebruik van productiegegevens in test- en ontwikkelingsomgevingen nog steeds het grootste risico. Er wordt vanuit het oogpunt van AVG al langer gewaarschuwd dat dit verboden is, maar toch gebruikt 65% van de organisaties nog steeds potentieel gevoelige productiedata in de testomgevingen.

Productiegegevens lijken een voor de hand liggende keuze om te gebruiken voor testen. Het probleem is dat test- en ontwikkelingsomgevingen in de meeste gevallen minder veilig zijn dan productieomgevingen, zodat alle gevoelige gegevens die erin worden opgeslagen het risico van een datalek verhogen.

Dan zijn er nog de rechten van de Europese burgers met betrekking tot de gegevens (bijvoorbeeld: je mag de gegevens alleen gebruiken waarvoor ze bestemd zijn). Deze rechten gelden ongeacht of er sprake is van een inbreuk op de gegevensbescherming en vormen een extra uitdaging voor de huidige praktijk op het gebied van kwaliteitsborging.

Als laatste is daar dan ook nog de logistieke nachtmerrie van de huidige TDM-oplossingen. Veel organisaties slaan gegevens op in verschillende testomgevingen, in onbeheerde formaten zoals spreadsheets op lokale machines van de testers. Deze organisaties hebben geen idee meer waar bepaalde gegevens worden bewaard en zullen daarom moeite hebben om ze op verzoek te identificeren, te kopiëren en te verwijderen.

Verbetering van de gegevensbeveiliging en kwaliteit van de testgegevens

Het goede nieuws is dat het gebruik van productiedata in testomgevingen te vermijden is. Het genereren van synthetische testdata is vandaag de dag een goed alternatief om organisaties te voorzien van testdata, dit geldt zelfs voor complexe systemen.

Kwalitatieve synthetische testdata wordt opgebouwd uit een model van de metadata die in productie wordt gevonden. Het weerspiegelt complexe patronen in data zoals trends, terwijl het volledig fictief blijft. Het ondersteunt daarom een accurate en stabiele testuitvoering, zonder het risico van het blootleggen van gevoelige informatie.

Naast dat de data veiliger tot stand komt en voldoet aan de AVG, is het ook mogelijk om zoveel gegevenscombinaties te generen als je wilt. Dat geeft een aanzienlijke kwaliteitswinst, omdat er ook gegevenscombinaties gegeneerd kunnen worden die niet in bestaande productiegegevens gevonden worden, inclusief de negatieve scenario’s en uitschieters die nodig zijn voor een goede testdekking.

Het verbeteren van de gegevensbeveiliging bij het testen is daarom niet alleen een logistieke kwestie: het kan de testdekking verhogen, de kwaliteit van de software verbeteren en de inspanning om bevindingen te verhelpen verminderen.

Organisaties zullen niet van de ene op de andere dag kunnen overschakelen op het gebruik van volledig synthetische testgegevens. Toch moet een effectieve TDA-strategie erop gericht zijn productiegegevens geleidelijk te vervangen door fictieve testgegevens. Deze “hybride aanpak” blijft werken met productiegegevens waar nodig, waarbij op termijn alle testgegevensbronnen vervangen worden door fictieve equivalenten die de dekking verbeteren.

Testers en gegevensbeschermingsfunctionarissen (DPO’s) kunnen dan met een gerust hart genieten van de kwaliteit van de toepassingen.

Bedankt voor het lezen en bij dezen alvast de aankondiging voor de blog van volgende week over het creëren van testdatasets met hoge dekking.

Om meer te weten te komen over hoe de naleving van testgegevens ook de testdiscipline kan maximaliseren, kunt u zich op 28 november in Hotel Mitland te Utrecht aansluiten bij de Meetup “Test Data Automation”.
Aanmelden voor dit event kan via deze link.

SOCIAL MEDIA

NEEM CONTACT MET ONS OP

CloseSure Noord BV
de Vos van Steenwijklaan 75
7902 NP Hoogeveen
+31 (0)88 383 01 20

CloseSure Utrecht BV
Landjuweel 11 B
3905 PE  Veenendaal
+31 (0)88 383 01 10

CloseSure West BV
Europalaan 16
2408 BG  Alphen a/d Rijn 
+31 (0)88 383 01 50

CloseSure Oost BV
Hazenweg 70
7556 BM  Hengelo
+31 (0)88 383 01 00

CloseSure Zuid BV
Noord Brabantlaan 265
5652 LD  Eindhoven
+31 (0)88 383 01 40

CloseSure Services BV
Hazenweg 70
7556 BM Hengelo
+31 (0)88 383 01 60

(c) Copyright 2017-2019 CloseSure Nederland B.V.

SHARE THIS!