Als software tester heb ik maar één missie: zorgen dat de opgeleverde software van topkwaliteit is. Iedere keer als het developmentteam nieuwe functionaliteit oplevert, leg ik die kritisch naast de requirements en kom ik met een lijst bugs en bevindingen. Het fiksen daarvan kost de developers tijd, en dat vinden ze niet altijd leuk. Maar in dit projectdagboek lees je hoe juist deze dagelijkse spanningen leiden tot optimale software.
Maandagochtend, 9 uur
Een nieuw project gaat van start. Ik was niet uitgenodigd voor de kick-off, maar last minute denkt de lead developer er gelukkig aan om ook de tester uit te nodigen. Het wordt een goede start met fijne mensen. Precies waar ik energie van krijg!
De requirements voor het project zijn opgehaald door onze businessanalisten en tijdens de kick-off krijgen we vooral boomstructuren en titels te zien. Een snelle blik op de backlog leert me dat daar nog veel openstaande vragen in staan. Ook zijn er nog niet overal acceptatiecriteria voor. Ik zie mijn collega’s om me heen geduldig mee kijken naar de presentatie. Zij zien de toekomst zonder zorgen tegemoet. Alsof ze een Ikea-kast in elkaar gaan zetten…
De eerste week
De eerste week werkt het team hard, maar ik kan als tester nog niet zo veel. We werken in sprints van 2 weken, dus na oplevering van de eerste sprint – terwijl de ontwikkelaars aan de functionaliteit van sprint 2 werken – kan ik de release van sprint 1 testen. In plaats van af te wachten bereid ik tijdens deze sprint alvast tests voor. Ik krijg snel antwoord op vragen die ik stel en ik kan zelfs af en toe iemand behoeden voor een gemist requirement. Snel overleg met de klant levert een meer complete feature op, zodat we dat later niet via een bevinding hoeven op te lossen.
Wanneer is een feature ‘af’?
Na de demo van sprint 1 mag ik echt gaan testen. De user stories die gebouwd zijn gaan naar ‘completed’. Maar… als ze nog niet getest zijn, zijn ze dan ‘af’? Ik noteer een puntje voor de retrospective om te kijken of we dat proces kunnen stroomlijnen en ga snel verder met testen. Ondanks veel overleg tijdens sprint 1 vind ik nog best wat dingen die niet in orde lijken.
Het is ongeveer een 50/50 verdeling van bugs en bevindingen die resulteren in een aanvulling van de requirements. Geen validatie op een datumveld is bijvoorbeeld geen showstopper, maar als je allerlei verschillende formaten en ook platte tekst toestaat heb je binnen de kortste keren een dataset waar niet mee te werken is. Dat komt dus op mijn lijst.
We hebben de afspraak dat we de bevindingen toevoegen in sprint 2, waardoor deze al snel in scope groeit. Naast de geplande werkzaamheden, moeten de developers ook nog met mijn bevindingen aan het werk!
Vertraging door steeds groeiende sprints
De volgende sprint gaat hetzelfde. Opgejaagd door de geplande features en mijn toevoegingen gaan de ontwikkelaars hard aan de slag. De nieuwe features geven nieuwe bevindingen en de gefikste bugs brengen af en toe een nieuw probleempje boven water. In plaats van minder bevindingen, verschijnen er dus juist meer op de sprint.
Ik overleg met de lead developer. We gaan niet snel genoeg met opleveren van nieuwe functionaliteit, maar de zaken die ik vind zijn te belangrijk om te laten liggen. Wat nu? Ik snap het probleem en leg deels de schuld bij de requirements. Als de randvoorwaarden om software te bouwen niet duidelijk genoeg zijn, worden er al snel zaken vergeten die kunnen resulteren in een bevinding. We besluiten om wat meer tijd in te ruimen voor refinements om ervoor te zorgen dat requirements beter uitgewerkt in de sprint verschijnen.
De testserver gaat plat
Een nieuwe dag. De testomgeving wordt niet automatisch bijgewerkt, maar als ik een nieuwe build nodig heb, kan ik zelf een release doen. Zo kan ik altijd met de nieuwste versie verder. Rond half vijf ‘s middags doe ik een nieuwe release, zodat ik nog wat fixes van die middag kan checken.
Krak.
De testomgeving doet vervolgens niets meer. Balen, maar beter nu dan morgen, vlak voor de daily. Ik laat een bericht achter op de team-chat, in de hoop dat een vroege vogel er morgenochtend naar kijkt. Tot mijn vreugde zie ik dat de lead developer nog even tijd maakt om ernaar te kijken. Samen proberen we verschillende browsers uit en na een uurtje heeft hij het probleem te pakken: er is probleem, specifiek voor de Chrome-browser. Dat hebben we snel opgelost.
Halverwege het project: de balans opmaken
Halverwege het project maken we de balans op. We leveren duidelijk resultaten op die werken en uit de acceptatietesten van de klant komen weinig bevindingen. Ik ben trots op de features die we uiteindelijk hebben uitgeleverd. Ze zijn compleet en werken goed. Daarnaast hebben we verbeteringen doorgevoerd die niet waren opgenomen in het eerste plan. We hebben niet alle geplande features op kunnen leveren, maar ik maak liever iets goeds. Als het halen van de planning leidt tot middelmatigheid, dan laat ik de planning liever voor wat hij is.
Tijdens de retrospective komen wel wat pijnpunten naar boven. De developers vinden sommige bevindingen die ze moesten fiksen vergezocht. “We snappen allemaal dat hackers soms rare fratsen uithalen,” is de boodschap.
“Maar we verwachten toch niet dat een gebruiker expres zal proberen om een tekstbestand van een paar miljoen tekens in een veld te zetten.”
Ik snap de klachten, maar leg ook uit dat deze exotische testen bijdragen aan de robuustheid van het product. We spreken af dat ik een standaard ga opleveren van waar verschillende elementen aan moeten voldoen op gebieden als SQL-injectie en validatie. Dan kunnen we een checklist vastleggen die we dan niet in iedere user story hoeven te herhalen.
Positieve inbreng is er ook bij deze evaluatie. De afgelopen sprints hebben we gemerkt dat we elkaar nodig hebben. Zonder de developers duren mijn checks veel langer. Zij weten exact waar ik zaken kan vinden. Door het vroege overleg hebben we bugs kunnen voorkomen.
Optimale samenwerking = samen uitvinden wat ‘perfect genoeg’ is
We spreken af dat we de komende sprints meer tijd vrij maken voor het oplossen van de bugs en iets rustiger aan doen met het inplannen van nieuwe functionaliteit. Daarnaast zorgen we in overleg met de klant dat niet alle bevindingen ook meteen op de sprint komen. We hoeven niet alle problemen die gevonden worden direct op te lossen. Ook al wil ik het liefst een perfecte applicatie, het is belangrijk om verschil te zien tussen verbeteringen en problemen.
Mijn collega’s maken mooie features en die moeten doorgezet worden. Soms kan dat best met known issues. Het is beter om iets moois te tonen met een bekend probleem dan om niets te laten zien omdat het nog niet perfect genoeg is.
