Aanpak unit-test binnen

een Agile BI-project

Door: Abdel L’Ghdas

Aanpak unit-test binnen een Agile BI-project

Pg, 2

Dit artikel is onderdeel van de themareeks BI & Techniek, bedoeld om de meer technische

aspecten van BI voor het voetlicht te krijgen. Het is geschreven voor project-managers en

ontwikkelaars binnen de BI, die zich afvragen hoe agile zich in de BI-praktijk staande houdt.

Er is al veel geschreven over de aanpak van testen binnen Agile BI-projecten. Maar dat is

theorie, in de praktijk blijkt testen toch een lastig onderwerp, waardoor het testtraject vaak een

ondergeschoven kindje binnen het project wordt. Dit blog beschrijft een aanpak om de

voorbereiding - die altijd voorafgaat aan het functioneel testen - zo veel mogelijk te beperken en

toch een adequate, automatische unit-test uit te kunnen voeren. Het doel is om uiteindelijk

meer moeite en tijd te kunnen stoppen in het testen zelf en niet in de voorbereiding (en het

automatiseren) ervan. De aanpak die ik hier beschrijf vloeit uit eerdere eigen ervaringen binnen

verschillende Agile BI-projecten.

Aanpak unit-test binnen een Agile BI-project

Pg, 3

Probleem

In de praktijk wordt een testtraject binnen Agile BI-projecten vaak als tijdrovend ervaren. We

moeten immers testdata genereren die afdoende alle mogelijke paden en scenario’s afdekt. Alle

voorkomens van data, hoe die data zich gedraagt binnen de opgestelde omgeving en welke

resulterende foutpaden kunnen worden bewandeld, moeten worden geïnventariseerd om ze te

kunnen toetsen. Lastig hierbij is het verkrijgen van een testset die representatief is. Uit

praktische overwegingen gaat men veelal uit van een tot vijf procent van de productiedata, maar

een dergelijke set hoeft lang niet alle gewenste testsituaties te bevatten. In een Agile BI-traject

is testen en vooral regressietesten een serieus aan te pakken onderwerp. Bij de bouw van

nieuwe software loopt alles immers nog lekker vlotjes, maar na een paar increments gaat

regressietesten steeds meer moeite en tijd kosten, waarbij de tijdsgrenzen van de twee-

wekelijkse cyclus je al snel parten gaat spelen.

Aanpak unit-test binnen een Agile BI-project

Pg, 4

Investeer in een flexibele, gedegen testset

Even los van privacy-eisen, is het vaak een goede en pragmatische oplossing om een set vanuit

productie te kopiëren en beschikbaar te stellen. Vooraf moet je dan wel een analyse doen om te

bepalen welke data vaak voorkomt in productie. Zo kan men bepalen welke waarden vaak

voorkomen en welke uitzonderingen er zijn. Die analyse kun je met behulp van profiling tools

en/of queries uitvoeren. Profiling tools zijn natuurlijk een stuk sneller en overzichtelijker, maar

soms ook wat duur en niet altijd beschikbaar. Uit de resultaten van de analyse selecteer je een

gevarieerde set die zo representatief is dat alle voorkomende situaties gedekt zijn. Verder kun je

deze testset aanvullen met eigen testsets waarmee je (vanuit de logica van de software

afgeleide) mogelijk voorkomende foutpaden en/of uitzonderingssituaties afdekt. Hierbij is ook de

interactie met de gebruikers belangrijk die de verwerkingslogica vaak functioneel goed kennen.

De startset wordt dan iedere keer bijgehouden zodra nieuwe onvoorziene gevallen ontdekt

worden.

Aanpak unit-test binnen een Agile BI-project

Pg, 5

Hou hierbij rekening met de doorlooptijd en beheerbaarheid van de testsets. De testsets moeten

snel geladen kunnen worden, het uitvoeren van de test moet snel lopen en de testset moet

makkelijk uit te breiden zijn. Dit is een incrementeel proces. Dus bij iedere nieuwe functionaliteit

dient de testset uitgebreid te worden met testgevallen.

Vanuit eigen ervaring is dit proces goed haalbaar en uiteindelijk minder arbeidsintensief. Als je

hierin investeert aan het begin van een project (zoals in Sprint 0 bij Scrum) kun je er alleen

