Snel snel snel! – De invloed van agile op testen

Veel organisaties zijn al overgegaan van Prince2 op meer agile ontwikkelmethodes. Nog veel meer organisaties staan op het punt om deze transitie te maken. Als het over agile ontwikkelen gaat, dan gaat het vaak over het ontwikkeldeel. Maar wat is nu eigenlijk de invloed van agile en scrum op testen? En nog specifieker: op testdata?

Agile software ontwikkelen betekent dat vaker kleine stukjes software worden opgeleverd. ‘Vaker’ betekent meestal ergens tussen de 2 en 4 weken. Binnen agile wordt deze periode 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.

Anders testen
Om dit te kunnen waarmaken moet een organisatie anders gaan testen. Geautomatiseerd testen is daarom de norm, simpelweg omdat de tijd ontbreekt om de vereiste testcoverage te halen met handmatig testen. Ook test driven development is een vaak gebruikte methode binnen agile organisaties.

Testscenario & -data
Maar de kwaliteit van een test staat of valt met het testscenario en met de data die je gebruikt. Een goede test met slechte (lees niet representatieve) testdata zegt niets over de kwaliteit van de software. Omgekeerd geldt het uiteraard ook, een slecht uitgedacht testscenario met goede testdata is nog steeds een slecht testscenario.

Testdata op afroep
Als je agile gaat ontwikkelen, moet je dus niet alleen slimmer ontwikkelen, betere testscenario’s opstellen en test automatiseren. Je moet ook tijd en aandacht besteden aan de testdata. De vertaling van het logische testgeval naar een fysieke testcase is vaak de crux. Hoe zorg je dat je deze vertaling snel genoeg kunt maken? De sprint duurt immers maar 2 tot 4 weken, dus testdata moet bijna op afroep beschikbaar zijn. Daarnaast moet deze testdata representatief zijn, anders is de test bij voorbaat waardeloos.

Zelf maken?
Tot nu toe creëerden veel organisaties zelf hun testdata of ze gebruikten data uit productie. De eerste methode is in een agile organisatie slecht houdbaar omdat het te lang duurt. 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…)?

Productiedata gebruiken?
En de tweede methode dan? Data uit productie is 100 procent representatief voor de productiesituatie. Maar dit stuit op grote problemen vanuit de privacywetgeving. Sinds 1 januari 2016 is een organisatie bijvoorbeeld verplicht om een datalek te melden. Data uit productie gebruiken in een testomgeving vergroot de kans op een datalek aanzienlijk. De consequenties van een datalek zijn pittig: boetes tot 820.000 euro, reputatieschade, et cetera. Daarnaast staat de wetgeving gebruik van persoonsgegevens in een testomgeving niet toe. Als organisatie heb je deze gegevens gekregen voor het leveren van het product of dienst. Testen valt daar normaal gesproken niet onder.

Wat is het alternatief dan?
Bij veel organisaties die al langer agile ontwikkelen, zie je dat zij gebruik zijn gaan maken van geanonimiseerde data uit productie. Deze data wordt zo bewerkt dat hij niet meer herleidbaar is naar een natuurlijk persoon. Hiermee heb je feitelijk het beste uit twee werelden: de data is representatief én je voldoet aan de privacywetgeving. 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.

Druk op de knop
Om goed aan te sluiten bij een agile organisatie is het natuurlijk wel belangrijk dat de oplossing om data te anonimiseren volledige geautomatiseerd en snel werkt. Alleen dan kun je er voor zorgen dat elk ontwikkelteam bijna met een druk op de knop kan beschikken over representatieve testdata.

Profiteren
Door technologische vernieuwingen kost het tegenwoordig steeds minder tijd om een dergelijke oplossing te implementeren. Zeker bij organisaties die hun datamodel goed kennen, is het eerder een kwestie van dagen dan van weken voordat een eerste iteratie werkend is en de teams profiteren van goede testdata.

Bekijk hier DataFactory voor het representatief testen van je data