Van hoogst naar mogelijke

 

Ik was en ben perfectionistisch. Ik wil altijd het hoogst mogelijke bereiken. Maar naarmate mijn ervaring toenam, merkte ik iets op: hoe meer je wil bereiken, hoe minder je vaak bereikt. En dit is vooral merkbaar in testautomatisering en testverbetering. Hoe hoger de eisen aan de testautomatisering of de testverbetering, hoe kleiner de kans dat er ook maar iets verbetert.

Wat ik zag gebeuren, is twee verschillende zaken. De eerste is dat verbeteringen, al dan niet door testautomatisering, door de eisen die gesteld werden, nooit in gebruik werden genomen. De perfecte oplossing was in de huidige situatie van het bedrijf of team vaak niet haalbaar, dus gebeurde er uiteindelijk niets.

Het tweede dat ik zag gebeuren had te maken met draagvlak. Ik kan met mijn kennis en ervaring weten wat de perfecte oplossing voor een testautomatiseringsprobleem is. Maar als daaraan getwijfeld wordt, is mijn oplossing niet meer perfect. Verbetering werkt op zijn best als de personen die ze moeten uitvoeren in de oplossing geloven of het minimaal een kans willen geven. Bij twijfel of ongeloof zullen mensen de perfecte oplossing alleen volgen, wanneer je constant blijft controleren. En dat is gewoon niet haalbaar. Uiteindelijk zit je met een perfecte oplossing die niet perfect wordt uitgevoerd, waardoor de perfectie niet gehaald kan worden.

Maar ik schreef dat ik nog steeds perfectionistisch ben. Ja, ik wil nog steeds het hoogst mogelijke bereiken. Ik heb alleen mijn doel verplaatst van “hoogst” naar “mogelijke”. Ik wilde altijd uitgaan van de oplossing die in theorie het beste resultaat zou geven. Het hoogste doel halen, wat maar mogelijk is. Nu wil ik iets anders. Ik wil kijken wat er in de organisatie mogelijk is, en binnen die mogelijkheden het hoogste doel halen.

Het gekke is dat dit perfectionisme vaak gezien wordt als erg pragmatisch. Maar er zit meer achter dan alleen pragmatisme. Ik kijk niet alleen naar wat nu mogelijk is, ik kijk ook of ik de grenzen kan verleggen. Ik kijk of ik meningen van mensen kan veranderen. En ik kijk of ik iets dat binnen de organisatie al bekend is, nu op een andere manier kan inzetten om een ander doel te bereiken.

Ik zorg voor snelle, korte-termijn verbeteringen, om draagvlak te creëren voor grotere, lange-termijn verbeteringen. Dus eerst een paar eenvoudige, maar waardevolle automatische testen om te bouwen aan draagvlak voor de middelen die nodig zijn voor de complexere automatische testen.

Ik wil altijd meer en beter. Maar ik wil tegelijkertijd wel dat het testen en het testproces werkelijk verbetert, en niet wacht tot alles perfect in orde is. Ik wil dat mensen zien dat verbetering kan, waardoor mensen geloven dat meer en beter ook werkelijk iets kan opleveren. Zo komen mogelijkheden open die eerst gesloten waren. Perfectie in stappen, in plaats van in een keer.

Tijd is een factor, geen doel

 

Ik denk dat iedere tester het wel een keer heeft meegemaakt: het project waaraan je werkt moet opeens snel af. Liefst zo snel mogelijk. Vandaag is goed, gisteren was beter. Het gevolg laat zich raden: alles gaat in een noodtreinvaart. En bijna altijd zie je hetzelfde patroon terug: de tijd die zogenaamd is gewonnen in de ontwikkeling, verdwijnt genadeloos in het bugfixen.

En toch blijven we het doen.

Mijn reactie op tijdsdruk is daarom al jaren dezelfde, en die levert regelmatig fronsende wenkbrauwen op: hoe sneller iets moet, hoe langzamer ik test. Niet uit dwarsheid, maar uit ervaring. Want hoe harder een team gaat rennen, hoe sneller de kwaliteit onderuitgaat. Dat is geen mening, dat is een wetmatigheid.

Tegelijk ben ik ook niet naïef. Tijdsdruk bestaat. Soms is het onvermijdelijk. Soms zelfs terecht. Maar laten we stoppen met doen alsof “het moet snel” een volledige boodschap is. Dat is het niet. Het is hooguit de helft.

De andere helft wordt vaak bewust niet uitgesproken: hoeveel risico zijn we bereid te accepteren?
Zolang die vraag niet beantwoord is, betekent “snel” meestal: minder testen, minder nadenken, minder kwaliteit. En daar zou geen enkele tester tevreden mee moeten zijn.

Wat mij stoort, is dat snelheid zelden wordt gepresenteerd als een keuze. Het wordt gebracht als een natuurverschijnsel. Alsof we geen alternatieven hebben. Alsof morgen goed opleveren minder waardevol is dan vandaag half. Terwijl iedereen weet wat de uitkomst is: vandaag snel levert morgen gedoe op. En overmorgen frustratie.

Juist testers zouden hier harder in mogen zijn. Het is niet onze taak om blind mee te sprinten omdat de rest dat doet. Het is onze taak om zichtbaar te maken wat versnellen kost. Kwaliteit laat zich niet dwingen. Die laat zich alleen ruilen tegen stabiliteit, vertrouwen en uiteindelijk tijd.

Dus voordat we weer “even gas geven”, stel ik liever eerst een paar ongemakkelijke vragen. Versnellen we omdat het echt waarde toevoegt? Of alleen omdat iemand heeft geroepen dat het moet? En belangrijker: als dit misgaat, zijn we dan allemaal bereid de consequenties te dragen?

Want nee, we hoeven geen wedstrijd te winnen.
We proberen een goed product te leveren. En dat kost tijd. Altijd.