Testen kost geld. Hoe testen we business intelligence zo efficiënt mogelijk?
Toen bij een opdrachtgever onlangs de BI-projectorganisatie opnieuw werd opgezet, heb ik ook de aanpak voor BI-testen tegen in het licht gehouden. Nu was deze opdrachtgever een hele grote organisatie, met een forse BI-organisatie en allerlei bestaande best practices, waaraan niet te tornen viel. Op basis van de bestaande ontwikkelmethodiek werd er een aanpak voor het testen uitgekiend die zo efficiënt mogelijk was. Dit alles bleek sterk afhankelijk van de bestaande ict-organisatie en de afgesproken methoden en technieken waarmee het datawarehouse en de rapportage werden ontwikkeld. Het resultaat werkte naar tevredenheid, maar het was maatwerk.
Wat voor de ene organisatie goed werkt, is voor de volgende organisatie niet goed bruikbaar. In het algemeen wil je een vaste aanpak hanteren voor het uitvoeren van projecten, met aandacht voor standaardisatie en efficiency, zodat je zo goedkoop en betrouwbaar mogelijk je projectdoelen haalt. Voor datawarehouseprojecten werk ik bij mijn klanten daarom graag met een standaard datavault-architectuur, een daarop afgestemde vaste ontwikkelmethodiek (inclusief prototyping) en een aansluitende generator voor datamodellen en ETL om het ontwikkelproces efficiënter te maken.
Testen is een optimalisatieproces, je kunt in theorie oneindig doorgaan met iets te testen. Functionaliteit, robuustheid, performance van software (ETL en rapporten) en datakwaliteit zijn allemaal noodzakelijk om te testen in de BI. Vooral bij het laatste topic zijn de variaties oneindig, want een datawarehouse is deels zelf een testsysteem. Maar idealiter test je zo weinig mogelijk, het kost geld.
Een duidelijk V-model (ontwerp vs. test) en zoveel mogelijk standaardisatie kan het testwerk beperken. Dus genereren we zoveel mogelijk ETL (inclusief gestandaardiseerde foutafhandeling van incorrecte of inconsistente brondata) in plaats van te bouwen, om de noodzakelijke tests te beperken. De voor business rules handmatig gebouwde ETL moet altijd volledig worden getest, maar dat kan soms automatisch met generatoren voor testware. Performance testen laat ik voor deze discussie buiten beschouwing. Dan blijven er over 1) de noodzakelijke kwaliteits- en consistentiechecks over de opgeslagen historische data en 2) de functionele en technische tests voor de rapportage. Voor deze laatste twee topics hou ik me aanbevolen voor tips om de hoogste graad van efficiency te bereiken. Hoe maken we het plaatje compleet?
Robert,
Interessant onderwerp. Er is veel denkwerk verricht en realisatie gedaan op het gebied van testen als het gaat om pure software engineering (Java, C++, etc.), maar voor BI specifieke zaken als ETL en rapportages staan we nog aan het begin.
Je spreekt over testen voor de voor business rules handmatig gebouwde ETL, en mogelijke aansluiting hierop met generatoren voor testware.
Is dat ook niet bruikbaar voor de functionele tests voor de rapportage? Immers, als de output van rapportage voorhanden is in puur data formaat, dan lijkt er mij weinig verschil tussen een test op een ETL resultaat en een test op een rapport resultaat.
Of bedoelde je het anders?
En wat zie je als technische test van rapportage? Het eventueel herhaald opvragen van een rapport?
Meer dan bij testen op OLTP systemen zie ik ook een belangrijke kwaliteitsverbetering binnen de BI wereld mogelijk als het gaat om regressietesten: als er een detail wordt aangepast tbv 1 rapport, hoeveel van het bestaande (ETL, rapportage) blijft dan nog overeind en/of onveranderd qua inhoud. En hoeveel van het testwerk kan simpelweg met een druk op de knop worden herhaald.
Wat zie jij daarvan terug in de praktijk?
Groeten, Richard Kooijman.
White-box testing op basis van dynamisch gegenereerde zogenaamde testbeacons versnelt het testproces enorm. Daarnaast kun je rekenregel georienteerd testen d.m.v. het geavanceerde repository systeem. Ik heb daar goede ervaringen over gehoord en gelezen (google Don Fowler en zijn artikelen over het G4 solution platform). De G4-producten zijn nota bene (conversie, Repository, analyzer, WBT) van Nederlandse bodem. Helaas dus wel “invented here”.