De politieke wurggreep voor het testteam

Wanneer er bij softwareontwikkeling gebruik wordt gemaakt van de traditionele watervalmethode dan kan dit een probleem vormen voor het testteam doordat zij in een politieke wurggreep terecht komen. Ik wil hier graag dieper ingaan op de nadelen waar het testteam tegen aanloopt bij traditionele watervalprojecten, maar ga ik ook in op oplossingen en hoe hiermee om te gaan.

De watervalmethode is een methode voor softwareontwikkeling, waarin de ontwikkeling regelmatig en vloeiend (als een waterval) naar beneden loopt. De watervalmethode bestaat uit een aantal fasen die elkaar logisch opvolgen, namelijk: definitiestudie/analyse, basisontwerp, technisch ontwerp/detailontwerp, bouw/implementatie, testen en  integratie. Dit is een traditionele manier van software-ontwikkeling die al jaren wordt toegepast. Het grote voordeel van deze manier van ontwikkelen is dat het duidelijk, bekend en snel te begrijpen is. Wensen en eisen zijn vooraf gedefinieerd en de realisatie daarvan kan in de tijd worden uitgezet en dus goed gepland worden. De methode behelst dat een volgende fase pas gestart kan worden als de vorige is afgerond.

In de praktijk wordt er echter vaak een dakpansgewijze constructie gevolgd, waarbij  de volgende fase  al wordt opgestart voordat de vorige volledig is afgerond. Dit omwille van besparing op doorlooptijd en budget (leegloop, onnodig wachten op elkaar), waardoor deze aanpak in de praktijk vaak leidt tot veel rework en forse overschrijding van tijd en/of kosten per fase.

Politieke wurggreep

Als testteam loop je in deze traditionele projecten het risico in een politieke wurggreep terecht te komen. Als team zit je aan het einde van de rit. Eén van de grote nadelen hiervan, zeker als de einddatum (implementatiedatum) en de kosten van het project gefixeerd zijn, is dat eerder opgelopen vertragingen in het project gecompenseerd moeten worden in de fase van testen. In de praktijk betekent dit dat vertraging binnen een watervalproject ook altijd als een waterval bij de laatste in de lijn, het testteam, als probleem terecht komt. Wanneer de fase van testen ingekort moet worden vanwege vertragingen in de voorgaande fases, dan betekent dit dat er minder tijd besteed kan worden aan het testen van het softwaresysteem. Hierdoor is er te weinig tijd om alle risico’s in kaart te brengen, het systeem grondig te testen en alle fouten en eventuele problemen op te sporen. Dit gaat ten koste van de kwaliteit van het systeem en kan zeer nadelige gevolgen hebben.

De mogelijkheden binnen een watervalproject om in de testfase met dit probleem om te gaan zijn:

– De einddatum van het project uitstellen:
Voordelen: het volledige systeem kan grondig getest worden, het risico op fouten in productie neemt af.
Nadelen: het project duurt langer, de kosten worden hoger, het uitnutten van de baten start later.

– Het aantal testanalisten verhogen om in de kortere tijd dezelfde hoeveelheid testwerk te verzetten:
Voordelen: het volledige systeem kan grondig getest worden, de einddatum van het project wordt gehaald.
Nadelen: de kosten worden hoger, nieuwe testanalisten zijn beperkt inzetbaar vanwege een inwerkperiode.

– De scope van het project verkleinen:
Voordelen: een deel van het systeem kan grondig getest worden, budget en tijd worden niet overschreden.
Nadelen: niet het volledige systeem komt in productie.

– Minder grondig testen:
Voordelen: het volledige systeem wordt getest, budget en tijd worden niet overschreden.
Nadelen: groter risico op fouten in het systeem in de productiefase, risico op hogere herstelkosten, risico op imagoschade.

Welke keuze er in deze fase ook door het testteam gemaakt wordt, de klant- en projectbelangen staan lijnrecht tegenover elkaar, waarmee het team zich per definitie in een politieke wurggreep bevindt. Als het testteam in het belang van de klant de risico’s zo goed mogelijk in kaart brengt, betekent dit dat het extra geld en/of tijd nodig heeft (optie 1 en 2). Brengt het testteam de risico’s in het belang van het project zo goed mogelijk in kaart, dan kiest het voor minder of minder grondig testen om op tijd en binnen budget klaar te zijn (optie 3 en 4).

En nu?

Als tester wil je een gedegen advies geven aan de klant omtrent de risico’s die deze loopt als de opgeleverde software in productie gaat én wil je een bijdrage leveren aan een succesvol project. Betekent dit dan dat de waterval methode per definitie leidt tot een politieke wurggreep voor de tester en dat er altijd een keuze gemaakt moet worden tussen het projectbelang of het klantbelang?

Het antwoord is nee. Als een waterval project niet te complex is en niet te lang duurt (dus kleinere projecten) en als er een goede projectleiding is, worden rework en overschrijding van budgetten beperkt en kan het testteam prima binnen de grenzen van het project het belang van de klant én het project dienen. Krijgen we echter te maken met grotere en complexere projecten, dan is de wurggreep nagenoeg een feit.

De laatste jaren zien we in dit soort projecten de Agile benadering steeds meer aan terrein winnen. Binnen deze benadering is het testen niet geïsoleerd aan het einde van het project, maar juist vol betrokken op elk tijdstip van het project. Geeft deze benadering dan een oplossing voor de politieke wurggreep van het testteam in de traditionele benadering?

In een Agile aanpak van projecten leveren klant, ontwerper, ontwikkelaar en testanalist in een multi-disciplinair team in korte sprints functionaliteiten van een systeem op. Elke sprint is als het ware een miniatuurproject op zichzelf en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Anders dan bij een watervalproject zit je als testteam dus niet meer aan het eind van de lijn, maar ben je vanaf het begin van het project actief onderdeel van de verantwoordelijkheid om tot een goed werkend systeem te komen. De functionaliteiten met de meeste waarde worden binnen een Agile benadering als eerste opgeleverd en na iedere sprint worden de project-prioriteiten heroverwogen. Hierdoor is er na elke sprint een moment voor alle partijen om zowel op project- als klantbelang te sturen. Op deze manier komt het probleem van vertraging niet meer automatisch als een waterval bij het eind van het project, dus het testteam, terecht en is er van een politieke wurggreep voor het testteam geen sprake meer.

Toch zijn er ook kanttekeningen bij een Agile benadering van projecten. Voorwaarde voor het slagen van deze benadering is dat het als een soort ‘way of life’ door de hele organisatie gedragen moet worden, wat in te passen moet zijn binnen de bestaande cultuur van een organisatie.  Verder moet het gehele team vanaf het begin van het project altijd aanwezig zijn,  waarbij afwezigheid tot stagnatie en vertraging leidt en is het eindproduct niet vooraf exact te bepalen wat de langere  termijn planning lastig maakt. Ten slotte vereist het werken in een Agile omgeving specifieke eigenschappen en de nodige ervaring van de testconsultant: hij moet op de hoogte zijn van de politiek binnen en de cultuur van de organisatie, en hij moet over ruime business- en testkennis en de juiste softskills (zoals communicatieve vaardigheden en empathisch vermogen) beschikken.