Als developer heb ik maar één missie: functionaliteit opleveren. Maar voordat mijn werk naar de klant kan, legt een tester het kritisch naast de requirements en komt met een lijst bugs en bevindingen. Het fiksen daarvan kost me iedere keer weer veel tijd. Tijd die ik niet kan gebruiken om nieuwe features te bouwen… Maar in dit projectdagboek lees je hoe juist deze dagelijkse spanningen leiden tot optimale software.
Maandagochtend, 9 uur. De projectgroep en ik zitten klaar voor de kick-off van een nieuw project. Een project met veel componenten en aardig wat afwisseling. Precies waar ik energie van krijg!
Ikea-kast!
De requirements zijn al opgehaald door onze businessanalisten en de gebruikersinterface staat klaar om gemaakt te worden. Een project als dit voelt als in elkaar zetten van een Ikea-kast waarbij de inbussleutel en de schroeven al klaarliggen. Je hoeft hem alleen nog even in elkaar te zetten.
De eerste week
De eerste week verloopt vlotjes. Iedereen pakt een user story op. We werken in sprints van 2 weken, waarna we een deel opleveren om getest te worden door onze tester. Zo ook na de tweede week. Hoewel de oplevering alleen wat boilerplating bevat met niet al te veel complexe gebruikersinteracties, is er al best wat zichtbaar van wat we hebben gemaakt.
We schuiven de stories die af zijn naar de ‘completed’ status in Azure DevOps en gaan verder met de volgende sprint.
Deze features waren toch af?
Maar dan… Halverwege sprint 2 komt onze tester met bevindingen. En een aardige lijst ook! Bepaalde inputvelden worden niet juist gevalideerd. Bij datumvelden kun je zelfs tekst invoeren. Hier hadden we niet meteen rekening mee gehouden. Het was immers de eerste sprint en we wilden vooral snel meters maken en later naar de eventuele details kijken.
Wéér extra werk in de sprints
De bevindingen zorgen voor 3 extra items op product backlog op DevOps… En dat terwijl we al lekker bezig waren met de volgende items. De volgende sprintoplevering gaat niet anders. Ditmaal komen er 5 extra items bij, terwijl we er 3 konden wegtikken. Wéér extra werk dus… Ditmaal heeft onze tester ook nog een deel van het systeem getest dat nog niet 100% af was. Wij, als developers, waren hiervan op de hoogte. Maar de overdracht is blijkbaar te summier geweest, zodat de tester het niet wist.
Tijd voor een goed gesprek. Ik vertel onze tester dat we op deze manier niet snel genoeg meters maken. Het DevOps-board staat vol belangrijke zaken die we snel willen oppakken. Dat snapt hij natuurlijk ook wel, maar voor hem zijn de randvoorwaarden van sommige taken simpelweg niet goed genoeg gedefinieerd.
De testserver plat? Hoe dan?
Een nieuwe dag en iedereen is weer hard aan het werk. Ook onze tester. Als ik rond een uur of 5 mijn laptop dichtdoe, krijg ik een berichtje van hem. De testomgeving is kapot, en het systeem onbereikbaar…
Zucht…
Dit is mij nog geen enkele keer gebeurd in dit project. Hoe krijgt hij het dan wel voor elkaar? We kunnen er deze sprint echt geen tijdverlies meer bij hebben, dus klap ik mijn laptop weer open en begin het systeem te debuggen. Ik kom er al snel achter dat onze tester een probleem heeft gevonden dat specifiek te maken heeft met het gebruik van Google Chrome. Vandaar dat dit bij mij nog niet was gebeurd!
Halverwege het project: de balans opmaken
Halverwege het project zien we op dat we goed op weg zijn. We leveren resultaat op dat werkt en de klant is meer dan tevreden met het proces. Al voelt het voor mij alsof we pas op een kwart zijn. Waarom? Omdat we veel meer taken hebben voltooid die ‘tussendoor kwamen’ dan de afgesproken items die initieel waren vastgelegd.
Tijdens de retrospective komen nog wel wat meer pijnpunten naar boven. Als ontwikkelaars vinden we het vervelend als mensen onze gemaakte oplossing niet zo gebruiken zoals we bedacht hadden. Als een tester dat naar boven haalt en de boel met zijn vergezochte tests ook nog extra kapot maakt, dan vinden we dat niet fijn.
Je gaat twijfelen aan je eigen kunde. Heb ik iets gemist? Doe ik het verkeerd? Snap ik niet hoe mensen het systeem gaan gebruiken? De harmonie tussen een ontwikkelaar en een tester bestaat uit wederzijdse acceptatie, dat snap ik. Maar leuk vind ik het niet.
Optimale samenwerking = af en toe botsen
Toch zou ik niet aan een groot project willen werken zonder tester. Ik heb nou eenmaal liever dat het tijdens de ontwikkel-iteraties stukgaat dan na de livegang. Dat we soms met elkaar botsen, dat neem ik op de koop toe. Daar waar ontwikkelaars de volledige focus hebben op wat ze moeten maken, hebben testers gevoel voor waarom het gemaakt moet worden. Zo houdt de tester de groep scherp.
