Artikel

Aandachtspunten bij datawarehouse testing

tijd versus kwaliteit

Eigenlijk gaan we er altijd vanuit dat opgeleverde systemen en de informatie erin te vertrouwen zijn. Idealiter is het systeem getest en zijn de risico’s en mogelijke afwijkingen in informatie bekend. Met andere woorden: we vertrouwen erop dat we in financiële rapportages niet ineens een afwijking van 30 miljoen euro zullen vinden. Onderzoek van Information World Review bevestigt onze behoefte aan datakwaliteit; bijna 90% van organisaties wereldwijd is van mening dat datakwaliteit zeer belangrijk en waardevol is voor hun onderneming.

Idealiter is een informatievoorzieningssysteem opgeleverd en dus te vertrouwen. In een ideale situatie heeft de organisatie een beeld van de kwaliteit van het datawarehouse en van de kwaliteit van de data in het datawarehouse en is de data voor 100 procent getest. De auditafdeling heeft de testresultaten bekeken en de risico’s in kaart gebracht en er is een audit trail opgesteld van alle testresultaten. Met andere woorden: alle uitgevoerde testen en de bijbehorende resultaten zijn transparant. Verder heeft de projectorganisatie ervoor gezorgd dat het testproces ‘lean’ is ingericht en wijzigingen en defects snel opnieuw te testen zijn. De resultaten van deze testen zijn te vergelijken met de vorige testresultaten. De projectorganisatie en de beheerafdeling hebben ervoor gezorgd dat deze testwerkwijze overdraagbaar is naar de beheerfase.

Een ideale situatie met betrekking tot de informatievoorziening is voor veel organisaties nog een streven en geen status quo. Bovendien geldt dat als informatie goed gebruikt wordt een datawarehouse-omgeving nooit af is. De informatiebehoefte binnen een organisatie wijzigt immers continue. In het ideale plaatje zijn er dan ook altijd testers met specifieke kennis van business intelligence en datawarehouses beschikbaar die de omgeving continu kunnen monitoren en beheren.

Voor het ontwerpen van een datawarehouse geldt vaak het advies ‘denk groot, maar begin klein’. Voor het testproces van een datawarehouse geldt eigenlijk hetzelfde. Een testproces moet immers mee kunnen groeien met de groei van een datawarehouse. Tijdens deze groei is het belangrijk het testproces voortdurend te evalueren en te verbeteren. Het testproces krijgt tijdens de groei te maken met meerdere testers, een inrichting van de beheerafdeling en incrementele opleveringen van het datawarehouse. Allemaal zaken die het testproces zodanig kunnen beïnvloeden dat er vertraging of verstoring optreedt. En bij het streven naar optimale datakwaliteit is dat uiteraard niet wenselijk.

Aandachtspunten
Uit een evaluatie van het testproces van datawarehouses, uitgevoerd door onderzoekers van Kadenza, kwamen een zestal punten naar voren die er in meer of mindere mate voor zorgen dat vertragingen of verstoringen ontstaan. Deze aandachtspunten zitten niet in de kwaliteit of de nauwkeurigheid van het opgeleverde datawarehouse, maar hangen vooral nauw samen met de gevolgen van de groei van een datawarehouse en de hoeveelheid extra tijd die dat in beslag neemt.

1. Onvolledige testbasis
In de evaluatie is ook de testbasis nader bekeken. In deze testbasis ontbreekt het eigenlijk veelal aan technische ontwerpen. De kwaliteit van de onderdelen die wel aanwezig zijn, zoals requirements, functioneel ontwerpen en bouwconventies, is erg hoog. De borging van de requirements en de functioneel ontwerpen binnen de test kunnen echter wel verbeterd worden.

2. Complexe controles
De voorbereiding van een systeemtest van een datawarehouse-increment neemt veel tijd in beslag. Het samenstellen van controle queries in het bijzonder is erg tijdrovend. De complexiteit van de controles neemt bovendien toe naar mate er aan de geïntegreerde datawarehouse-omgeving voortdurend incrementen worden aangebouwd.

