De kijk van Kees: just in time testmanagement

Auteur: Kees Blokland ● kees.blokland@polteq.com

Timing is alles. Te vroeg een plan helemaal uitschrijven lukt niet vanwege ontbrekende informatie. Te laat heeft geen zin meer. Van een testmanager wordt een verhaal verwacht waar het allemaal in staat: wat ga je testen, hoe ga je testen en wanneer gebeurt dat? Ook in Agile projecten voor de E2E test en gebruikersacceptatie. Hoe zorg je ervoor dat testmanagementinformatie op het juiste moment beschikbaar komt?
Trekken, niet duwen
Het just-in-time beginsel, dat een belangrijke rol speelt bij Lean, Scrum en Kanban geeft het antwoord: je gaat pas iets maken op het moment dat het (bijna) nodig is. Preciezer: je start op het moment dat het nodig is minus de tijd die nodig is om het te realiseren, plus een klein buffertje om tegenvallers op te vangen. De mensen die bekend zijn met de Theory of Constraints herkennen dit mechanisme.
Waste
Wanneer is bijvoorbeeld een MasterTestPlan nodig? Ik ken organisaties waar zo’n document voorwaarde is voor het passeren van een projectbeslismoment. ‘Schrijf jij even het MTP, dan kunnen we verder.’ Daar loop ik vast: een sjabloon met lege bladzijden staart me aan en de paragraafkopjes vragen me om inhoud die met de beste wil van de wereld nog niet is te geven. Helaas gaan velen dan over tot het copy-pasten uit oude documenten en creëren daarmee ‘waste’.
Vroeg in een project praat ik projectleden liever bij over testen aan de hand van een mindmap of een powerpoint. Dat kost minder inspanning dan het schrijven van een tekstdocument, communiceert makkelijker, wekt niet de suggestie dat we het allemaal al weten en het bijhouden van wijzigingen is makkelijker. Dat laatste brengt me trouwens op het punt van updates: ik moet wel continu alert blijven dat wezenlijk nieuwe informatie (bijvoorbeeld gewijzigde scope) wordt gedeeld met betrokkenen.
Te vroeg
Gek genoeg kun je ook te vroeg zijn om je inmiddels complete visie op testen te delen binnen het project. Voor een BI-migratieproject had ik een powerpoint-presentatie gemaakt met een uitleg van diverse testonderwerpen. De leden van het projectteam voelden nog niet de urgentie om alle testpunten meteen op te pakken, want er waren nog allerlei andere zaken die hun aandacht vroegen. In de loop van het project kwamen de onderwerpen alsnog aan de orde. Voorbeelden:

• Hoe bepalen we de testdiepgang? Toen deze vraag opkwam, waren de geesten rijp voor een risicoanalyse.
• Hoe houden we bij wat we getest hebben? Een eenvoudig register in Excel was voldoende.
• Waar moeten we op letten bij het testen van een rapport? Daarvoor schreef ik een korte instructie (de teststrategie) voor de functioneel beheerder.
• Hoe kan de functioneel beheerder tests die worden bedacht later hergebruiken? Door de functioneel beheerder een testdocument te laten schrijven met een vinklijstje wat getest wordt met daarbij de bevindingen.
• Hoe moeten we end-to-end testen inrichten? Die was jammer: bij de planning van softwarebouw was niet gekeken naar end-to-end (stond wel in mijn powerpoint aan het begin, you win some, you lose some).

De truc is om het project een stap (maar niet meer dan een stap) voor te zijn en het materiaal, de visie, het idee et cetera klaar te hebben op het moment dat de vraag zich aandient.
Just in time.