Niet zelden verschijnt er in het nieuws een bericht over fouten in de bedrijfsvoering als gevolg van – vaak grote – ICT-trajecten. En dat zou best wel eens kunnen komen, doordat we een beetje boven onze stand leven als het om testen gaat. Ik zal jullie proberen uit te leggen waarom…
Het testvak is in zekere zin niet heel jong meer. De eerste software tests werden immers uitgevoerd kort nadat de eerste regels code gecompileerd werden. De brede schaal waarop organisaties nieuwe software gestructureerd testen, is dat echter wel. Steeds meer dedicated testers dragen bij aan kwalitatief goede code, dat kan ik als testconsultant alleen maar toejuichen. Steeds vaker vindt dit plaats in een agile setting. En op het moment dat we daar net een beetje aan gewend zijn, wordt de druk opgevoerd en staan ‘CI/CD (continuous integration / continuous delivery) of vol inzetten op het automatiseren van bijvoorbeeld end-to-end regressietests bovenaan de wensenlijst.
Laten we eerst eens kijken naar het agile ontwikkelen van nieuwe software. De methodiek is daadwerkelijk een verademing ten opzichte van de traditionele waterval methode. Dynamiek tegenover gestage ontwikkeling. Interactie en feedback tegenover eilandjes die ieder hun eigen zaakjes afhandelen.
Testen in een agile tempo
Agile werken vraagt echter om een groot gevoel van verantwoordelijkheid van alle teamleden en het strikt nakomen van afspraken die worden gemaakt. Als beide niet of in mindere mate aan de orde zijn, ontstaat al snel een situatie waarin nieuw ontwikkelde functionaliteit pas aan het eind van de sprint (en dus onder tijdsdruk) wordt getest. En misschien nog zorgelijker: de tijd voor een solide regressietest ontbreekt. Dat maakt het ineens niet zo vreemd dat er pas op de productieomgeving grote problemen naar boven komen. Ik vermoed dat vooral de grotere organisaties daar last van hebben, al dan niet onder druk van releases die vooraf de klant zijn aangekondigd.
Zoals een verdediger bij voetbal vaak het slot op de deur is, zijn wij dat als testers ook!
Het in hoog tempo najagen van nieuwe ontwikkelingen gaat vaak ten koste van een goede basis. Testen is niet zo moeilijk, is daarbij de aanname. Goed en consequent testen is dat echter wel. In veel ontwikkelomgevingen staat de techniek (van coderen en automatiseren) naar mijn idee iets te vaak centraal waardoor er geen oog is voor het belang van gedegen testen. Het functioneel goed beschrijven van nieuwe software en het goed testen daarvan wordt hierdoor minder urgent gevonden. De hang naar CI/CD is een voorbeeld waarin deze ‘squeeze’ optreedt. Maar deze stap kan je alleen succesvol maken als de onderliggende processen volwassen zijn ingericht. Dus ook het testproces! Ga je met CI/CD aan de slag in een omgeving waar testen nog in de kinderschoenen staat, geef ik je op een briefje dat het traject mislukt of dat er vaker problemen in productie optreden dan voor de transitie.
En daar wringt dus de schoen. In voetbal termen gesproken: je mag en moet bij een 8-0 voorsprong de bal nog steeds terug op de keeper kunnen spelen. Niet elke bal moet met alle risico’s van dien door de verdediger blind naar voren worden gespeeld. Als je denkt dat je al er bent, ligt verlies om de hoek.
Slot op de deur
Deze blog is bedoeld als een constructief waarschuwend vingertje naar onszelf als testconsultants en de mensen met wie wij als testers direct samenwerken. Hou in de gaten dat de basis van het testen blijft staan. En ook dan is het best mogelijk om tegelijkertijd de blik op de toekomst te richten. Zoals een verdediger vaak het slot op de deur is, zijn wij dat als testers ook. Breng rust door terug te grijpen naar het fundament. Je collega’s zullen zien dat het helpt om het overzicht te bewaren.
