Blog

Agile ontwikkeling vereist realistische testdata en slimme data staging

Bij agile systeemontwikkeling is het de bedoeling om in korte sprints van enkele weken applicaties te ontwikkelen, te demonstreren en geaccepteerd te krijgen. In de praktijk worden wel use cases of user stories opgesteld om op basis van de bedrijfswaarde de prioriteit te bepalen van de te maken functionaliteit. Maar zodra het gaat over het opstellen van de bijbehorende test cases en test data, geven de gebruikers en ontwikkelaars vaak niet thuis. Terwijl dit zowel de ontwikkelaars als de gebruikers enorm kan helpen om zich als het ware te identificeren met de applicatie die straks in productie zal gaan.

Realistische testdata
Om testcases voor te bereiden en uit te voeren – maar ook om demo’s uit te voeren en gebruikers te trainen - is het cruciaal dat men over een kwalitatief en kwantitatief goede set testdata beschikt. Kwalitatief goed wil zeggen dat de testdata representatief is voor het gebruik in productie en dat het alle mogelijke varianten bevat, ook de extremen en de exoten. De testdata mag met andere woorden geen beperkende factor zijn voor alle mogelijke testgevallen die zijn op te stellen. Kwantitatief goed betekent dat de testset voldoende volume heeft om ook de performance van het systeem te kunnen testen. Maar hoe kom je nou aan een realistische set testdata? Dat is makkelijker gezegd dan gedaan.

Handmatig invoeren
Eén van de mogelijkheden is om handmatig testdata in te voeren, al dan niet voor een specifiek testgeval. Afgezien van het feit dat dit erg arbeidsintensief is – zeker bij agile ontwikkeling, waar door het werken in sprints soms meerdere keren testdata ingevoerd moet worden – en de kans op fouten groot, weten veel gebruikers in de praktijk niet hoe zij testgevallen op moeten stellen en dus ook niet welke data zij hiervoor nodig hebben. Ontwikkelaars zijn op hun beurt een soort van blind voor hun eigen ontwikkelwerk. Voor hen is het daarom per definitie lastig om objectief en goed te testen. Zolang de testgevallen niet door professionele testers worden opgesteld, is het dan ook lastig om de kwaliteit van de testdata te garanderen. En zelfs in het geval er wel testexperts betrokken zijn, is de kwaliteit van de testdata sterk afhankelijk van het niveau en de ervaring van de testers.

Gemaskeerde productiedata
Een tweede mogelijkheid om aan testdata te komen, is om een kopie van de productiedata te gebruiken en deze te maskeren. Productiedata heeft volume, is representatief en het betreft een snelle oplossing. In de praktijk van systeemontwikkeling komt de data echter lang niet altijd in productie voor. Denk bijvoorbeeld aan nieuwe functionaliteit die nog niet in productie staat, testdata om foutmeldingen te testen of extremen die (nu nog) niet in productie voorkomen en aan het testen van een migratie zonder dat de conversiesoftware al gereed is. Ook beschikken veel organisaties niet over maskerings-tools om de wet bescherming persoonsgegevens goed na te kunnen leven. Bovendien hoeft de hoeveelheid testdata die nodig is om goed te kunnen testen niet even groot te zijn als de hoeveelheid productiedata.

Automatisch genereren
De derde mogelijkheid om tot testdata te komen is het genereren van testdata. Bijvoorbeeld via tools zoals www.generatedata.com. Dit betekent dat testdata ontstaat op basis van specificaties, die overeenkomt met de productiedata en op geen enkele manier kan voorkomen in de productieomgeving. Deze manier van testdata aanmaken, is vergelijkbaar met hoe modelgedreven systemen worden ontwikkeld; het specificeren staat voorop. Het genereren van testdata is niet alleen de meest kosteneffectieve manier, maar biedt ook de beste garanties op een kwalitatief en kwantitatief goede dataset. Het apart specificeren van de testdata is niet altijd eenvoudig, maar voor de rest biedt deze manier om aan testdata te komen eigenlijk alleen maar voordelen. Zo kunnen ook extreme en exotische testgevallen worden gegenereerd, zijn grote volumes aan testdata mogelijk, kan de testdata eenvoudig worden ingeladen via bestanden of SQL-srcipts en kunnen de testdata-specificaties bij Agile-ontwikkeling per sprint mee ‘evolueren’.

Smart data stagen
Een ander aspect van realistische testdata is dat deze beschikbaar moeten zijn in de verschillende Ontwikkel-, Test-, Acceptatie- en Productie-omgevingen voor het uitvoeren van respectievelijk unit testen, systeemtesten, gebruikers- en productieacceptatietesten. Complete databases doorzetten is veelal geen optie of ongewenst door de omvang en privacy-restricties. Met ‘smart datastaging tools’ kan voor een bepaalde applicatiescope de datastructuur worden geanalyseerd en gefilterd om één consistente dataset door te zetten. Dit werkt op vergelijkbare wijze als de DevOps methodiek voor het stagen van applicaties (zie mijn blog over ‘DevOps: de laatste horde voor succesvolle Agile’).

Kortom, het automatisch genereren van testdata leidt tot kwalitatief en kwantitatief goede testdata die met smart data staging tools eenvoudig beschikbaar gemaakt kan worden in de verschillende OTAP-omgevingen. Zo geeft realistische testdata als het ware ‘betekenis’ aan een nieuwe applicatie voor zowel de gebruiker als de ontwikkelaar. En dat is zeker met het oog op de voortgang tijdens de sprints bij agile ontwikkeling erg belangrijk.
 

Deze blog is geschreven door Joachim Vandecasteele. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van JoachimVandecasteele
Joachim Vandecasteele
Anderson MacGyver - Adviseur

Joachim Vandecasteele is adviseur bij Anderson MacGyver heeft een passie voor business innovatie én structurele organisatieverbetering met IT. Anderson MacGyver realiseert meer businesswaarde met IT. Door advies- en managementdiensten vergroot Anderson MacGyver de waarde van IT en informatie voor organisaties. Daarvoor was
hij CTO bij COOLProfs, specialist in het bouwen van bedrijfskritische informatiesystemen op maat op basis van OutSystems en CA Gen modelgedreven RAD-tooling. Vandecasteele was voor zijn tijd bij COOLProfs senior consultant bij KPMG Consulting op het gebied van World Class IT en consultant ISES International op het gebied van CASE-tools voor systeemontwikkeling. Hij heeft verschillende publicaties op zijn naam staan over de toekomst van de IT-organisatie, over strategierealisatie met de balanced scorecard en over maatwerk systeemontwikkeling. Vandecasteele studeerde Bestuurlijke Informatiekunde aan de Katholieke Universiteit Brabant en Bedrijfsinformatica aan de Haagse Hogeschool. Zijn vrije tijd besteedt hij aan zijn gezin, alles volgen wat met IT te maken heeft en triathlons, trails en marathons. Altijd gedreven, scherp en vrolijk!

Twitter: jvandecasteele
Email: joachim.vandecasteele@andersonmacgyver.com

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.