Efficiënt testen van business intelligence
BI Projectmanager
Expert van Computable voor de topics: Business Intelligence en Smart IT
MeerTesten 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?
Maurice, 26-08-2010 13:35
13-02 Beveiliging SaaS uit de cloud is discutabel
10-02 Het einde van het begin van cloud en virtualisatie
10-02 De windwakken van de cloud-sector
09-02 Citoto
09-02 Lang leve de hackers!
09-02 Modder gooien in ICT-land
08-02 Reseller verliest slag om het groene huishouden
08-02 Hadoop lijkt een alleskunner
07-02 Hou zicht op de informatie bij HNW
07-02 Eigen werknemer kan ook een vijand zijn
08-02 Hadoop lijkt een alleskunner
06-02 Delta Lloyd verlengt contract met Human Inference
27-01 Te veel aandacht voor KPI's leidt af
24-01 SAS ziet omzet met 12 procent stijgen
23-01 Gebruik strategiekaart en Balanced Score Cards...
23-01 CIO zet analytics en BI op eerste plaats
23-01 Marktplaats.nl benut met SAS markt- en klantkennis
20-01 Software en diensten bezorgen IBM groeicijfers
20-01 Datamanagement hot item voor verzekeraars
19-01 IBM-CIO stimuleert social networking
|
|
06-01-12 IBM koopt softwaretester Green Hat
09-12-11 NGI en TestNet zetten testafdeling op
29-10-10 Information Builders en Teradata samen in BI
De gecombineerde kracht van JD Edwards en Salesforce.com
De integratie van JD Edwards en Salesforce.com drijft organisaties vaak tot wanhoop. Deze whitepaper beschrijft hoe......
| Aantal reacties met 3+ sterren | Gemiddelde waardering | |||
 | 1 | 155 | 6.4 | |
 | 2 | 121 | 6.7 | |
 | 3 | 112 | 6.4 | |
 | 4 | 79 | 6.6 | |
| 5 | 53 | 6.1 | |
| 6 | 49 | 6.3 | |
 | 7 | 48 | 6.5 | |
| 8 | 44 | 6.1 | |
| 9 | 43 | 6.0 | |
| 10 | 40 | 6.3 | |
Computable.nl is onderdeel van VNU Media, uitgever van o.a.: NationaleVacaturebank.nl | Intermediair | IntermediairPW | Carrièregids.nl | CompanyRating | NationaleStagebank.nl | Banen.nl | HRbase.nl | HRdirectory.nl | Financebase.nl | InIct.nl | InInterim.nl | InOverheid.nl | Overheidscircuit.nl | Computable | CRN | IT Knowledge Base | Tweakers.net | Recruitmentbloggers
Sitemap | Abonneren | Adverteren | Algemene voorwaarden | Disclaimer | Privacy | Alle rechten voorbehouden © 1995-2012 VNU Media
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.