Wat maakt het testen van een Business Intelligence- en Datawarehouse-omgeving anders dan het testen van een applicatie? Hieronder lichten we een paar verschillen -en overeenkomsten- toe.
Bredere Context
Business Intelligence toepassingen, zoals OLAP Queries en rapportages, worden doorgaans gevoed met gegevens die vanuit het hele applicatieve landschap van de organisatie komen. Vaak wordt dan aan de tester gevraagd om vast te stellen dat de data in het rapport klopt: is het juist en volledig en sluit het aan bij de data zoals we dat kennen in de bronsystemen?
Dit vereist kennis van de manier waarop deze rapportages worden ingezet, van de bronsystemen (toepassingen) en van de wijze waarop het in de rapportages landt, bv, via ETL-processen.
Lagenstructuur
Bij het testen van een applicatie wordt vaak een opdeling gemaakt in 2 lagen: een presentatielaag (wat de gebruiker ziet) en een opslaglaag (waar de data bewaard wordt). Daarnaast wordt de verwerking van de data in de toepassing getest. Dat zijn vaak uitgebreid beschreven processen, denk aan het berekenen van een maximale hypotheek. Zie ook: Minder Strakke Specificaties.
Deel 1 – Bij een data-geörienteerd traject zoals een datawarehouse of een business intelligence oplossing is de gebruiker van het platform vaak een Business Analist die op zijn beurt een dashboard maakt voor een eindgebruiker (bv. controller of een sales manager). De Business Analist is daarmee een soort ontwikkelaar geworden en deze zal een testproces inrichten met de eindgebruiker waarbij hij/zij implciet uitgaat van de juistheid en de volledigheid van de aanwezige data. De test is er dan dus op gericht om deze gegevens op een goede manier te presenteren aan de eindklant.
Deel 2- Om er op te kunnen rekenen dat de gepresenteerde gegevens juist en volledig zijn, moet dit laatste expliciet getest worden. Op de route van de bronsystemen (“primaire applicaties”, “toepassingen”) tot en met de presentatie in BI-rapportages worden veel stappen genomen: data wordt verzameld, aangepast en geaggregeerd.
We noemen dit het ETL-proces: Extractie, Transformeren en Laden. Deze ETL-stappen zullen getest worden zodat aangetoond kan worden dat de gegevens compleet en juist overkomen. En waar verschillen ontstaan, zullen die verklaard moeten worden.
De tester moet daarbij focus houden op het testen van de vele verschillende lagen in het landschap – en kan niet alleen volstaan met een end-to-end test (waarbij de tussenstappen als een “black box” worden beschouwd). Bij die aanpak is de kans op (lastig te verklaren verschillen) enorm groot en dat kost in projecten zeer veel doorlooptijd.
Minder Strakke Specificaties
Bij de bedrijfsapplicaties worden de functies vaak uitgebreid uitgewerkt: het wordt voor de ontwikkelaar kraakhelder gemaakt hoe bv. een Hypotheekberekening moet worden gedaan, uit welke stappen een prolongatie van een verzekeringsprolis bestaat of wat er voor nodig is om een bankoverschrijving te kunnen verwerken. Bij het Datawarehouse is dat vaak minder strak opgeschreven – en vraagt het om veel scherpte bij analisten, ETL-ontwikkelaars en datawarehousetesters.
Bovendien leven ontwerpers van een applicatie in een bubbel: de begrippen die zij gebruiken hoeven alléén in die applicatie ingezet te worden. De begrippen die in het datawarehouse landen, worden ontsloten uit diverse applicaties. DWH-ontwikkelaars moeten daarom met Data Stewards en informatiemanagers het gesprek aangaan over de gebruikte begrippen en hun betekenis. Dat heeft ook invloed op de testers: zij mogen er niet van uit gaan dat bv. het begrip Omzet in toepassing A hetzelfde betekent als Omzet in toepassing B. En dat Klant hetzelfde betekent als Customer of Verzekerde. Enz. enz. De meeste organisaties beschikken nog niet over een bedrijfsbrede data dictionary en dat vraagt dus extra scherpte bij de tester.
Méér en andere kwaliteitsattributen relevant
Bij het opstellen van een testplan worden vaak de kwaliteitsattributen voor software aangehaald (NEN ISO 25010), bij data-geöriënteerde trajecten komen vooral de kwaliteitsattributen voor gegevens in beeld (NEN ISO 25012).