Een tip voor testers
De volgende tekst schreef ik naar aanleiding van een bericht van Maartje van Oorschot op LinkedIn, waarin ze auteurs zocht die mee wilden schrijven aan het tweede deel van 101 Tips voor Testers. Na mijn tip volgt Maartjes reactie.
*
Maak ontwikkelaars verantwoordelijk voor testen!
Elke softwareontwikkelaar weet dat hij zijn werk goed moet testen. Waarom glippen de meest voor de hand liggende bugs er dan toch doorheen? Omdat testen bij testers is belegd. Dat klinkt voor programmeurs verleidelijk efficiënt: waarom tijd besteden aan het schrijven van tests als iemand het werk toch nog naloopt? Deze taakverdeling nodigt uit tot lagere codekwaliteit en legt de pijn daarvan bij testers.
Verschuif de verantwoordelijkheid naar waar die hoort. Programmeren en testen zijn twee kanten van dezelfde munt. Het is aan ontwikkelaars om te bewijzen dat de code werkt zoals bedoeld, niet aan testers om dat te controleren. Begin elke feature met het gezamenlijk opstellen van testcases die, als ze slagen, jullie voldoende vertrouwen geven om te releasen. Automatiseer de tests tijdens de ontwikkeling één voor één en werk de lijst bij zodra inzichten veranderen. Dat gesprek schept een gedeeld beeld van de requirements en brengt ontwikkelaars en testers dichter bij elkaar. Zo vormen we echt een team!
Karl van Heijster
Softwareontwikkelaar
Stichting Cito
*
Ik schrok me kapot toen ik deze tip voor het eerst las. Als tester van het eerste uur was mijn reflex direct: “Wacht even, als de ontwikkelaars verantwoordelijk worden voor het testen, dan gaat de slager toch zijn eigen vlees keuren?”
Mijn nekharen gingen eerlijk gezegd even overeind staan. Want laten we wel wezen: gaat hij nou werkelijk beweren dat testers niet meer nodig zijn?? Het voelde als een directe aanval op mijn bestaansrecht.
Maar toen ik de emotie parkeerde, zag ik de bevrijding die eronder zit.
Het gaat er namelijk niet om dat die keuring onfeilbaar is. Het gaat erom dat de ‘muur’ tussen creatie en validatie wordt gesloopt. Wanneer ontwikkelaars hun eigen code niet meer blind over de schutting gooien, ontstaat er voor ons juist ruimte. Ruimte om te stoppen met het eindeloos afvinken van basale logica en eindelijk te focussen op de echte waarde: de diepgang, de randgevallen en de overkoepelende kwaliteit waar een programmeur (hoe goed ook) vaak blind voor is.
Karl weigert software te zien als een zielloze lopende band. In zijn tip stelt hij messcherp dat programmeren en testen simpelweg twee kanten van dezelfde munt zijn. Testen is voor hem geen eindstation, maar een gedeelde taal. Door de verantwoordelijkheid neer te leggen waar de code ontstaat, dwingt hij een dialoog af nog vóórdat de eerste regel code is getypt. Dat is geen bedreiging voor ons vak, dat is de ultieme erkenning van kwaliteitsbewustzijn.
Pas als we het samen doen, wordt softwareontwikkeling weer een echt ambacht. De ontwikkelaar borgt de fundamenten, zodat wij als testers eindelijk de diepte in kunnen om het verschil te maken tussen ‘het werkt’ en ‘het is kwaliteit’.