del.icio.us	Digg
Furl	Netscape
Yahoo! My Web	Technorati
Google Bookmarks	Newsvine
BlinkList	reddit
Blogmarks	ma.gnolia
Tailrank	Windows Live
Linkedin

Gebaat met Test Governance?

Op het moment dat aan tafel het woord Test Governance valt, komen er de meest uiteenlopende verhalen en misverstanden naar boven. Het lijkt een onderwerp waar iedereen wel een voorstelling over heeft, maar een ieder een andere. En waarom eigenlijk zou een bedrijf gebaat zijn met Test Governance?

Waarom bedrijven willen testen

Laten wij eest kijken waarom bedrijven willen dat er getest wordt. Vanuit een IT perspectief lijkt testen immers niet zo veel toe te voegen. Als er kwalitatief goed wordt gebouwd, dan zitten er toch maar weinig fouten in? En zeker geen ernstige toch? Kijken wij vanuit een Business perspectief, dan gaat het eigenlijk om iets heel anders - om het uitsluiten van bedrijfsrisico's. En het onvoldoende ondersteunen van de bedrijfsprocessen (door een applicatie) is zo een risico.

Acceptatie is de beoordeling van uitstaande risico's

Het uiteindelijke doel van testen is een gefundeerd en goed afgewogen oordeel te kunnen geven over de risico's, die een bedrijf loopt als de IT ondersteuning van zijn bedrijfsprocessen in productie genomen wordt.

IT Governance heeft ten doel het vermogen om dit oordeel te vormen te borgen in overeenstemming met de bedrijfsdoelstellingen, het bedrijfsbeleid en relevante wet- en regelgeving. Bij die oordeelsvorming moeten drie vragen naar behoren worden beantwoord:

• Is er voldoende bewijsmateriaal om te oordelen dat bepaalde risico's zijn afgedekt;
• Welk bewijs is er dat sommige features niet naar behoren werken (het risico is gematerialiseerd);
• Welke risico's blijven uitstaan wegens gebrek aan bewijsmateriaal (de tests zijn niet uitgevoerd, of er waren geen tests gepland).

Wat levert het op?

Goed ingerichte Test Governance biedt de kaders om consistent tot deze afgewogen oordeelsvorming te kunnen komen via afspraken en richtlijnen, die gelden voor alle IT projecten en releasematige IT veranderingen. Hierdoor wordt veel bespaard doordat schade aan de bedrijfsvoering wordt voorkomen, dat vrijwel altijd een veelvoud is van de kosten van de benodigde testinspanning. Bijkomend wordt door bedrijfsbrede Test Governance veel bespaard door het meer optimaal inzetten van kennis en kunde, en van resources en ook tooling.

Wat houdt Test Governance in?

Test Governance betekend niet dat er een enkele bedrijfsbrede testaanpak wordt neergezet, die daarna voor elk project wordt afgedwongen. Immers zijn er verschillende project aanpakken, die een ieder zijn eigen testaanpak vereisen. Test Governance zal wel generieke richtlijnen in de vorm van een Test Policy geven, die door de verschillende projecten naar de project specifieke aanpak vertaald dienen te worden. En dat is nu eenmaal anders voor een klassieke waterval aanpak dan voor een moderne iteratieve aanpak volgens SCRUM.

Test Governance richt zich op een aantal specifieke proces gebieden:

• Test policy en Test strategie
• Test planning (inclusieve test estimation)
• Test monitoring en control
• Test design en Test uitvoering
• Test omgeving management
• Acceptatie Management

Voor elk van de proces gebieden kunnen KPI's worden gedefinieerd om succes meetbaar te maken en verbetering te kunnen sturen. Dat betekend ook dat zo het positieve effect van testen objectief zichtbaar gemaakt kan worden.

Inbedding in het grotere geheel

Test Governance staat niet op zich. Het moet worden ingebed in het grotere geheel van IT Govenance en ook van de Business Governance. De Business Governance maakt steeds vaker gebruik van BISL en Six-Sigma; en brengt regelgeving in zoals de Code tabaksblad, BASEL II, en ook regelgeving, die meer effect hebben op de inrichting van IT, zoals SOX en SAS70. IT Governance is veelal gebaseerd op COBIT en maakt gebruik van ITIL en/of ASL, en heeft voor de groeiambities paden uitgezet, gebaseerd op CMMi.

Ook dient Test Governance aan te sluiten bij de Programme- en Project methodieken, die in de onderneming worden gebruikt. Bij voorbeeld, Prince2 en PMBok,

Wat zijn de voorwaarden?

Naast een goede aansluiting met zowel Corporate Governance en IT Governance kan de rol van het hogere business management niet worden onderschat. Zij beïnvloeden als geen ander de geloofwaardigheid en de bereidheid van alle betrokkenen om te coöpereren.

Verder is het handig om Test Governance stapsgewijs in te voeren en elk succes te vieren. Drie klassieke Quick-Wins bij wat grotere organisaties en programma's van projecten zijn: Aansluiting op Business Risico's, Test Estimation en Test Environment Management. Het aardige is dat dit allen onderdelen zijn, die in een Master Testplan beschreven moeten worden. Via veelal informele reviews en constructieve terugkoppeling kan zowel projectwinst als ook commitment van de betrokken TestManagers worden gewonnen.

Hoeveel Test Governance is genoeg?

Dat hangt van de organisatie en de situatie af. Het opstellen van de Test Policy en het door het hogere management te laten bekrachten is de basis. Hiermee worden de meest fundamentele afspraken over kwaliteit en aanpak vastgelegd, wat doorgaans niet meer dan een enkel A4'tje hoeft te beslaan. Het is zeker niet de bedoeling een waterhoofd aan bureaucratie op te werpen, waar niemand op zit te wachten. Het levert meer op effectieve en veilige communicatie structuren in te richten om zowel positieve ervaringen, als ook geraakte valkuilen over de projecten heen uit te kunnen wisselen. Die structuur levert tevens een platform op voor het vergroten van draagkracht en voor verdere verbetering stappen.

Voor de verdere uitwerking van Test Governance kan heel goed gebruik gemaakt worden van beschikbare kennis en boeken zoals TestGrip en het Verification & Validation Maturity Model (V2M2®), dat is gebaseerd op CMMi en TMMi.