Testen met persoonsgegevens
Geschreven door Rudi Niemeijer   
vrijdag, 22 april 2011 09:12

 

Ten behoeve van het testen van informatiesystemen wordt door softwaretesters incidenteel gebruik gemaakt van persoonsgegevens. De testers stellen met deze persoonsgegevens vast dat informatiesystemen voldoen aan de eisen die er aan worden gesteld. Tot deze eisen behoren ondermeer de beveiliging, de juistheid van gegevens en de bruikbaarheid van een informatiesysteem voor een gegeven doelgroep. Door gebruik te maken van échte persoonsgegevens kan de juiste werking van een informatiesysteem beter worden aangetoond, bijvoorbeeld doordat de verwerking van een nieuwe versie van een salarissysteem hetzelfde totaal oplevert als de oude versie.

Op het gebruik van persoonsgegevens bij het testen van software berust een taboe: persoonsgegevens dienen niet ongeanonimiseerd onder ogen van ICT'ers te komen. Immers, je moet er niet aan denken dat Erik de Tester je medische gegevens loopt te begluren. Onder bepaalde omstandigheden kan echter het belang van de bescherming van de privacy van burgers niet opwegen tegen het belang van de burger om op een juiste manier in informatiesystemen gerepresenteerd te worden. Immers, je moet er niet aan denken dat de resultaten van jouw medisch onderzoek verkeerd op een computerscherm aan de dienstdoende arts worden getoond omdat Erik de Tester niet al zijn testen heeft kunnen doen.

Ondanks het taboe en ondanks het feit dat er een gezonde afweging mogelijk zou moeten zijn tussen privacy enerzijds en zwaarwegend belang anderzijds, komt het toch met regelmaat voor dat testorganisaties het gebruik van persoonsgegevens niet als uitzondering beschouwen. Aan de andere kant zijn er ook voldoende organisaties die het gebruik van persoonsgegevens dusdanig schuwen dat de kwaliteit van hun software hier nadeel van ondervindt.

In Nederland ziet het College Bescherming Persoonsgegevens (CBP) er op toe dat door de overheidsorganisaties, maar ook hierbuiten, zorgvuldig met de gegevens van Nederlandse burgers wordt omgegaan en dat hun privacy gewaarborgd blijft. Het CBP houdt toezicht op de wetten die het gebruik van persoonsgegevens regelen: de Wet Bescherming Persoonsgegevens (WBP), de Wet Politie Gegevens (WPG) en de Wet Gemeentelijke Basisadministratie (WGB).

Het gebruik van persoonsgegevens door testers wordt veelal overgelaten aan de integriteit van testorganisatie of zelfs aan een individuele tester. De richtlijnen die vanuit de overheid worden gesteld geven dan ook te veel interpretatieruimte om een eenduidig beleid te vormen. Het gevolg is dan ook dat veel testorganisaties in één de uitersten terechtkomen: geen enkele vorm van gebruik van persoonsgegevens, of altijd maar echte gegevens gebruiken in plaats van anonieme testdata.

In de ideale situatie maakt een testorganisatie routinematig en in de regel gebruik van speciaal voor dit doel gemaakte fictieve testgegevens met bijbehorende fictieve persoonsgegevens of heeft een goede manier gevonden om persoonsgegevens te anonimiseren. Daar waar dit de kwaliteit van de software ten goede komt en de belangen van individuele burger niet worden geschaadt kan, onder voldoende gedefinieerde en gecontroleerde omstandigheden, gebruik worden gemaakt van persoonsgegevens. De precieze omstandigheden zullen variëren, maar er is hier een rode lijn te herkennen.


Geraadpleegde bronnen:


Gerelateerde informatie:

 

 
Kwaliteit is een keuze
Geschreven door Rudi Niemeijer   
donderdag, 12 juni 2003 15:15

 

