Veel organisaties zijn al van Prince2 overgegaan op meer Agile-ontwikkelmethodes. Nog veel meer organisaties staan op het punt om deze transitie te maken. Daarmee groeit de behoefte aan testdata op afroep. Hoe zorg je als organisatie op een snelle en eenvoudige manier voor representatieve testdata, terwijl je je wel houdt aan de privacy wetgeving?
Agile softwareontwikkelen betekent dat vaker kleine stukjes software worden opgeleverd, meestal in periodes van twee tot vier weken. Zo’n periode wordt een sprint genoemd. Randvoorwaarde is dat de opgeleverde software ‘potentially shipable’ is. Aan het eind van elke sprint moet een stukje software zo ver zijn uitontwikkeld én afgetest dat het in principe in productie kan worden genomen.
Dit vraagt om een andere manier van testen. Geautomatiseerd testen is de norm in Agile-trajecten, omdat je met handmatig testen nooit de vereiste testcoverage haalt. Daarvoor ontbreekt simpelweg de tijd. Ook test driven development is een vaak gebruikte methode in Agile-ontwikkeltrajecten. Daarbij wordt eerst de test opgezet en start daarna pas de ontwikkeling.
Kwaliteitsgarantie
De kwaliteit van een test staat of valt met het testscenario en met de gebruikte data. Een goed scenario met slechte (lees: niet representatieve) testdata zegt niets over de kwaliteit van de software. Omgekeerd geldt hetzelfde: een slecht testscenario met goede testdata levert net zulke onbetrouwbare resultaten op.
Vooral op het vlak van testdata is nog gigantisch veel winst te behalen. De crux zit vaak in de vertaling van het logische testgeval naar een fysieke testcase. Tot nu toe creëerden veel organisaties daarvoor zelf hun testdata of ze gebruikten data uit productie.
In een Agile-traject is het zelf creëren van testdata slecht houdbaar, omdat het gezien de korte sprints te veel tijd in beslag neemt. Bovendien is de representativiteit twijfelachtig. Hoe creëer je bijvoorbeeld een testgeval met historie? En wie denkt eraan testgevallen te maken voor situaties die niet mogen voorkomen in productie (maar dat in de praktijk toch doen…)?
Andere organisaties gebruiken voor hun testcases de eigen productiedata. In een Agile-ontwikkeltraject ideaal vanwege de snelle beschikbaarheid. Kopietje maken en klaar. Maar hier komt – als het tenminste om persoonsgegevens gaat – de privacywetgeving om de hoek kijken. De Wet Bescherming Persoonsgegevens verbiedt het gebruik van klantdata buiten de productieomgeving. Met de Meldplicht Datalekken die op 1 januari 2016 is ingegaan, is de wet nog strenger geworden. De boete op overtreding is niet mals: 820.000 euro. Voor een kleine tot middelgrote organisatie kan dit – nog los van een gedeukte reputatie – de nekslag zijn.
Alternatief
Organisaties die al langer Agile-ontwikkelen, zijn gaandeweg steeds vaker gebruik gaan maken van geanonimiseerde productiedata. Deze data wordt dusdanig bewerkt dat hij niet meer herleidbaar is naar natuurlijke personen. Er zijn verschillende technieken om data te anonimiseren, zoals versleutelen of maskeren. Elke methode heeft zijn eigen voors en tegens en wat het beste is hangt erg af van de situatie.
Op de markt zijn diverse tools verkrijgbaar voor het anonimiseren of pseudonimiseren van data. Sommige tools zijn met één druk op de knop te bedienen. Toch heeft 62 procent van de Nederlandse bedrijven hier nog geen beleid voor, blijkt uit onderzoek van PwC. Met de groeiende populariteit van Agile in combinatie met strengere privacywetten zal daar snel verandering in (moeten) komen. Wie snel én goed nieuwe software wil testen kan er niet meer omheen.
En qua invoeringsstrategie zou ik dan kiezen voor een Agile benadering:
– maak een analyse van welke (productie)data je de komende 6 maanden verwacht nodig te hebben
– anonimiseer de belangrijkste (!) gegevens hier uit
– begin klein en simpel, en laat dit per sprint uitgroeien.
– update je databehoefte met enige regelmaat
In eerste instantie is het voor de hand liggend dat een specialist dit anonimiseert, maar na verloop van tijd zou deze expertise door het team opgepakt moeten kunnen worden (mits ondersteund door tools en procedures). Dan is het gewoon dagelijks werk als onderdeel van de sprint.
Persoonlijk vind ik vanuit een test standpunt dat je niet productiedata moet gebruiken, maar met de nieuwe software zelf de testdata aan maken. Hierdoor breng je al eerder bevindingen aan het licht.
Mocht dat niet mogelijk zijn, dan is productiedata altijd wel een optie. Maar de laatste tijd zijn er ook voldoende (freeware) tools verschenen die je prima kunnen helpen met het juiste volume en inhoud van je testdata. Bijvoorbeeld: http://www.generatedata.com/ en http://www.convertcsv.com/generate-test-data.htm
Maar er zijn ook voldoende professionele en commerciële tools met voldoende ondersteuning beschikbaar.
Daarnaast mis je, in al dan niet aangepaste, productiedata veelal specifieke situaties of volume die je wel wil hebben om bepaalde testen uit te voeren. En dan zal je toch wel specifieke data aan moeten maken. Dit merk ik vaak in de praktijk.
Tevens kan ook het data-driven geautomatiseerd testen helpen met het creëren van testdata.
@Anko: Dank voor je aanvulling. Een agile opzet is wat mij betreft ook zeker zinvol bij het invoeren van een manier om testdata op afroep te realiseren. Door te zorgen dat eerst die data beschikbaar komt waarvan de business value het hoogst is, zorg je voor draagvlak.
Qua inbedding, helemaal eens. Het initieel inrichten is lastig en complex. Maar het dagelijkse gebruik moet ook wat mij betreft zeker bij het team liggen.
@Nico: Het risico van het zelf samenstellen van testdata is dat de niet bedachte situaties niet voorkomen in de testset. De kracht van geanonimiseerde productiedata is dat juist ook onverwachte situaties voorkomen. Situaties die (nog) niet in de productiedata voorkomen kunnen natuurlijk altijd worden toegevoegd aan de geanonimiseerde dataset.
Wat mij betreft zou je daarom als tester per situatie moeten bepalen welke ‘mix’ aan data je gebruikt. In veel gevallen zal dat ook prima een combinatie kunnen zijn van geanonimiseerde productiedata en door de applicatie gegenereere data.