3. Toename doorlooptijd regressietest
Door de groei van het aantal incrementen neemt vervolgens de doorlooptijd van de regressietest toe. De combinatie van incrementele opleveringen aan een geïntegreerde datawarehouse area-laag en een data marts-laag zorgt ervoor dat bestaande ETL-processen bij een nieuw increment gewijzigd kunnen zijn, waardoor er weer opnieuw een regressietest uitgevoerd moet worden.

4. Gebrek samenhang tussen oplevering en testscripts
Derde aandachtspunt is dat er geen goede correlatie is tussen opleveringen en testscripts. Hierdoor is het voor anderen dan de tester niet inzichtelijk welke versie van een testscript een bepaald testresultaat heeft opgeleverd en op welke oplevering dit testresultaat betrekking heeft. Bovendien zijn de testscripts en testresultaten niet centraal toegankelijk. Hierdoor is hergebruik van de testscripts door andere testers erg lastig.

5. Te weinig kruisbestuiving
Het gebrek aan voldoende testkennis bij ontwikkelaars en voldoende ontwikkelkennis bij de testers is een vierde knelpunt. Hierdoor wordt kennis van ontwikkelaars te weinig gebruikt bij het maken van testscripts en worden testscripts van opgeleverde incrementen niet gebruikt tijdens de ontwikkelfase voor controle doeleinden.

6. Onvolledige testsets
Het zesde en laatste struikelblok is tijd. Door de werkdruk is het moeilijk om de bij het project behorende testset up to date te houden. Verder is gekeken waar tijdwinst te maken is. Zo is geconstateerd dat in het project bevindingen in de opgeleverde datastructuren meer werk en vertragingen in doorlooptijd tot gevolg hebben dan bevindingen in de ETL-processen. Denk bijvoorbeeld aan het ontbreken van verplichtstellen van een veld in een datastructuur. Deze zijn snel te herstellen, maar hebben een grote impact op de doorlooptijd van het testproces, doordat hierbij de testset in de testomgeving vaak opnieuw opgebouwd moet worden.

Plan van aanpak
Inzicht in de aandachtspunten bij datawarehouse testing, geeft handvatten voor het opstellen van een testmethodiek. In feite komt dit neer op twee verbeterpunten voor het testproces: het verbeteren van de kwaliteit van requirements en het verbeteren van de systeemtest. Een kort en krachtig plan van aanpak biedt houvast.

Kwaliteit verbeteren door verbeteren testbasis
Om tot verhoging van de kwaliteit van de requirements en de functioneel ontwerpen te komen, dienen een aantal verbeteringen te worden doorgevoerd. Naast brainstormsessies waarin ontwerpers een overall functioneel ontwerp in grote lijnen opstellen, zijn er plenaire reviews nodig van functioneel ontwerpen per datawarehouse-increment met ontwikkelaars, testers, beheer en de business om het ontwerp op alle aspecten te beoordelen. Hierbij kan gebruik gemaakt van user stories.

Documentatie
De functioneel ontwerp-documentatie dient zo opgezet te zijn dat deze een ingang heeft per datawarehouse-increment voor projectdoeleinden, plus een ingang voor het overall datawarehouse functioneel ontwerp voor beheerdoeleinden. Ten behoeve van transparantie kunnen er verwijzingen (CMMI compliant) in de functioneel ontwerpen worden opgenomen naar op te lossen requirements. Daarnaast moeten er ten behoeve van de ondersteuning bij testdefinities beschrijvingen van functionele controletellingen in de functioneel ontwerpen worden opgenomen. Door gebruik te maken van templates ontstaat er een eenduidige manier om de functionele ontwerpen ook daadwerkelijk vast te leggen.

Door deze maatregelen zal de kwaliteit van de testdefinities en de testscripts omhoog gaan en neemt de doorlooptijd van het maken van testdefinities af. De verbeteringen zijn daarnaast leuk om uit te voeren, zodat ze de betrokkenheid en samenwerking van alle deelnemers verhogen. En passant zorgen ze ook nog voor een beter acceptatie.