maar profijt van hebben. Het is echter wel noodzakelijk om dit bij het begin van een traject op

te pakken, anders blijkt het vaak lastig om alles later nog eens in te halen. Hoe langer je dit

uitstelt, hoe groter de inhaalslag is. In Scrum termen kan men dan op een gegeven moment

spreken van een epic aan testactiviteiten.

Investeer in automatisch testen

Door het incrementele karakter van Agile projecten, zul je vaak regressietests moeten doen.

Daarom is het belangrijk om dit proces te automatiseren. Bij ieder increment investeer je dan

alleen in het aanmaken van testsets voor je nieuwe functionaliteit. Het regressietesten op eerder

Aanpak unit-test binnen een Agile BI-project

Pg, 6

opgeleverde functionaliteit zal daarnaast automatisch moeten gaan lopen. Binnen Agile BI is

automatisch testen in de praktijk dus onmisbaar, maar daarvoor moet je wel vooraf een

automatisch proces inrichten.

Om hier op een pragmatische manier mee om te gaan, wordt vaak een (product-)risico-analyse

uitgevoerd, door impact van en kans op falen te bepalen en met elkaar te vermenigvuldigen om

tot een risico-verwachtingswaarde te komen. Je testaanpak wordt dan bijvoorbeeld 'licht',

'gemiddeld' of 'zwaar', direct afhankelijk van de uitkomst van je risico-analyse. Bij een risico-

verwachtingswaarde ‘licht’ zou je bijvoorbeeld kunnen volstaan met tellingen over een

ontwikkelset. Bij een risico-verwachtingswaarde 'zwaar' kies je dan ook een 'zware' testaanpak,

waarbij bijvoorbeeld alle delen van de geïmplementeerde logica intensief getest moeten worden,

gebruikmakend van een complete en slimme testset gevolgd door een complete vergelijkingstest

op detail-niveau.

Aanpak unit-test binnen een Agile BI-project

Pg, 7

Voorbeeld:

Ik heb een testset in de vorm van een brontabel A. Ik verwacht dat mijn ETL-software vanuit A

een resultaat levert in de vorm van B. Die set kan ik handmatig gaan samenstellen, maar het is

nog sneller om door middel van een SQL query de geïmplementeerde logica na te bootsen in

SQL (i.e. reverse engineering). Deze query levert een verwachte output set B. Mijn te testen

proces levert, vanuit dezelfde brontabel A, de werkelijke output set C. Nu kan ik door middel van

SQL Except bepalen of er verschillen bestaan tussen mijn verwachte output set B en mijn

werkelijke output set C. En dat natuurlijk in twee richtingen: B except C en daarna C except B.

Een lege result-set betekent dan foutvrije software.

Aanpak unit-test binnen een Agile BI-project

Pg, 8

Aanpak unit-test binnen een Agile BI-project

Pg, 9

Wanneer je dit hebt bereikt, heb je al een eerste belangrijke stap gezet naar een pragmatische

maar solide unit-test. Vervolgens gaan we dit automatiseren, zodat iedere keer als we dit proces

draaien de test automatisch opstart. Het resultaat van beide vergelijkingen moet positief zijn (in

dit geval een lege result-set opleveren).

De queries zouden onmiddellijk na het proces geplaatst kunnen worden, bijvoorbeeld in een

stored procedure. Hierdoor start - elke keer als het ETL-proces wordt geraakt- de test

automatisch. Als we een keten hebben ontwikkeld waarin alle componenten met elkaar

verbonden zijn, dan zouden deze tests daarvan onderdeel moeten uitmaken. Het is hier

belangrijk om te onthouden dat een test een bepaalde verwachte output levert en deze

makkelijk geïntegreerd kan worden in het proces voor testdoeleinden.

Het opleveren en uitbreiden van de automatische testset wordt ieder increment vastgesteld en

uitgebreid. Men zou dit kunnen opnemen als acceptatiecriterium of in geval van Scrum als

onderdeel van de Definition Of Done.

Aanpak unit-test binnen een Agile BI-project

Pg, 10

SCRUM-StarterKit

Download hieronder de gratis SCRUM-StarterKit met handige checklists en templates:

Dit blogartikel is geschreven door Abdel L’Ghdas.

Wil je meer informatie? Neem dan een kijkje op ons blog.