Strategy & Architecture

BI Testen is Transparantie volgens drie W’s

Als breed georiënteerde BI en Analytics consultant word ik regelmatig gevraagd mijn visie te geven.

Zo werd ik laatst gevraagd twee workshops BI testen te begeleiden. Eerlijk gezegd ben ik zelf geen tester, maar dat wil niet zeggen dat ik daar geen beeld bij heb. BI testen, een regelmatig terugkerend onderwerp, dat in de praktijk weerbarstig blijkt. Waarom is dat toch? Zit dat in de complexiteit van de architectuur, die feitelijk een keten van componenten met specifieke methoden en technieken vormt. Of zit dat in de benodigde kennis? Het is geen expertise op zich, dus laat je een BI-er testen leren, of een tester BI leren?

Terugkomend op beide workshops, de onderwerpen waren verschillend. Waar er bij de ene een concrete rapportage als use case op tafel lag, ging het bij de andere meer om concrete vragen in het leveringsproces van datamarts. De aanleiding voor beide workshops waren vragen als hoe test je, waar begin je en hoe weet je het goed doet. Heel herkenbaar, want BI is complex (architectuur en techniek), gebruikt veel data en behoeft altijd context (informatie).

In elke BI oplossing wordt data uit meerdere bronnen samengebracht en voor meerdere doeleinden beschikbaar gesteld. In die verwerkingslag wordt data eerst bron onafhankelijk geintegreerd en vervolgens gericht op de gewenste informatiebehoefte weer uitgeleverd. Naast de feitelijke data is de methode van verwerking ook cruciaal om tot goede informatie te komen. Die garantie kan alleen maar worden geboden als op al die aspecten de juiste testen worden uitgevoerd: de data inhoud, het proces (ook wel de logistiek genoemd) en de uitkomst (informatie). Hoe breder de projectscope aan bron- en doelkant, hoe complexer dat verwerkingsproces wordt en daarmee des te moeilijker een kwaliteitsgarantie op de BI oplossing is af te geven.

BI testen moet daarom zichtbaar en concreet worden opgepakt. Dat kan door er structuur in aan te brengen en dat terug te brengen naar standaards en generieke zaken. Generaliserend wordt in elke stap van het verwerkingsproces data geselecteerd, vervolgens omgezet naar een andere structuur en formaat en uiteindelijk weer uitgeleverd. Onderstaand overzicht geeft aan hoe er in die stappen kan worden getest. Dit is zeker geen volledige opsomming, maar een weergave van de zaken die in praktijk altijd aan de orde zijn.

Wat: Bron
Waarom: Zicht op kwaliteit van de onderhavige data t.b.v. selectie, vulling en betekenis. Afstemming en verantwoording over volledigheid en juistheid van de aanlevering.
Waarmee: Data profiling (definitie, data type, % gevuld, min/max waarde, domeinwaarden). Controleoverzichten (tellingen en sommaties) op relevante entiteiten die over de keten heen behouden blijven.

Wat: Extractie
Waarom: Borgen van de stabiliteit van de leverings¬kwaliteit.
Waarmee: Gegevenslevering overeenkomst (GLO): frequentie, planning, formaat, structuur en kwaliteitseisen.

Wat: Transformatie
Waarom: Transparantie, compleetheid en juistheid van classificaties (groeperings- en analytische kenmerken).
Waarmee: Condition decision, pairwise testing.

Wat: Laden
Waarom: Toetsing dat de principes (generieke kenmerken) van het doel (datamart/rapportage) goed worden toegepast.
Waarmee: Datamart: Uitgifte sleutels (ID’s), opbouw historie (Data vault, SCD2) en granulariteit. Rapportage: structuur (groepering) en (sub)totalen.

Wat: Doel
Waarom: Afstemming en verantwoording over volledigheid en juistheid van de uitlevering.
Waarmee: Acceptatie criteria van de ontvanger. Controleoverzichten (tellingen en sommaties op relevante entiteiten ter vergelijking met bron). Representatieve steekproeven voor detailvergelijking met bron.

Naast deze data inhoudelijke kant spelen ook organisatorische aspecten een grote rol in het uiteindelijke resultaat, namelijk betrouwbare informatie. Dit los je niet alleen met techniek(en) op, maar die technieken kun je wel handig inzetten als bewijs. D.w.z. ter onderbouwing van de kwaliteit van het leveringsproces en de uiteindelijke informatie zelf. Een gezamenlijke verantwoordelijkheid op zowel de aanlevering (bron) als de uitlevering (doel) is daarbij cruciaal. Over het gehele verwerkingsproces heen is de transparantie en eenduidigheid van data, zowel op definitie als inhoud, natuurlijk randvoorwaardelijk.

Testtechnieken zijn zowel in het ontwikkelproces (testend) als in de operationele uitvoering (beheersmatig controlerend) te gebruiken. De kracht ervan is dus dat deze generiek inzetbaar zijn, maar daarmee wel de keuze qua toepassing in het project neerlegt. Alles testen is namelijk geen optie. Dus wat, waar en hoe je gaat testen, dat is de keuze. Daar is helaas geen checklist of handleiding voor. De data inhoudelijke context van een datamart of rapportage bepaalt de concrete invulling en toepassing van die testtechnieken. Als BI testen zoals hiervoor aangegeven wordt toegepast, kan de BI tester zich op de toepassing concentreren. Dat maakt het werk van de BI tester veel interesanter. In dit kader verwijs ik graag naar de TMAP site (https://www.tmap.net/wiki/test-design-techniques ) voor testtechnieken die goed inzetbaar zijn in het data- of informatieleveringsproces (selecteren, transformeren en leveren).

De insteek voor beide workshops was dus anders, maar uiteindelijk kom ik op dezelfde aandachtspunten. Het leveren van informatie is een aaneenschakeling van stappen, waardoor er een sterke afhankelijkheid ontstaat. Met BI testen concentreer je op een specifiek onderdeel, maar je moet daarbij voortdurend over de hele keten van het verwerkingsproces heen blijven kijken, terug én vooruit.

BI testen is wat mij betreft transparantie volgens de drie W’s: Wat, Waarom en Waarmee. Omdat bedrijven steeds meer datagedreven zijn, hoeft BI testen zich niet meer te bewijzen. Het is gewoon een pure noodzaak. BI testen is wat mij betreft dan ook vooral Bewust en Intelligent testen!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *