Met de zomer in aantocht, is het tijd om terug te blikken op het afgelopen jaar. Ik ben in juni vorig jaar begonnen aan een nieuwe opdracht, als BI testconsultant. Gedurende mijn carrière als tester heb ik hier altijd interesse voor gehad, maar is een opdracht in dit vakgebied nooit voorbijgekomen. Dus toen ik de kans kreeg om aan met BI aan de slag te gaan, heb ik dit met beide handen aangegrepen!
Mijn ervaring met Business Intelligence tot dan toe was voornamelijk een cursus BI testen. Gewapend met deze kennis ben ik aan het BI test avontuur begonnen. Gelukkig was het bij een klant waar ik eerder al een andere opdracht had gedaan. Hierdoor had ik al branche-, product- en omgevingskennis. Dit heeft me wel een zekere boost gegeven in het begin zodat ik niet helemaal in het diepe heb hoeven springen.
Verschillen
Maar wat zijn dan de verschillen tussen een BI tester en een ‘gewone’ tester? Waarom wordt overal specifiek om een BI tester gevraagd? Het is toch software (black box) waar je iets in stopt en er een verwachting uitkomt? Het antwoord hierop is dat er in principe ook niet veel verschil is. Maar daar heb je het al, de term “in principe”.
“in principe”
Om dit verder te duiden, is een korte uitleg nodig. Simplistisch gezien is BI een stukje software dat data uit een (of meerdere) bronsyste(e)m(en)haalt, hier een aantal berekeningen op los laat, samenvoegt, om vervolgens deze data uiteindelijk te aggregeren. Hierna wordt dit netjes gepresenteerd doormiddel van een rapport.
Net zoals bij “gewoon” testen het geval is, kan je een dataset nemen van één enkel geval, en deze door de software halen, waarna het in het rapport terecht komt. Eventuele wijzigingen op de software zijn op deze manier dan ook goed te testen. Maar nu komt het grote verschil met BI testen; het gaat niet om één geval, maar om een dataset van miljoenen records. En elk record heeft soms wel 100 (of meer) velden.
Het tweede grote verschil is dat BI testen vaak gaat over data die in het verleden is opgevoerd. Dit is dus een extra complicerende factor waar je rekening mee moet houden, omdat het vaak erg lastig is om nieuwe data in het verleden op te voeren. Dit houdt dus in dat je niet alleen een ‘backdated mutation’ moet doen, maar ook bijvoorbeeld het moment van opvoeren moet aanpassen aan een datum in het verleden.
Test methodiek
Dus hoe kunnen we er dan voor zorgen dat dit stukje software dan toch kan worden getest?
Om te beginnen moet de testpyramide worden gevolgd, waarbij de nadruk moet komen te liggen op (geautomatiseerde) unit testen. Deze unit testen zijn vooral bedoeld om de functionaliteit van de berekeningen af te testen. Hierbij kan er synthetische data worden gebruikt als brondata. Hiermee kan een groot gedeelte van de functionaliteit worden af getest.
Ten tweede moet de data die er uit komt worden vergeleken. In het geval van een migratie binnen BI kan je de nieuwe data vergelijken doormiddel van tooling met de oude data. Deze tools controleren op hoeveelheidrecords op basis van sleutelvelden, evenals op inhoud van alle velden die bij deze sleutelvelden horen. Op basis van de uitkomst van de vergelijking kan een oordeel worden geveld over de kwaliteit van de software. Uiteraard kan je ook vergelijken met de bron data op bepaalde velden, maar dit zal voornamelijk zijn op totale aantallen.
Conclusie
Na een jaar met veel plezier bij deze finance klant gewerkt te hebben, kom ik tot de volgende conclusie: BI testen is niet meer en niet minder dan functioneel testen van een specifiek stukje software, echter... 😉
financial detective
De basis is gelijk, maar zodra je gaat inzoomen en doorpakken komen er specifieke kenmerken naar boven. De soms enorme hoeveelheden records stellen eisen aan hoe je met het softwaretesten om moet gaan. De factor “tijd” is er één om continu rekening mee te houden. Denk dan aan de timestamps van records, maar ook aan verwerkingstijden van batch jobs (non functional requirements). Én, last but not least, je moet cijfers en data écht leuk vinden. Door het samenvoegen van veel bestanden i.c.m. de grote hoeveelheid (vaak complexe) rekenregels, voel ik me soms een financial detective in de grote boze datawarehouse wereld. En weet je, ik geniet van deze rol!