Unittests
Hoe hoger de kwaliteit van de input des te hoger is de kwaliteit van de output’. Deze filosofie kan worden vertaald naar de unittest. Met name de correctheid en compleetheid ten aanzien van datastructuren en bouwconventies zijn cruciaal voor een goede unittest. Door zo compleet en correct mogelijk te werken worden fouten in de ontwikkelingsfase eerder geconstateerd en opgepakt, wat leidt tot een vermindering van het aantal bevindingen in de systeemtest. Voorbeelden van activiteiten waarmee veel tijdwinst te behalen is, zijn: het zorgen voor correcte naamgeving van objecten en de correcte implementatie van data-objecten.

Goed uitvoeren van de unittest vereist discipline van de betrokkenen, ook bij grote tijdsdruk. De tijd die besteed wordt aan unittesten wordt dubbel en dwars terugverdiend op de doorlooptijd van het systeemtesten. Een neveneffect is dat er meer aandacht is voor functionele testresultaten.

Verbeteringen systeemtest door testmethodiek en -applicatie
Door het testproces te ondersteunen met een testapplicatie wordt er allereerst voor gezorgd dat testresultaten opgeslagen worden in de testapplicatie. Dit zorgt voor beter zichtbare testresultaten (transparantie) en de hieruit te trekken lessen zullen duidelijker naar voren komen. Door gebruik te maken van herbruikbare rapporten op de test-metadata kunnen testrapportages bovendien sneller opgeleverd worden. Ten tweede maakt de inzet van een testapplicatie hergebruik van testscripts mogelijk. Door de opgestelde testen of controles op te slaan in de testapplicatie kunnen deze bij volgende opleveringen van datawarehouse-incrementen hergebruikt worden als onderdeel van een regressietest. Dit zorgt voor een betere garantie van de betrouwbaarheid en de kwaliteit. Verder zal, met opgeslagen testresultaten op zowel hoog als laag detailniveau, het voor zowel de testers als voor datawarehousebeheer duidelijk zijn hoe de datawarehouseprocessen zich gedragen.

Start met juiste methodiek
Automatisch testen begint met de juiste methodiek. In de juiste benadering wordt zoveel mogelijk gelijke tred gehouden met het datawarehouse ontwikkelproces, waarbij zoveel mogelijk stappen en tests geautomatiseerd zijn. Doel is het testproces zo effectief mogelijk te maken door de preventie van defects en optimalisatie van de testuitvoering. De op de TMAP gebaseerde testmethodiek biedt hiervoor een ideaal raamwerk. Dit raamwerk en bijbehorende templates kunnen vervolgens worden afgestemd op de bedrijfsspecifieke situatie. De volledig ingerichte testomgeving is tijdens de hele looptijd van een data warehouse te gebruiken. Ook tijdens de beheerfase. Overigens is in een Agile project aanpak automatisch testen onmisbaar.

Onderdeel Ondersteuning
Master Testplan data warehouse Document Template 
Detail Testplan data warehouse Document Template
Testcases in 11 testcategorien Generatie Templates
Review requirements Methodiek
Review Unittest Methodiek
Review data warehouse architectuur Methodiek
Review Standaarden Methodiek
Dashboards Excel Template

Tabel 1. Methodiek testaanpak

Meer weten over het concretiseren van de methodiek en geautomatiseerd testen, lees het tweede artikel over geautomatiseerd testen van datawarehouses.
 

Categorie:   
Auteur(s)
afbeelding van mariannekadenza
Marianne Kompagne
MN - Senior DWH/BI Architect/Requirement engineer

Marianne Kompagne is Business Intelligence/Datawarehouse architect/Requirement engineer bij MN. Naast haar kennis op het gebied van DWH- en Enterprise architectuur, data modelling en datakwaliteit heeft Marianne veel ervaring binnen Solvency II projecten. Specifieke DWH omgevingen die hoge eisen stellen aan de betrouwbaarheid en kwaliteit van informatie. Bij Kadenza is Marianne medeverantwoordelijk geweest voor het opstellen en geven van interne Masterclasses (DWH en BI) en de DWH Test Methodiek. Binnen MN is Marianne verantwoordelijk voor o.a. requirement engineering van DWH/BI projecten.

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.