Tester moet focussen om project te laten slagen

Testen moet. Geen project kan zonder. Ook wanneer een ict-project wordt uitbesteed moet er getest worden door de opdrachtgever. Op diverse manieren kan invulling gegeven worden aan de 'testrol' in een project. Elke mogelijkheid heeft voor- en nadelen. Wat zijn de opties? Hierbij heb ik aangenomen dat er een zinvolle business case ten grondslag ligt aan het project. Er is dus een probleem voor de organisatie! Het probleem vertegenwoordigt een significante waarde, waardoor het voor de organisatie essentieel is dat het project op tijd en binnen budget wordt opgeleverd. Wie kun je dan het beste laten testen? Door bewust te zijn van de voor- en nadelen, voorkom je een mislukt project.

Opdrachtgever test zelf
Het is gebruikelijk om de (interne) opdrachtgever de capaciteit voor de testrol te laten leveren. Deze medewerkers zijn immers bekend met de materie en staan achter de business case van het project. Het is alleen de vraag of zij bekend zijn met gestructureerd testen. Uit eigen ervaring weet ik dat het antwoord hierop meestal 'nee' is. Op basis van de ervaring en het referentiekader van degene die de test uitvoert, wordt de oplossing getest. Het gevaar ontstaat dat dit niet conform een teststrategie is, waarin de risicovolle onderdelen en zwaarte van testen benoemd zijn. Het ene deel van het systeem kan dan te licht of niet getest worden en het andere deel te zwaar. Bovendien is testen iets wat 'erbij' gedaan wordt: voor medewerkers van de opdrachtgever is het project vaak een bijzaak en niet de hoofdtaak. Mijn ervaring is dat het moeilijk is om deze mensen voldoende vrij te maken van hun hoofdtaak. Wanneer de medewerker niet goed wordt begeleid en hij de noodzaak er niet van inziet, zal het niet de eerste keer zijn dat het project onnodig uitloopt doordat de testen niet tijdig voorbereid en uitgevoerd worden. Hierdoor komt het projectteam op den duur stil te staan, met alle gevolgen van dien voor de einddatum, het budget en natuurlijk voor het behalen van de business case.

Leverancier laten testen
Een andere optie voor het testen is de leverancier hier invulling aan laten geven (dit kan ook de interne ict-afdeling zijn). Voor deze mensen is het project de hoofdtaak; zij zijn gespecialiseerd in het uitvoeren van projecten. Ook kennen zij alle ins- en outs van het project. Bij leveranciers die het doen van projecten serieus nemen, is de testrol belegd bij professionals die zijn gespecialiseerd in testen, de tester. Deze professionals bezitten de kennis om testen gestructureerd uit te voeren. De testers hebben echter minder kennis van de materie dan de medewerkers van de klant. Als tester richt je je, terecht, op de beschreven requirements. Daardoor wordt vooral het functioneel ontwerp getest en niet of de oplossing het (kern)probleem van de klant oplost. In de perfecte wereld is het functioneel ontwerp waterdicht. Helaas is dat alleen het geval in Utopia. In de echte wereld zal het functioneel ontwerp een goede stap in de richting zijn, maar de afstemming met het werkelijke proces van de klant is vrijwel nooit volledig.

Externe tester
Om deze nadelen te compenseren, wordt vaak een externe tester een goede oplossing gevonden, zeker in combinatie met een materiedeskundige van de klant. Een externe tester is immers specialist op zijn vakgebied en weet dus goed hoe hij/zij gestructureerd moet testen. Op deze manier is de materiekennis en de kennis van gestructureerd testen samengevoegd: het lijkt een ijzersterke combinatie. Maar pas op: vaak wordt de externe tester zo laat mogelijk in het project ingeschakeld (pas wanneer de testcapaciteit daadwerkelijk nodig is). Hierdoor heeft hij niet voldoende begrip van het kernprobleem dat in het voortraject is behandeld: dat probleem dat nu net met dit project wordt opgelost. In plaats van gefocust te zijn op het probleem dat met deze oplossing aangepakt zou moeten worden, gaat de externe tester voor een zo groot mogelijke dekking! Hij staat voor kwaliteit; daar is hij tester voor. Hij test bij voorkeur alles. Echter, voor het slagen van het project is het essentieel dat hij zich focust op de teststrategie, die afgestemd is op het kernprobleem achter dit project.

Het project moet immers op tijd, binnen budget en met de juiste kwaliteit opgeleverd worden. Het hoeft niet volledig foutloos. Belangrijkste is dat het probleem van de klant is opgelost. Als er dan nog een schoonheidsfoutje zit in een niet-kritisch onderdeel van de oplossing, is dat niet erg. Naast de juiste kwaliteit, betekent een geslaagd project voor de klant ook dat het project op tijd en binnen budget wordt opgeleverd. Als de externe tester dit niet in zijn achterhoofd heeft en geen idee heeft van het kernprobleem, leidt dit tot tegengestelde belangen en is het risico van uitlopen in tijd en budget aanwezig.

Focus de tester!

Kortom, ik pleit ervoor om ook bij het testen te blijven focussen op het probleem, ongeacht wie de testen uitvoert. Met andere woorden, toets of het probleem is opgelost! Hierbij is het van belang dat alle projectmedewerkers, die van de opdrachtgever, van de leverancier en eventuele externe, het op te lossen probleem accepteren. En dus antwoord kunnen geven op de vraag ‘waarom wordt dit project eigenlijk uitgevoerd?‘. Dat geldt ook voor alle mensen die de oplossing testen. Kiest de klant voor een externe partij ten aanzien van testen, dan zal deze ook het probleem moeten accepteren. Wanneer dit niet gebeurt, is het risico van het niet behalen van de business case daadwerkelijk aanwezig.