Auteur: Kees Blokland ● Kees.Blokland@Polteq.com
Redactie: Eric Spaargaren
Verschilt de rol van testmanager bij de leverancier wezenlijk van die bij de opdrachtgever? Beide rollen heb ik leren kennen en in beide rollen worstel ik zo nu en dan. Graag deel ik een aantal gedachten en overwegingen over enerzijds de spanning en anderzijds de samenwerking tussen beiden. Als ik hiermee meer verwarring sticht dan helderheid creëer, dan tekent dat de situatie waarin beide testmanagers zich ten opzicht van elkaar bewegen. (Pin me trouwens niet vast op de functienaam testmanager, het gaat om wie de ’testpet’ op heeft.)
Testmanager van de klant
Het lijkt zo eenvoudig: de opdracht is om de software te (laten) testen en op basis van de testresultaten aan te geven in hoeverre het een goed idee is om de software te accepteren. Je vertegenwoordigt de klant en je bent samen met de acceptatietesters kritisch op de software. Je spreekt de leverancier aan op problemen in de software en andere zaken, zoals niet op tijd leveren of niet leveren wat contractueel is afgesproken.
Testmanager van de bouwer
Het lijkt zo eenvoudig: de opdracht is om de software te (laten) testen en op basis van de testresultaten aan te geven in hoeverre het een goed idee is om de software te leveren. Je vertegenwoordigt de bouwer en bent samen met de testers en ontwikkelaars kritisch op de software. Je geeft aan welke problemen er nog in de software zitten en wat de status is van de software ten opzichte van wat er contractueel is afgesproken.
Haast letterlijk dezelfde taakomschrijving, een omschrijving die suggereert dat aan hetzelfde doel wordt gewerkt: succesvolle inzet van software dat de klant graag wil gebruiken en de bouwer graag wil leveren. Problemen in de software staan dat in de weg, dus hoe beter de inzichten daarin zijn, hoe beter belanghebbenden besluiten kunnen nemen, zoals over ingebruikname.
Echter…
Ervaringen in de rol van testmanager van de klant
In die rol was ik uiterst kritisch naar de bouwers: ik wilde bewijs van goed testen zien en hield metrics bij om daar uit af te leiden. De insteek bij mijn opdrachtgevers leek: we moeten de bouwer niet vertrouwen, want minder testen is minder kosten en dan houdt de bouwer meer € over ten koste van ‘ons’. Met die basis van wantrouwen was ik op zoek naar olifantenpaadjes die de bouwer volgde om op te leveren met minder testdekking. Het aantal acceptatietesters was beperkt, dus moest na oplevering van de software niet teveel testverantwoordelijkheid voor de klantorganisatie overblijven.
Ervaringen in de rol van testmanager van de bouwer
In die rol trachtte ik de ontwikkelteams voldoende te laten testen op alle niveaus, dus unit testen, systeemtesten en ketentesten en op alle niveaus ook regressietesten, liefst geautomatiseerd. En ik oefende druk uit om bugs opgelost te krijgen. Intussen bouwde zich het beeld op van de kwaliteit van de software en welke problemen er waren gevonden. ’Management’ wilde de klant niet ’al te wijs’ te maken. Als testmanager weet je veel over wat er mankeert maar voordat die informatie bij de klant aankomt, zijn daar een pakje kleurpotloden overheen gegaan. Rood (helemaal niet goed) wordt oranje, oranje wordt geel en geel wordt donkergroen (bijna goed). Dat werk.
Spanning
Zo beschouwd lijken de doelstellingen van de beide testmanagerrollen helemaal niet gelijk te zijn. Dat vindt zijn oorzaak in spanning tussen klant en bouwer die verschillende oorzaken kan hebben. Slechte ervaringen, geldgebrek, lastig te halen deadlines, maar ook botsende persoonlijkheden van belanghebbenden kunnen een rol spelen. Dat begrijp ik wel, maar raken we dan het doel van succesvolle ingebruikname van de software niet uit het zicht? Zou het niet beter zijn als de testmanagers een zekere afstand nemen van die spanning? Dat zij ’hun management’ laten omgaan met discussies over verwachtingen, planningen, escalaties, enzovoort en dat zij vooral de testsamenwerking zoeken tussen klant en bouwer, waarbij de testdekking wordt afgestemd, in de wetenschap dat het aan beide zijden allemaal geen rozengeur en maneschijn is? Een beetje zoals landen die tegenover elkaar staan informatie met elkaar delen vanwege een gezamenlijk doel (of vijand). Op informeel niveau informatie uitwisselen dat misschien van hogerhand later wordt ontkend… of draaf ik nu een beetje door?
Gezamenlijk streven
Hoe dan ook, ik denk dat de mensen die betrokken zijn bij testen aan beide zijden van de grens tussen klant en bouwer veel aan elkaar kunnen hebben. Ik zou testmanagers willen uitdagen om zich minder vanuit ’de formele positie van de opdrachtgever’ op te stellen en ruimte te zoeken om met de ’andere partij’ zo goed mogelijk het testen af te stemmen. Niet om aan te tonen waarom de bouwer het nog niet goed heeft gedaan, of aan te tonen dat de software formeel voldoet en de klant het wel moet accepteren, maar om zoveel mogelijk nuttige informatie te vergaren over de software. Beslissers aan beide zijden kunnen uit die informatie natuurlijk alsnog hun eigen conclusies trekken, maar het verkleint de kans op problemen na het in productie nemen van de software.
Herkenbaar Kees en goed om dat spanningsveld te benoemen. Wij worden geacht politiek sensitief te zijn, maar waak ervoor dat je niet teveel voor één van de karretjes wordt gespannen. Het gezamenlijke doel van een goed product is op de langere termijn vaak voor beiden het meest waardevol.
Kees, ik heb je artikel met veel interesse gelezen. Heel veel herkenning.
Als er een testmanager wordt aangesteld ergens dan kan hij mijn inziens met 4 type inslag worden aangesteld. 2 zijn inderdaad zoals die jij beschreef, 1 is de service verlener (minion), 2 is de toezichthouder op de regels (cop). er zijn er 2 meer, vraag mij maar eens t.z.t. welke de andere 2 zijn!
Vervolgens zijn z’n belangrijkste taken: planning en chronologische volgorde van testen bepalen. (hoofdzakelijk vanuit ervaring en inzicht t.o.v. junioren) Er kunnen namelijk 2 uitgangspunten zijn: 1) de software wordt nieuw gebouwd. 2) de software was er al, de manager wordt aangesteld.
In geval 2 is mijn ervaring is er in 90% van de gevallen: chaos, wanorde, te weinig getest, geen systematiek, etc, etc. of wat ik zelf noem: ‘damage controll’.
Oftewel je kunt het niet opbouwen zoals je idealiter zou doen als je het testproces van scratch af aan zou opzetten (wel genoeg aandacht voor unit testen, wel genoeg aandacht voor testautomatisering wel genoeg noem de hele rimbam maar op, alles waar wij wel op zouden letten).
Dus in dat tweede geval is de kans op haantjes, mensen die een mening hebben maar geen sjoege verstand van testen inderdaad enorm groot. Dan is het inderdaad een kwestie van daarboven staan en laten zien dat je weet hoe de vork in de steel zit.
Dat is het verschil tussen een leider en een manager. https://www.desteven.nl/leiderschapsontwikkeling/leiderschapsprogramma/leiderschapsvormen/leiders-managers
MoSCoW-test opstellen is ook een aanrader (must test, should test,….)
Alleen past dat soms wat minder goed in de SCRUM Sprint, maar je kunt hem dynamisch maken en je kunt die persoonlijke toevoeging dropdown in Jira toevoegen. (goede ervaringen mee)
Mijn ervaring is dat de samenwerking het beste resultaat oplevert, waarbij je in eerste instantie veel achterdocht ervaart bij de testmanager van de leverancier. Vanuit de klant bezien wil je namelijk grip hebben op de testresultaten van de bouwer, maar die krijg je niet zomaar! Door vooral de samenwerking op te zoeken en aan te geven wat de bouwer heeft getest, is niet meer nodig om te testen door de klant. Heb je interesse in de unittesten? Nee, maar wel in de testgevallen van systeemtest en eventuele ketentest. Dat betekent ook, je als klant kwetsbaar opstellen! Geef ook jou testgevallen! Beoordeel elkaar testgevallen! Door deze brug te slaan, maak je de testperiode korter. Helaas blijkt dan, dat juist de requirements onduidelijk waren. Door de testgevallen van de leverancier te beoordelen, kan je dus tijd winnen en kosten verlagen.
Mooi dat het wat losmaakt!