Synthetische test data versus data maskeren

Omgaan met AVG/GDPR in Software Quality

Zouden we synthetische testdata of gemaskeerde testdata moeten gebruiken? We zijn allemaal op zoek naar het antwoord op deze vraag. Maar waarom is deze vraag relevant? Er is maar één echte reden: privacyregelgeving! Dit kan de AVG/GDPR zijn of een andere privacyregeling. We willen weten welke van deze technologieën bruikbaar is. Want als er geen privacyregelgeving was, zouden we waarschijnlijk allemaal volledige kopieën van productiedatabases gebruiken.

De impact van privacyregelgeving op het softwarekwaliteitsproces

Dus wat is de impact van deze voorschriften op het softwarekwaliteitsproces? Hoe kunnen we omgaan met deze privacyregels in ons kwaliteitsproces? Wij als DATPROF weten veel over deze privacyregelgeving. Er is één ding dat je moet onthouden nadat je dit blog hebt gelezen, en dat is:

Je kunt geen kopieën van productiedatabases gebruiken in een niet-productieomgeving.

Helaas kan dat gewoon echt niet meer. Het gaat allemaal niet meer zo eenvoudig als in 2017. Als je met de AVG/GDPR omgaat, is het niet meer zo gemakkelijk om kopieën van productie in een testomgeving te gebruiken. Dus hoe beïnvloedt dit het kwaliteitsproces van de software? Want productiedata is waarschijnlijk de beste testdata… En de reden waarom het de beste testdata is, is omdat we er vrij zeker van kunnen zijn dat als de software op een kopie van productie werkt, deze ook in de productieomgeving zal werken. Maar helaas kunnen we dus geen kopie productie meer gebruiken.

Omgaan met AVG/GDPR in Software Quality

Dus hoe kunnen we nu omgaan met deze privacyregelgeving en de kwaliteit van onze software? Er zijn nog maar twee echte opties met de privacyregels in het achterhoofd:

  1. Synthetische testdata genereren
  2. Testdata maskeren/anonimiseren

Momenteel zien we geen andere mogelijkheid die je kan helpen met de hoogst mogelijke softwarekwaliteit naar productie te gaan. Dus als je te maken hebt met privacyregelgeving, moet je overwegen één van deze strategieën of technologieën te gebruiken. Maar wat zijn de voor- en nadelen van deze opties?

voordelen van synthetische testdata

  • Je gebruikt minder data
  • Perfect afgestemd op je testgevallen
  • Geen risico op datalekken
  • Beperkte afhankelijkheden
  • Besparing op opslagkosten en bijv. licenties

Als je synthetische testdata kunt genereren, heb je minder testdata beschikbaar in je omgeving en is deze perfect afgestemd op je testgevallen. Als je een lege database hebt in ieder geval, anders is het niet echt een voordeel omdat je testdatabase groeit vanwege het gebruik van extra data.

Topje van de ijsberg

Helaas zijn er enkele nadelen voor het synthetisch genereren van testdata. In veel gevallen, wanneer we gaan nadenken over het genereren van synthetische testdata, denken we vooral aan het topje van de ijsberg. In eerste instantie lijkt het genereren van synthetische data namelijk vrij eenvoudig. Maar als snel zul je merken dat er problemen ontstaan, omdat er onder het wateroppervlak nog een veel groter deel van de ijsberg schuilt. 

Bijvoorbeeld: hoe zit het met het genereren van synthetische testdata voor dat andere systeem dat je nodig had? Hoe krijg je de testdata in je database? Kan het worden geïmporteerd via de database of alleen via de front-end van een systeem? Mag je dit doen? Bijvoorbeeld: met Salesforce kun je alleen de front-end gebruiken. Je kunt niet rechtstreeks communiceren met de database. Maar hoe zit het met het tweede systeem of het derde? Je hebt waarschijnlijk niet slechts één systeem, je hebt waarschijnlijk meerdere systemen.

We moeten dus nadenken over het genereren van synthetische testdata voor meer dan één systeem en als je met het eerste systeem testdata kunt importeren, betekent dat niet direct dat dit ook mogelijk is in het tweede of derde systeem. En zo wordt het gebruik van synthetische testdata dus ineens toch erg ingewikkeld.

Nadelen van synthetische testdata

Het wordt nog gecompliceerder, want als je erover nadenkt om alle attributen te genereren met synthetische testdatageneratoren, is het al een behoorlijk intensieve taak. In veel gevallen bestaat een eenvoudig datamodel uit 1.000 tabellen, met bijvoorbeeld 15 kolommen. Dus als je synthetische testdata voor dit systeem wilt genereren, heb je al 15.000 (1000 x 15) generatoren nodig. Je hebt deze nodig om alle benodigde attributen voor je systeem te hebben. Dus als je begint na te denken over het genereren van synthetische testdata, moet je het volgende weten:

  1. Hoeveel attributen heeft je datamodel (niet database)
  2. De functionele vereisten van je systemen
  3. Problemen met datakwaliteit
  4. Historische data

Wanneer synthetische testdata genereren?

De enige reden die wij ons kunnen voorstellen om synthetische testdata te gebruiken, is als je een geheel nieuw systeem of nieuwe applicatie bouwt. Je hebt dan geen testdata die je moet maskeren, dus kun je synthetische testdata genereren. Of misschien in een situatie waarin slechts één systeem wordt getest. Maar als je zeker wilt zijn van de softwarekwaliteit, is het zeer tijdrovend om de juiste synthetische testdata te genereren.

Test Data Masking

Bescherm privacy gevoelige data in niet-productie databases, voldoe aan wet en regelgeving en voorkom datalekken in QA omgevingen.

Data Masking

DATPROF Privacy

Data Subsetting

DATPROF Subset

Data Automation

DATPROF Runtime

Data Discovery

DATPROF Analyze