In de afgelopen jaren ben ik twee verschillende manieren van het testen van een datawarehouse tegengekomen.
De ene methode test bij elke wijziging het volledige datawarehouse en de andere test op basis van de componenten die gewijzigd zijn.
Nu vraag ik mij af waarom dit zo is. Als ik winterbanden onder mijn auto laat zetten, zal de garage niet opnieuw ook de motor etc testen. Toch ga je wel een testritje maken, waarin je, voor mij onbewust, ook de rest van de auto test.
Welke methodes heb ik gezien.
De eerste is dat bij elke wijziging het hele datawarehouse wordt getest. Dit werd gedaan door een aparte testafdeling, die meerdere projecten en systemen test. Hierbij wordt uitgegaan dat elke wijziging een domino effect zou kunnen hebben.
Bij de tweede methodiek werden alleen die componenten getest, waarbij door de business analyst werd aangegeven dat die geraakt zouden worden. Niet het gehele datawarehouse werd hierdoor getest. Dit werd gedaan door een klein testteam, wat nauw betrokken was bij het ontwikkelen van het datawarehouse.
Is het nu zo dat als de testers in het project betrokken zijn, de functionele kennis hoger is van de inhoud en ze hierdoor meer vertrouwen hebben in het op componenten testen? En is het dan ook zo dat aparte testafdelingen beter zijn gespecialiseerd in het testen, maar minder in de functionaliteiten van alle systemen, dat het volledig testen van het datawarehouse hun voorkeur geniet?
Wat is jullie ervaring hiermee?
Als BA ben ik op dit moment eveneens betrokken bij het testen (coordinatie/aansturing van het testteam) van een data warehouse oplossing.Ik denk dat er inderdaad een duidelijk verschil is tussen het testen door een testafdeling (wellicht aan de andere kant van de oceaan) en testers, welke onderdeel zijn van het projectteam. De eerste testers zien het totale data warehouse als een blackbox, “als ik er iets instop, moet er iets uitkomen dat ik verwacht”. Men heeft geen context informatie en kan dus ook niet op onderdelen beoordelen of het correct is wat er gebeurt. Dit vraagt om een duidelijke input – expected output aanpak. Deze testers moeten duidelijk weten wat erin gaat en wat er verwacht wordt uit te komen.Aan de andere kant zijn er de testers binnen een project. Deze hebben ook te maken met het BLACKBOX principe, echter kunnen veel beter ZELF bepalen wat de input en verwachte output is. Hierdoor lijken deze testers zelfstandiger, echter er zit wel degelijk een nadeel m.i.Door alleen componenten te testen moet óf duidelijk zijn dat dit component geen afhankelijkheden heeft met de omgeving óf deze effecten moeten in een andere test worden vastgesteld…Als ik kijk naar de twee methoden die worden gehanteerd hier, zien ik een tweetal stappen in het gehele testproces (V-model). Ik ben dus van mening dat beide noodzakelijk zijn voor een goede kwalitatieve borging van de opgeleverde componenten. Feit blijft dat wanneer een data warehouse wordt opgezet volgens een metadata gestuurde aanpak, waarbij code op basis van instellingen en metadata wordt aangemaakt, de tweede methodiek component testen, wel meer mogelijk lijkt.De processen ansich wijzigen niet (MOTOR / AUTO), maar de verschillende componenten kunnen wel bijdragen aan het goed / fout functioneren van het totaal. WINTERBANDEN hebben een bepaald doel, betere grip tijdens de wintermaanden. Maar ze bieden net als de ZOMERBANDEN, de mogelijkheid om de auto te laten rijden. Deze functie, rijden, mag niet wijzigen bij deze componenten wisseling / implementatie, en zal dus ook minder diepgaande tests hoeven te ondergaan.Tot zover mijn 2 cents van wijsheid…
Antwoord:Als ik de vraagstelling juist heb begrepen stel je jezelf een drietal vragen:1. Mening over het telkens volledige Data warehouse (DWH) testen2. Mening over het alleen testen van gewijzigde componenten 3. Consequenties van wel of niet betrekken van testers in een projectVraag 1Het volledige DWH telkens testen is geen noodzaak. Dat doe je eigenlijk alleen de eerste keer wanneer de eerste componenten van het DWH worden opgeleverd. Het complete Extract, Transform en Laadproces (ETL) zal moeten worden getest; met andere woorden als een white box test. Wanneer je de validiteit van data in een rapport gaat testen dan kun je dit wel als een black box testen. Echter het is nooit of/of maar en/en.Vraag 2Wanneer je op een bestaand DWH wijzigingen gaat aanbrengen of functionaliteit gaat toevoegen dan zul je de wijzigingen moeten testen, maar ook de eerder gebouwde componenten, die geraakt zullen worden door deze wijzigingen of aanvullingen zullen moeten worden getest. Je moet kunnen beoordelen of datgene dat eerst goed werkte nu ook nog steeds werkt nu er aanpassingen zijn gedaan.Ook hier is het niet voldoende om alleen als een black box te testen. Je zult ook hier het ETL proces moeten testen.?Vraag 3Als testers in het project betrokken zijn dan zal hun functionele kennis zeker hoger zijn van de inhoud, alleen zal dit nooit, en mag dit ook geen garantie geven dat ze dan meer vertrouwen hebben in het alleen op componenten testen.Mijn persoonlijke ervaring dat een testafdeling niet altijd beter gespecialiseerd is in het testen. Testen van BI c.q. DWH is een vak apart en testafdelingen zijn nog steeds te veel geconcentreerd op het traditioneel testen (transactionele systemen).Echter: gebruik testers die in ieder geval enige kennis hebben van de technologie (ze moeten tenminste kennis hebben van DWH-begrippen) en goede kennis hebben over het bedrijf of het bronsysteem.Belangrijke aandachtspunten (ook wel valkuilen) bij het testen van een DWH:- Het testen van een BI/DWH is net als de bouw ervan een iteratief proces.- Data issues zijn de grootste problemen die aan het licht komen tijdens testen van het ETL proces en het oplossen van deze problemen kan veel tijd kosten.- Maak gebruik van data sets uit productie voor alle testen.- Als ‘echte’ data niet beschikbaar is, dan moet de implementatie van het data warehouse worden uitgesteld. Het testen met productie data is zo belangrijk.- Betrek gebruikers vanuit het bedrijf bij het testen van het DWH. Eindgebruikers zijn de reden waarom een DWH bestaat. Zij zullen de rapporten uit het DWH pas vertrouwen wanneer zij er zeker van zijn dat deze rapporten hun dezelfde of zelfs betere informatie verschaffen.En zo zijn er nog wel wat valkuilen te noemen.Erik FransenAnita van BergenhenegouwenCentennium BI Expertisehuis
Hallo Eva,Jouw blog bijdrage focust op de situatie dat er een verandering in het data warehouse plaats vindt. Het hele systeem is dus al een keer getest, en de speficaties/ het te behalen serviceniveau zijn reeds vastgesteld. Cruciaal bij het bepalen van de te hanteren testmethode is dan natuurlijk of is vast te stellen welke componenten zijn gewijzigd, en of bekend is welke componenten hiermee samenhangen (in termen van afhankelijkheden). Een tweede cruciale variabele in de besluitvorming is de grootte/complexiteit van het te testen systeem en de beschikbare testcapaciteit (in termen van tijd/budget/resources).Een datawarehouse zou moeten worden opgezet volgens het systeemprincipe van maximale samenhang binnen een component, en minimale afhankelijkheid van andere componenten. Idealiter wordt dit ook ondersteund door aanwezigheid van versiebeheer / configuratie management op het dwh. Alleen dan is een goede component-test uitvoerbaar. Echter, een systeemtest blijft altijd noodzakelijk vanuit technisch perspectief. Er kunnen altijd sitatuaties optreden waarin bepaalde systeemgrenzen worden overschreden (rijlengte van de tabel wordt groter waardoor fragmentatie optreedt, er wordt net iets meer intern geheugen gebruikt, waardoor plotsling swapping gaat optreden, etc.). Deze overschrijding kan altijd systeemimpact hebben. Het besluit van wel of niet een systeemtest moet in dit geval worden op basis van de volgende criteria:1) Impact/risico van de gedane wijziging2) Urgentie van de wijziging3) Kosten van de systeemtest4) Kan een (performance) probleem in productie alsnog worden opgelost, of mag het absoluut niet in een productie-situatie optreden.