Testen is een middel om de kwaliteit van een product te méten. Bijvoorbeeld de mate waarin een applicatie geschikt is om na aanpassingen in uw organisatie gebruikt te worden, kan met testen worden vastgesteld. Of wat dacht u van de veiligheid van een auto, uitgedrukt in de aanwezigheid van ABS, het aantal airbags en de lengte van de kreukelzone.

Om kwaliteit te máken is meer nodig dan testen alleen. Zo is het voor de ontwikkelaar van een applicatie cruciaal om te weten voor welk doel een applicatie gebruikt gaat worden en welke eisen er aan de applicatie of onderdelen ervan gesteld gaan worden alvorens hij of zij een begin kan maken met de bouw ervan. Natuurlijk is er ook een gezonde dosis vakkennis noodzakelijk: we laten tenslotte ook niet de makers van ons nieuwe huis hun vak tijdens de bouw leren.

Of je het nu hebt over auto's, huizen of software, in alle gevallen is het goedkoper om al vóór de oplevering te praten over kwaliteit dan pas na het betalen van de laatste factuur. Toch gaat dit in de praktijk van de softwareontwikkeling nogal eens anders. Onder het mom van 'RAD' en 'hierop een variant' en 'als je alles op papier moet zetten dan zijn we zo een jaar verder' monden projecten veelal uit in meerjarige processen die van wijzigingsverzoeken aan elkaar hangen. Een bewuste keuze?

In de autoindustrie is het gebruikelijk om te kijken naar de meest uiteenlopende situaties waarin een auto kan belanden. Zelfs het hypothetisch treffen met een eland kan grote gevolgen hebben voor de uitrusting en productie van een auto. Als we dit herleiden naar software mag het duidelijk zijn dat zelfs het vooruitkijken naar een eeuwwisseling al vaak niet meer tot de horizon van softwareontwikkeling heeft behoord. Wat mij betreft is dit een slechte zaak.

Softwareontwikkelaars zijn geen tovenaars maar vakmensen die met hún hamer en troffel om kunnen gaan. Ze hebben echter wel opdrachten nodig. Analoog aan de huizenbouw is het niet voldoende om alleen een stuk grond aan de metselaars aan te wijzen en na een jaar een acceptatietest op het huis uit te voeren. In negen van de tien gevallen zullen er dan nog heel wat wijzigingsverzoeken ingewilligd moeten worden, uiteraard tegen meerprijs.

Kwaliteit kost veel geld, dat is duidelijk. Met testen kunnen we vaststellen of een product zijn geld waard is. Maar hoe kunnen we de kwaliteit van een product van te voren vaststellen?

Eén van de mogelijkheden om risico's te vermijden is het gebruik van proven technology, in de auto- en huizenindustrie een bekend gegeven. Zo zal een autofabrikant het liefst zijn nieuwste creaties baseren op onderstel en motor van een succesvolle auto en zal een aannemer zo veel mogelijk gebruik maken van bekende fundering- en bouwtechnieken.

Om terug te keren naar het testen door de ontwikkelaars: natuurlijk zal iedere vakman zijn best doen om kwalitatief hoogwaardig werk af te leveren. Het is echter de opdrachtgever (of consument zo u wilt) die het eerste én laatste woord over kwaliteit moet hebben. Het éérste woord om aan te geven wat nu precíes de wensen zijn en wat hiervoor betaald zal worden en het láátste woord om aan te geven of aan de eerdere eisen is voldaan. Vermits de vakmensen bekwaam en gemotiveerd zijn en het eerste en laatste woord convergent zijn dan kunnen er hoogstens nog wat 'gewone' fouten gemaakt worden.

Daar zijn we mensen voor.

Kwaliteit, met andere woorden, is een keuze. De keuze om uw eisen en wensen mee te laten spelen in de softwareontwikkeling, de keuze om gebruik te maken van proven technology en de keuze om een product niet eerder te accepteren dan dat het aan uw eisen voldoet. Dit alles is geen garantie dat de kleur van de dakpannen van uw nieuwe huis in de praktijk niet anders uitvalt dan op papier staat, maar het maakt de discussie erover met de aannemer wel een stuk eenvoudiger.