Resultaatgericht testmanagement

Interview met Paul de Horde

Paul de Horde van Test Management Group werkt samen met enkele KWD-ers aan een groot project bij een ministerie. Hij is geen typische testmanager die in een standaard hokje is te plaatsen en waarschijnlijk juist daarom is hij succesvol waar anderen dat niet zijn. Zelf noemt hij zijn aanpak resultaatgedreven testmanagement en daarmee sluit hij goed aan op het Resultaatmanagement van KWD.

 

KWD-er Ferdy Meijboom interviewde Paul over wat hem onderscheidt van veel van zijn vakgenoten.

Traditioneel zijn veel testmanagers te vatten in een paar karikaturen:

  1. De alle-risico’s-afdekkende testmanager
  2. De “daar ben ik niet van” testmanager
  3. De test-alleen-tegen-het-ontwerp testmanager
  4. De Fit for Purpose testmanager

Hoe zij jijzelf als je naar deze karikaturen kijkt?

Ik wil nog wel een 5e karikatuur toevoegen: De TMap fundamentalist. De afgelopen decennia hebben veel bedrijven hun testmanagers en testers heel traditioneel opgeleid waarbij TMap of ISTQB de standaard is. Wat ik echter ook zie is dat heel veel testers doorgroeien tot testmanager terwijl ze naar mijn idee op een aantal vlakken tekort schieten en dan heb ik het vooral over communicatieve eigenschappen en “personal agility”, de kunde om mee kunnen te bewegen met de behoeften. Dat wordt op dat moment gecompenseerd door rigide vast te houden aan de gekozen aanpak. Testers zijn van nature vaak zekerheidszoekers en willen dan ook graag tegen de requirements testen. Van te voren wordt dan een Master Testplan opgesteld terwijl, zeker bij grotere projecten, er zoveel verandert tijdens het project dat je steeds weer je plan moet bijstellen. Verder wordt er steeds vaker agile gewerkt en daarin past de TMap fundamentalist zeker niet, die voelt zich helemaal niet lekker bij wat hij ziet als onzekerheid en onvoorspelbaarheid.

Zelf kom ik het dichtst in de buurt van de Fit For Purpose testmanager. Maar dan in de zin dat ik alles doe om zo effectief mogelijk tot een voor de opdrachtgever bruikbaar resultaat te komen. Dit tot en met het ter discussie stellen van de bestaande uitgangspunten en plannen als dat nodig is.

Ik pas mijn werkwijze aan aan het project en het team met een sterke focus op het einde van het project. In samenwerking met het projectteam streef ik dan om te komen tot een voor de opdrachtgever bruikbaar en waardevol resultaat. En uiteraard, daar ben ik voor ingehuurd, een rapportage waarmee aangetoond wordt of het resultaat goed is om in productie te nemen óf juist niet. Daarmee kan ik de projectmanager ook helpen om succesvoller en voorspelbaarder te zijn.

We zien dat de afgelopen jaren Prince2 geëvolueerd is en Agile meer en meer gangbaar wordt binnen projecten. Ook combinaties van waterval en agile elementen zien we steeds vaker. Zijn de testmethoden net zo mee geëvolueerd?

Ook zou er veel meer gekeken moeten worden naar de karakterkenmerken van testmanagers. Agility vraagt om een kritische houding waarbij je je als testmanager ook bemoeit met bijvoorbeeld de releaseplanning en het ophakken van opleveringen. Dit alles met het oog op resultaat en beheersbaarheid.

Wat zijn jouw karakteristieken waarmee je je onderscheid en waardoor jij succesvoller bent dan veel vakgenoten?

Ik ben een praktische resultaatmanager langs de as van het testen en ik denk in logische stappen vooruit. Daarbij ben ik sterk analytisch waarbij ik me richt op hoofdlijnen en verbanden. Abstraheren en door de brei heen kijken, de logische volgorde bepalen en op basis daarvan en de afhankelijkheden bepalen wat we eerst moeten doen. Met andere woorden de traditionele kritieke pad analyses. Ik geloof in focussen op het eindresultaat. Niet het testplan is het doel maar het eindresultaat. Het gaat me dus vooral om de haalbaarheid en de testbaarheid van het resultaat. Dan komen de testresultaten vanzelf. En daarmee wil ik zeker niet op de stoel van de projectmanager gaan zitten maar deze wel helpen om samen de snelste en meest effectieve manier neer te zetten om tot waardevolle resultaten te komen.

Mijn natuurlijke houding is misschien wel wat conflict mijdend. Ik geef de voorkeur aan het meenemen van mensen waarbij ik er wel voor zorg dat ik mijn verhaal klaar heb. Als het nodig is ga ik een conflict niet uit de weg maar het is mijn overtuiging dat ik op deze manier succesvoller ben. Misschien is het niet altijd de snelste weg maar ik zorg er zo wel voor dat ik aan de bal blijf en in gesprek blijf met mijn omgeving. Daarbij blijf ik ook altijd zelf nog echt testen en zo houd ik een goed gevoel bij wat er allemaal speelt en krijg ik ook inhoudelijk meer zicht op de kwaliteit van zowel het testwerk als het eindproduct.

