Je zit in de refinement. Een nieuwe story wordt uitgelegd. Iedereen knikt.
Jij ook, maar ondertussen draait er van alles in je hoofd. Wat als iemand dit veld leeg laat? Wat als ze op de terugknop drukken halverwege? Wat als twee gebruikers dit tegelijk doen?
Je noteert het. Je test het straks. En je hebt gelijk.
Zo gaat dat, als je software tester bent.
Zeven van die inzichten. Voor iedereen die ze herkent.
1. "Bij mij werkt het" is geen testrapport
De ontwikkelaar die net een bug heeft opgelost, kijkt je verwachtingsvol aan.
"Bij mij werkt het hoor."
En hij meent het. Zijn lokale omgeving is schoon, zijn cache is leeg, hij heeft precies de juiste testdata klaargezet. Natuurlijk werkt het daar.
Maar dat zegt niets. Niet over wat er gebeurt als een gebruiker met een trage verbinding dezelfde stap probeert. Niet over wat er gebeurt als iemand per ongeluk twee keer op verzenden klikt. Niet over wat de database doet als er vijftig mensen tegelijk door hetzelfde formulier gaan.
Je knikt. Je noteert de testcase. En je test het zelf.
Want jij weet wat de ontwikkelaar bedoelt. Maar jij weet ook wat hij vergeet: lokaal is geen productie.
2. Nee, ik bewaar bugs niet expres voor vlak voor vijf uur
Vrijdagmiddag. Half vijf. De release staat gepland. De release notes zijn al geschreven. En dan vind je hem: een bug. Niet een kleine cosmetische dingetje, maar eentje die er echt toe doet.
De sfeer in de kamer verandert. Iedereen kijkt naar jou.
Alsof jij er iets aan kunt doen dat de bug zich pas laat in de testcyclus openbaart. Alsof jij bewust wacht tot de spanning het hoogst is om dan dramatisch je bevinding te presenteren.
Testers bewaren geen bugs voor het perfecte moment. Dat moment bestaat gewoon niet. Bugs verschijnen wanneer ze verschijnen, en dat is bijna nooit gunstig. Maandagochtend tijdens de standup is ook niet ideaal. Dinsdag na lunch evenmin.
Er is geen goed moment voor een bug die net niet meekomt in de sprint.
Maar vrijdagmiddag voelt altijd extra pijnlijk. Dat weet je. En toch doe je wat je moet doen.
3. Ik test ook dingen die niet in het ticket staan
Er staat een user story. Drie acceptatiecriteria. Heldere omschrijving. Je zou die drie dingen kunnen afvinken en door kunnen naar het volgende ticket.
Maar dat doe je niet.
Want jij weet dat de werkelijkheid anders werkt dan het ticket beschrijft. Jij vraagt je af wat er gebeurt als iemand het formulier op een telefoon invult. Of met een screenreader. Of zonder javascript. Of tegelijk met iemand anders.
Dus je klikt nog even door. Probeert een edge case. En ja hoor: daar is iets.
De scrum master kijkt je aan als je met acht bevindingen komt op een "simpel klepje". Alsof je moeilijk doet.
Maar als je alleen test wat in het ticket staat, kun je de test net zo goed overslaan. Dan had de ontwikkelaar het zelf kunnen controleren.
4. Ik lees de documentatie, maar ik vertrouw hem niet
De nieuwe functionaliteit is gedocumenteerd. Keurig. Met screenshots en alles. Je neemt het door, want het is een goed startpunt.
Maar dan ga je testen.
En het eerste wat je merkt is dat knop X links zit in plaats van rechts. Dat veld Y als verplicht is terwijl de tekst "optioneel" suggereert. Dat de flow drie stappen heeft in plaats van twee.
Niet omdat de documentatie slecht is geschreven. Maar omdat documentatie een momentopname is. Ondertussen is er een sprint geweest, een ontwerpwijziging, een technische keuze. Niemand heeft de documentatie bijgewerkt. Dat is niet erg, het gebeurt.
Maar het betekent wel dat de echte testcase niet in het document staat. Die schrijf jij. Vanuit wat je ziet, niet vanuit wat er beschreven is.
De beste testcases ontstaan precies daar waar de documentatie stopt.
5. Ik snap de user story ook niet altijd
Iedereen knikt tijdens de refinement. Ja, duidelijk. Ligt voor de hand. Volgende punt.
En jij zit met een vraag die je niet goed kunt formuleren. Niet omdat je niet oplet, maar omdat er iets wringt. Een stap die ontbreekt. Een aanname die niet benoemd is. Iets in de logica dat niet klopt maar ook niet makkelijk te omschrijven is.
Als je vraagt "wat bedoelen ze precies met…", ben je weer diegene. Degene die alles wil dichttimmeren.
Maar eigenlijk is het precies andersom. Als jij, de persoon die het straks gaat testen, de user story al niet snapt, hoe moet de ontwikkelaar hem dan bouwen? Precies. Dát is de reden dat je de vraag moet stellen.
Soms laat je het toch gaan. Het is vrijdag, je hebt al drie meetings gehad, en het voelt te klein om nu nog over te beginnen.
Met een klein risico dat je de bug maandag terugvindt.
Als je drie keer moet lezen wat er bedoeld wordt, is het geen user story. Het is een raadsel.
6. Soms hoop ik stiekem dat de demo mislukt
Niet uit boosheid. Niet omdat je iemand iets gunt.
Maar omdat je al weken probeert uit te leggen dat er gaten zitten in de flow. Je hebt het opgeschreven in je testrapport. Je hebt het benoemd in de standup. Je hebt er zelfs een post-it van gemaakt. En toch rolt de release door.
En dan, tijdens de demo, klikt de product owner precies op de plek die jij had gemarkeerd. Het scherm doet iets wat het niet moet doen. Stilte in de kamer.
Het voelt een beetje gemeen om dat op te merken. Dat is het ook, een beetje. Maar het is ook opluchting. Want nu ziet iedereen wat jij al zag. Nu hoef je niet meer te zeggen "maar in mijn testrapport stond dit al". Nu is het er, op het scherm, in real time, voor de hele kamer.
Een falende demo is soms het meest overtuigende testrapport dat er bestaat.
Al had je liever gehad dat ze naar je testrapport hadden geluisterd.
7. Mijn testcases zijn mooier dan de code
Een beetje een schuldige bekentenis. Maar er gaat iets voldaan door een strak gestructureerde testcase. Precondities helder. Stappen logisch. Verwacht resultaat exact. Edge cases meegenomen.
Aan de andere kant van de tafel denkt iemand: "just ship it."
En jij denkt: als ik deze testcase goed opzet, hoef ik hem nooit meer uit te leggen. Dan is hij er. Voor de volgende sprint, de volgende tester, de volgende keer dat iemand vraagt "hoe testten we dit ook alweer?"
Dat is geen perfectionisme. Dat is vakmanschap.
En ja, het is ook een beetje voor jezelf. Omdat het gewoon mooi werk is als het goed zit. Omdat je weet dat goed gedocumenteerd testen niet navelstaren is, het is precies wat je gevraagd wordt te doen.
En eerlijk? Software testers herkennen er meer.
De blik waarmee je een product owner aankijkt als hij "even een kleine aanpassing" voorstelt vlak voor de release. De manier waarop je "heb je het getest?" hoort als een persoonlijke aanval. Het moment dat een bug eigenlijk een feature blijkt te zijn.
Testers praten minder en zien meer. Dat is geen toeval, dat is het vak.
In elk goed team zit iemand die even wacht voordat hij reageert. Die luistert, kijkt, en dan pas zijn mond opendoet. Bij softwareteams is dat meestal de tester. En als die iets zegt, is het de moeite waard om te luisteren.
Dat is precies waarom ze er zijn.
Herken jij dit ook? Of werk jij liever in een team dat dezelfde taal spreekt en je testrapport echt leest voordat de demo live gaat? Kijk dan eens wat Your Test Professionals voor jou kan betekenen.
