Tag Tester (Rol)
Een tip voor testers
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.
De vergeten tester
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
De vergeten tester
Twee dingen kunnen tegelijkertijd waar zijn. (1) Ik vind de tester de belangrijkste rol hebben in het team. (2) Ik wil geen tester in het team. – Ik wil haast zeggen: de rol van de tester is te belangrijk om bij een tester neer te leggen, maar die uitspraak is makkelijk te misinterpreteren en nodeloos provocerend. En toch…
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?
First time right?
Na afloop van mijn praatje kreeg ik de vraag of ik geloof in het idee van first time right. Mijn antwoord was: “Ik geloof niet dat er zoiets bestaat als first time right. Maar ik geloof wel in first time een stuk beter dan we het nu doen.” Tijd om dat antwoord verder uit te werken, was er op dat moment niet. Maar de vraag bleef wel in mijn achterhoofd spoken. Is het mogelijk om een systeem in één keer goed te bouwen?
De tester als code reviewer
Mijn team heeft onze tester onlangs tot verplichte reviewer gemaakt voor elk pull request (PR). Hij heeft een heel specifieke opdracht – drie, eigenlijk: 1. Ga na of het PR unit- of integratietests bevat. Zo nee, keur het PR dan af. 2. Ga na of je de unit- en/of integratietests kunt begrijpen. Zo nee, keur het PR dan af. 3. Ga op basis van de unit- en/of integratietests na of de code werkt zoals bedoeld. Zo nee, keur het PR dan af. Pas als aan alle drie voorwaarden is voldaan, is het PR klaar om naar de main branch te mergen.