Wanneer word jij meestal aan boord gehaald als testmanager en wat heeft jouw eigen voorkeur?

Meestal word ik aangehaakt in al lopende projecten en vaak als projecten in een moeilijke fase verkeren. Eigenlijk vind ik dit ook de meest uitdagende en leukste klussen. Dit is overigens niet gemakkelijk: er wordt al snel een plan van je verwacht en er wordt om actie gevraagd terwijl ik natuurlijk eerst zelf een beeld moet vormen en een flinke kennisachterstand heb ten opzichte de anderen in het project. In het begin is de projectmanager de lastigste. Die vraagt om een plan en daarmee ook een product. Een plan kan echter ook remmend werken en dat zie je ook aan de karikaturen waarmee we begonnen zijn. Ik voorzie als resultaat van dat remmende plan een combinatie van de “daar ben ik niet van” en de “test alleen tegen het ontwerp” testmanager. Als je daar als testmanager en projectmanager aan vast blijft houden, wil dat niet zeggen dat je het beste resultaat neerzet en al helemaal niet als je ook nog eens agile wilt werken. Ook architecten willen nog wel eens een moeilijk te nemen horde zijn, omdat ze geen tijd hebben. Ook zitten ze niet te wachten op kritische vragen vanuit een testtraject, laat staan dat ze willen terugkomen op genomen ontwerpbesluiten.

Voor mij persoonlijk is er het meeste eer te behalen als er al de nodige ellende is. Ik voel me dan uitgedaagd om mijn creatieve oplossingsvermogen. Ik zoek uit wie ik als medestander of tegenstander moet zien en hoe ik met ze om moet gaan. Het krachtenspel tussen opdrachtgever, projectmanager, architecten, het bouwteam en testers is dan al een tijd aan de gang als ik binnenkom en daarin moet ik dan wel eerst weer mijn plek creëren. Dat doe ik door mijn visie te ontwikkelen: het pad naar het beste resultaat.

In de ideale situatie zou ik graag vanaf het begin voor 1 of 2 dagen in de week aan boord zijn en zo de methode en aanpak van het testen al mee te laten nemen in het project vanaf de start. Als testmanager heb ik veel ervaring met afronden van projecten en die kan ik dan ook inzetten om al vanaf het begin beter op het eindresultaat te kunnen sturen. Belangrijke inbreng van de testmanager is de volgorde van het opleveren van werkpakketten uit bouwtrajecten. Die volgorde moet afgestemd zijn op de meest logische volgorde van (integratie)testen. Daar kan meestal veel tijd gewonnen worden, maar dat vereist wel een testmanager die daar een duidelijke visie op heeft. 

Als je een paar adviezen mag geven om succesvoller en met betere resultaten te testen, waar denk je dan aan?

Allereerst mijn advies aan de projectmanager: geef geen opdracht tot een rigide testplan waarmee je denkt op voorhand alles af te kunnen dekken. Je weet vooraf niet alles dus dat plan gaat niet werken, dat gaat remmen. Ga het gezamenlijk uitvinden en besteedt meer tijd aan de uitleg van de aanpak en de doelstellingen van het testen en haak het projectteam en de business hierbij aan. De communicatie hierbij is veel belangrijker dan je focussen op een allesomvattend rigide testplan.

Heb je nog een paar tips om mee te geven aan testmanagers en projectmanagers?

Blijf je altijd afvragen: draagt wat ik doe bij aan het resultaat. Blijf ook gefocust op dat resultaat. Blijf je aanpassen op alle terreinen. Probeer niet alles te kunnen voorspellen en vastpinnen. Als je denkt alle risico’s vooraf te kunnen vastleggen en afdekken, kom je bedrogen uit.

Wees kritisch als het gaat om het beoordelen van de bruikbaarheid, de haalbaarheid en de testbaarheid van het resultaat. Het nadeel van laat aangehaakt worden kan ook een voordeel zijn. Je mag in een gevorderd stadium van een project een onafhankelijk oordeel geven over de haalbaarheid, de maakbaarheid en de toegevoegde waarde van het resultaat. Gebaseerd op wat je op dat moment waarneemt en vrij van de politiek die gespeeld heeft. Gebruik die vrijheid verstandig, maar gebruik hem zeker om tot een beter resultaat te komen.

Risk based testen is lastig, zeker in het begin van een project. Pas wanneer alles loopt, ga je de echte risico’s zien en gaat het leven. Een rigide plan volgen leidt tot reactiviteit en mensen schieten dan vaak in de verdediging in plaats van dat ze gaan bijsturen om wel succesvol te zijn en resultaat te halen.

Bepaal dus een goede volgorde van oplevering, werk goed samen met alle disciplines binnen het project en blijf vooral kritisch en vrij denken om tot het beste resultaat te komen. Want daar gaat het om: het eindresultaat.

Met dank aan Paul de HordeTest Management Group

Blogdetails

24-05-2016
Artikelen

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 088 266 28 70 Stuur ons een bericht