Dit blog-artikel is de eerste in een serie van 3, waarin we je meenemen in een aantal ontwikkelingen op het gebied van softwaretesten. Waartoe hebben deze ontwikkelingen ons geleid en welke kansen en perspectieven zien wij voor de (nabije) toekomst?
2005: Een groot ICT-project
Na drie maanden ontwerpen, drie maanden bouwen en duizenden uren vergaderen stond er dan op een zonnige vrijdagmiddag eindelijk de eerste versie van het op te leveren bouwsel, op onze met bloed, zweet en tranen bij elkaar onderhandelde testomgeving. Na een half jaar testvoorbereiding, scripts schrijven en onmetelijke Excelsheets vullen, was het leger testers vol energie om direct aan de testuitvoering te beginnen. Er werd diezelfde vrijdagmiddag nog Chinees besteld om toch vooral op dag één de smoke test er nog doorheen te krijgen. Slechts 2 weken waren er nog over om de hele acceptatietest te doorlopen, omdat het bouwtraject wat tegenslagen had gekend. Gelukkig werd het blokje ‘test’ in MS Project in de projectmanagement meeting eigenlijk ‘slack’ (niet het tooltje) genoemd en was er dus geen aanleiding om naar de stuurgroep alvast iets over eventuele uitloop te gaan rapporteren.
Na 6 avonden chinees, 2 overnachtingen op kantoor en 1337 gerapporteerde bugs (de testmanager bestelde bij bug 1000 nog een goede fles champagne!), verspreid over zes versies van hetzelfde Excelsheet en een gerapporteerde voortgang van 22% begon de projectmanager zich toch een beetje zorgen te maken. Voorzichtig meldde de testmanager alvast dat het vrijgaveadvies mogelijk negatief zou uitvallen.
De projectmanager kon de slaap niet vatten de avond voor de laatste stuurgroepvergadering voor de release. Toen ging er ineens een lampje bij hem branden. Het was een vrijgaveadvies. Dat kon de stuurgroep dus prima naast zich neerleggen! En van die 1337 bugs was toch de helft volgens specificatie gebouwd, en de andere helft was vast dubbel. De volgende ochtend rapporteerde hij trots aan de stuurgroep dat de deadline ondanks het moeizame testproces gehaald ging worden. Er waren nog wel een paar restpunten; maar hij verzekerde de stuurgroep dat hij en de rest van het externe team open stonden voor een vervolgtraject om deze puntjes weg te poetsen.
2012: Een groot ICT-project
De tijden zijn veranderd. Niet meer één release per jaar, maar één release elke twee weken! Na tien uur ‘refinen’, zes dagen bouwen en één sprintwisseldag vergaderen, stond op een zonnige vrijdagmiddag eindelijk de eerste versie van het sprintresultaat op de testomgeving. Gelukkig is er een code freeze afgesproken zodat de testers tegen een stabiele omgeving de testscripts (die ze in de zes dagen ervoor gemaakt hebben) uit kunnen voeren. Nadat er op dinsdagavond, de dag voor de demo, tweeënveertig bugs in Jira gerapporteerd waren, begon de product owner zich toch een beetje zorgen te maken over hoe zij de demo kon geven zonder dat iemand dit zou merken. Gelukkig levert de tester geen vrijgaveadvies meer op om te negeren, dus dat scheelt. In Jira maakte ze een nieuwe story “Oplossen bugs vorige sprint” aan, die mooi mee kan in de volgende sprintplanning. Ook weer opgelost.
2017: Een groot ICT-project
Veranderingen komen letterlijk en figuurlijk steeds vaker! Niet meer één release elke twee weken, maar een release meerdere keren per dag. De pipeline deployt namelijk automatisch op acceptatie na een geslaagde regressietest! Na 2 dagen bouwen en tegelijkertijd het schrijven van geautomatiseerde tests was de branch de laatste zonnige middag van de sprint klaar om te mergen. Die extra story zou dus ook nog af komen! Helaas was het niet de enige release: verrassend genoeg hadden alle teams bedacht om op de laatste sprintdag nog een aantal releases te doen. De geautomatiseerde regressietest duurde per release een paar uur en faalde vaak, om redenen die meer zeiden over de stabiliteit van de testomgeving dan de kwaliteit van het product. De product owner begon zich een beetje zorgen te maken: staat mijn release er morgenochtend wel? Gelukkig kon de ontwikkelaar de regressietesten “tijdelijk” uitzetten, zodat de releases een stuk sneller op acceptatie landden. Omdat er geen gefaalde tests waren gerapporteerd werd de release geaccepteerd en in productie gezet.
The more things change, the more they stay the same
Het releaseproces is aanzienlijk versneld in de afgelopen jaren, testers maken tegenwoordig onderdeel uit van het ontwikkelteam en zijn veel directer betrokken bij het ontwerp- en ontwikkelproces. Toch blijft het treintje ontwerp – ontwikkel – test onverminderd bestaan. Testen blijft de laatste wagon, en dus uiteindelijk vaak een ‘hindernis’ op het kritieke pad. Ondanks dat we als testers eerder testen, meer testen in dezelfde tijd en op steeds grotere schaal automatisering toepassen, is de waarde van snel(ler) releasen, als het puntje bij paaltje komt, vaak uiteindelijk hoger dan de waarde die we met onze testen proberen te leveren.
Natuurlijk zijn de testen waardevol en onmisbaar bij het ontwikkelen en opleveren van je product, maar hoe zorg je er als testspecialist voor dat de optimalisatie die is doorgemaakt in het ontwikkeltraject ook zijn maximale weerslag heeft in het testproces? Te vaak is testen toch nog een weinig transparante activiteit met onvoorspelbare output. Een laatste check of hobbel die in plaats van inzicht in de staat van het product, vooral een vinkje moet opleveren.
Volgende week, in deel twee van deze blog gaan we in op mogelijke oorzaken hiervan. Wat betekent slimmer testen voor ontwikkelteams? En hoe zorgen we als testspecialisten ervoor dat onze testen het maximale effect (blijven) leveren?
