Een paar weken geleden e-mailde een oud-projectcollega of ik (of wij bij Conspect) een beeld hebben bij testen in een BI-omgeving. Hij was op zoek naar hoe hij meer grip kon krijgen op het testen van Business Intelligence. In deze blog wil ik enkele praktijkervaringen behandelen.
Definitie van Business Intelligence (BI) is volgens Wikipedia: Business Intelligence (BI) staat voor het verzamelen van informatie binnen de eigen handelsactiviteit. Het kan worden omschreven als het proces van gegevens omzetten in informatie, dat vervolgens zou moeten leiden tot kennis en aanzetten tot adequate actie.
Het testen hiervan kan heel lastig zijn want je kunt kiezen voor een bepaald project/ontwikkel-model gegoten in een T-Map structuur, of voor een Agile-methode, of een mix daarvan.
Hoe te testen hangt een beetje af van wat verwacht wordt van de werkmethodiek in de organisatie. Als alles in een kort tijdschema moet gebeuren kan Agile wenselijk zijn. Anders is een ander project/ontwikkel-model waarbij uitgebreide ontwerp- en testfase en key-users betrokken zijn een goede mogelijkheid. Als de laatste werkmethodiek gemixt wordt met TMap dan krijg je het volgende fases voor de testsoorten ST/FAT/GAT:
Deze fasen van TMap hoeven niet lang te duren zoals vaak wordt gedacht maar kunnen kort cyclisch worden doorlopen in bijvoorbeeld 3 tot 4 weken tijd.
Voor de systeemtesten, een wat meer technische test, is het gebruikelijk om de zwaarte te leggen op het testen van het Extract, Transfer, Load (ETL) proces. Het meest handig om dit in nauwe samenwerking met de ontwikkelaar te testen. Bijvoorbeeld om samen queries te schrijven die aantallen vergelijken tussen de systeembronnen van het datawarehouse en het datawarehouse zelf, en om te kijken of de inhoudelijke wijzigingen die gemaakt waren in de business applicatie goed door kwamen in het datawarehouse database. Als het ETL samenwerkt met een datamart (datamart is een kleinere hoeveelheid aan gegevens en vaak ingericht voor een specifiek doel die periodiek wordt gevuld door middel van een snaphot) of meerdere datamarts dan dient de controle uitgevoerd te worden op aantallen en vergelijkingen.
Het kost veel tijd om dit goed te doen. Maar de keuze om juiste testen in de systeemtest te doen is omdat het testen van de feiten en de inrichting van het datawarehouse-deel en het ETL proces het meest lastig is om later in het project aan te passen. Als in een later stadium nog aanpassingen moeten worden gedaan kan het risico optreden dat er één of meerdere rapporten ook opnieuw gemaakt moeten worden. Ook kan alvast in een systeemtest gekeken worden of het maken van een gedefinieerd rapport binnen de gestelde tijd uitgevoerd kan worden en niet in een time-error terecht komt.
Voor functionele acceptatie testen kan dan meer gekeken worden naar de naamgeving van de velden, de layout (bijvoorbeeld: worden juiste aantal decimalen correct afgerond) en nogmaals een korte check of de getoonde inhoud van het BI-rapport overeenkomt met de inhoud van het bronsysteem. Daarnaast kan er ook getest worden of aanwezige filters, invoeringsbesturingselementen en toegepaste berekeningen correct werken.
In de gebruikersacceptatie testen kan de lay-out nogmaals worden gecontroleerd ook op bruikbaarheid en of de specifieke en vaak gebruikte data in de BI-rapporten correct worden getoond.
Wat belangrijk is dat voor elke (test)omgeving gecontroleerd dient te worden of de gewenste klassen, objecten (lees velden) / filters of invoeringsbesturingselementen / parameters aanwezig zijn, en in de juiste map binnen een Universe worden getoond. Dit is wenselijk omdat niet alles duidelijk beschreven is of vergeten is te verwerken in de opleveringsdocumentatie van de installatie van een Universe.
Het testen van een BI is niet anders dan het testen van bijvoorbeeld een applicatie, website of interface. Als de testen voor de BI goed zijn verlopen levert dit naast een bruikbare rapportage, ook een omgeving met heldere correct ingerichte universes (logische indeling, herleidbare namen, herleidbare en betrouwbare data, gedocumenteerd) waarmee de voor de organisatie gewenste rapportages gemaakt kunnen worden zoals beschreven in de requirements.
Voor deze blog dank voor de deels geleverde input van Menno van Boxtel (werkzaam bij Conspect Quality Management) en de gestelde vraag door Edwin van Hoogwaarden (werkzaam bij Ordina).
Er zijn nog geen reacties
Let op: Uw reactie wordt gepubliceerd. Voor privé-reacties kunt u rechtstreeks mailen met de auteur. Voor contact mogelijkheden bekijk het auteur profiel van Angélique Lesquillier
Angélique haar ambitie is “Leuke projecten doen, waar iedereen blij van wordt!”
Lees Meer in Profiel
© 2010 IMfacts • ICT & InformatieManagement
