Door Jacqueline Frank ● j.frank@eclipseIT.nl ● @jackiejackjack
Zo. Daar stond ik dan. Mijn ‘gehoor’ druppelde langzaam binnen op 14 mei 2014 om 15.40 in zaal 8-9 van het NBC Congrescentrum in Nieuwegein. Het werd een volle zaal voor mijn presentatie ‘Seriously? Hoe te roeien met de riemen die je (niet) hebt’. Mijn ervaringsverhaal over mijn eerste testopdracht. Tevens mijn eerste ‘conference talk’.
Ik heb verteld over hoe ik het testvak ingerold ben, een stoomcursus TMap Next kreeg en na een succesvolle intake aan de slag mocht bij mijn eerste klant. Hoe leuk! En spannend! Dit klusje gingen we klaren, hoe dan ook! Uiteindelijk bleek dit makkelijker gezegd dan gedaan, aangezien er nauwelijks tot geen requirements voor handen waren en er nauwelijks tijd was om écht ergens over na te denken. De Go Live datum werd meerdere keren met een paar weken verschoven en na elk uitstel, gingen we met z’n allen nóg een stapje harder lopen in de hoop bij de volgende Go Live datum wél klaar te zijn.
In het begin hebben we geprobeerd om requirements boven tafel te krijgen, om dingen vast te leggen en zodoende een testbasis te creëren zodat we volgens TMap konden gaan testen. Dat idee hebben we uiteindelijk los moeten laten en zijn we meer ‘verkennend’ aan de slag gegaan – om te testen, maar ook om te leren wat de applicatie nou precies deed en hoe het werkte. Exploratory Testing, maar dan zonder dat we wisten dat dat zo heette… Onze testresultaten en bevindingen legden we vast in een testrapportje, de issues (bugs of change requests) kwamen in het bevindingenregistratiesysteem terecht. Veel bugs, heel veel bugs. En change requests.
Het onderscheid tussen bugs en change requests was zonder documentatie alleen niet altijd even eenduidig. Uiteindelijk gebruikten we grofweg deze vuistregels: dingen die gewoon echt niet werken en ‘must haves’ zijn bugs; ‘nice to haves’ en compleet andere wensen zijn change requests. Niets was overigens eenduidig bij deze klant: weinig dingen stonden echt vast, wat zelfs twee dagen vóór de uiteindelijke/definitieve Go Live datum nog leidde tot een gewijzigde Deal Breaker List. Een lijst die opgesteld was om aan te geven wat er minimaal in de eerste versie van de applicatie moest zitten – een lijst die leidend was geweest bij de prioritering van taken en issues.
Maar natuurlijk heb ik ook verteld dat ik in eerste instantie geen idee had: dat ik niet eens wist dat je bij een Stand Up ook echt moest gaan staan en dat ik in de eerste week na elke Stand Up naar mijn computer toe holde om alle nieuwe termen die ik had gehoord (en had weten te onthouden) te googlen. Zo leerde ik beetje bij beetje het testvak kennen en leerde ik roeien met de riemen die ik had. Ik maakte in mijn eerste opdracht veel ‘seriously-momenten’ mee en heb geprobeerd die ook in mijn presentatie te stoppen door te werken met quotes. Bijvoorbeeld: ‘The Cookie Policy is… that the testers bring us cookies on Friday!’ En de uitspraak van een ontwikkelaar na het horen van een nieuwe klantwens: ‘Ja, ze wil elke keer iets anders… That’s not the way it works.’ Een verstoorde klant-leverancier verhouding was overigens precies wat dit project nodig had (NOT!)… Dit had historische redenen, maar zorgde er wel voor dat ik als tester tussen twee vuren zat en constant een balans moest zoeken tussen aan de ene kant zorgen dat de business kreeg wat ze nodig had en aan de andere kant zorgen dat de ontwikkelaars niet het idee kregen dat ze niets te zeggen hadden.
Tijdens mijn presentatie vroeg ik aan het publiek hoe zij zouden gaan testen, gegeven de context die ik zojuist geschetst had. Eén iemand riep dat hij het oude platform als testbasis zou gebruiken. Dit was een optie die ik zelf eigenlijk nooit had overwogen, wij waren altijd uitgegaan van het tot dan toe gebouwde (nieuwe) platform. En dat terwijl het nieuwe platform moest gaan doen wat het oude al deed (en een beetje meer). Met deze uitleg begon ik mijn presentatie en vlak daarna vertelde ik dat er eigenlijk nooit een inventarisatie gemaakt was van wat het oude platform eigenlijk allemaal deed (en waar het nieuwe platform dus minimaal aan moest voldoen). Maar hoe kwam het nou dat wij nooit bedacht hadden om het oude platform eens grondig uit te spitten? Tijdens mijn presentatie had ik geen antwoord op die vraag, ik wist het echt niet. Inmiddels heb ik er over na kunnen denken en heb ik twee mogelijke verklaringen.
De eerste is dat ik er zelf misschien pas veel later achter kwam dat het nieuwe platform minimaal moest gaan doen wat het oude deed, dus dat ik dat aan het begin helemaal nog niet wist. En dat ik mijn publiek daarmee eigenlijk meer context/informatie heb gegeven dan ik zelf had. Ik had zelfs geen toegang tot het oude platform! En daarmee kom ik op de tweede verklaring: ik ben (te veel?) meegegaan in de cultuur van de organisatie waarin de korte termijn altijd voorrang kreeg op de lange termijn, waarin altijd een gevoel van tijdsdruk en ‘tijd te kort’ hing, waarin nooit tijd gemaakt werd om eens goed over dingen na te denken. Het oude platform ging weg, dus waarom daar nog tijd in stoppen? Het was beter om ons te richten op het nieuwe platform – dat was immers het platform dat getest moest worden en daar was al nauwelijks tijd voor…
Na afloop kreeg ik de vraag of ik het anders zou doen, als ik het opnieuw zou moeten doen. Ja, zeker wel! Ik zou Exploratory Testing veel bewuster inzetten, ik zou beter nadenken over wat nou écht bevindingen zijn die opgelost en dus geregistreerd moeten worden zodat er geen ‘wildgroei’ aan bevindingen optreedt, ik zou me minder gek laten maken door het constante gevoel van tijdsdruk, ik zou meer gaan staan voor mijn eigen ‘testmening’ (dat het bijvoorbeeld niet goed is om gebruikers vrij toegang tot het bevindingenregistratiesysteem te geven en dat niet altijd iedereen kan testen), ik zou vanaf dag één de verwachtingen beter managen (dat je geen kwaliteit in een applicatie kunt testen, bijvoorbeeld) en ik zou me persoonlijk minder verantwoordelijk voelen voor het gehele project, een opmerking die ook vanuit de zaal werd gemaakt en waar ik erg dankbaar voor was.
Ik denk dat ik in mijn eerste testopdracht in zo’n beetje alle valkuilen gestapt ben waar ik als beginnende tester in had kunnen stappen, maar ik denk ook dat ik in mijn eerste testopdracht heel veel situaties tegengekomen ben die maar zelden allemaal samenkomen in één opdracht. Het bleek in ieder geval een zeer herkenbaar verhaal voor mijn publiek en er is hartelijk gelachen om mijn ‘ontboezemingen’. Wat mij betreft een zeer geslaagde presentatie!
NieuwsMagazine
Hoe herkenbaar is dit voor mij, leuk geschreven verhaal 🙂