Comfortzone

Hoewel het lang niet voor ieder Nederlands bedrijf interessant is om continu wijzigingen aan te brengen in zijn software, is het wel zinvol om te begrijpen waarom de eerdergenoemde bedrijven succesvol zijn in een markt waar zovelen ten onder zijn gegaan. Het succes van deze bedrijven is namelijk niet uit de lucht komen vallen. Het is rechtstreeks toe te schrijven aan een expliciete keuze voor kwalitatief hoogwaardige software. Niet alleen leidt een sterke focus op een uitstekende softwarekwaliteit op termijn tot structureel lagere ontwikkelkosten, ook stelt vakkundig gebouwde en geteste software een organisatie in staat om een steeds wijzigende klantvraag makkelijk te absorberen. Maar in een Agile wereld, waar het succes en de continuïteit van de business afhankelijk is van de snelheid waarmee software in productie wordt genomen, is het geen optie meer om de kwaliteit van softwarewijzigingen in een uitvoerig proces vast te stellen. Testers zullen uit hun comfortzone van omvangrijke testplannen en testprocedures moeten komen en op zoek moeten naar hoe ze binnen een ontwikkelteam waarde kunnen toevoegen. Wat in hun voordeel spreekt is, is dat het principe dat ze op weg zal helpen al sinds jaar en dag in de testliteratuur staat beschreven. De curve van Böhm wijst uit dat het oplossen van een fout in een computersysteem het voordeligst is als die fout zo kort mogelijk na de introductie wordt verholpen. Testers die in Agile teams floreren, hebben het organiseren van feedback op een computersysteem onder ontwikkeling tot een kunst verheven. Ze beginnen hier zo vroeg mogelijk in het ontwikkelproces mee en streven ernaar om de feedback op het product in ontwikkeling zo frequent mogelijk te leveren. In de ultieme situatie wordt na iedere codewijziging vastgesteld of het product in ontwikkeling nog steeds voldoet aan alle eisen die zijn gesteld. Om dit ook in het geval van vele dagelijkse codewijzigingen beheersbaar te houden, kiest een ontwikkelteam er doorgaans voor een volledig dekkende automatische testset op te bouwen.

Testset

Een goede testset kenmerkt zich door de verschillende feedbackloops die erin verwerkt zijn. Allereerst geven de automatische testen antwoord op de vraag: bouwen we het product goed? Deze testen, ook wel de verificatietesten genoemd, geven antwoord op de vraag of het systeem ‘onder de motorkap’ aan de technische wensen en eisen voldoet. Door zorgvuldig met deze vraag om te gaan, kan op lange termijn gewaarborgd worden dat de functionele wijzigingen die de business nodig heeft technisch te realiseren zijn. In nauwe samenwerking met ontwikkelaars kijkt de tester welke testen nodig zijn om voldoende informatie te verzamelen om de verificatievraag te beantwoorden. Dit kunnen technische, functionele en performancetesten zijn, maar ook testen die automatisch de codekwaliteit meten.

Naast de bovengenoemde verificatievraag zal de tester ook een antwoord zoeken op de validatievraag: bouwen we het goede product? Ook deze testen worden in de automatische testset opgenomen. Het antwoord op deze vraag is echter vaak al te vinden voordat er een lettercode is geschreven. Door als ontwikkelteam bijtijds actief na te denken over de technische en functionele gevolgen van een wijziging, kunnen veel fouten worden voorkomen. De tester kan in deze fase een cruciale rol spelen door te schetsen welke testen moeten slagen als de voorgestelde wijziging is doorgevoerd. Op deze manier draagt de tester bij aan het collectieve beeld dat het team van de oplossing heeft. Als dit beeld vooraf scherp genoeg is neergezet, is het bouwen van de juiste functionaliteit vaak een formaliteit. Door binnen een ontwikkelteam de juiste feedbackloops te implementeren kan een team in een voorspelbaar tempo software met een voorspelbare kwaliteit opleveren.

Een nieuwe uitdaging voor de tester is dat hij alle filters open moet hebben staan voor antwoorden op de vraag hoe het systeem in productie wordt gebruikt. Public Beta Testing en A/B testing zijn nieuwe tools die testers in handen krijgen. De ultieme feedback op een systeem komt immers van de gebruikers van het systeem in productie. Maar die feedback komt rijkelijk laat. Fouten in deze fase hebben impact op hoe een klant de kwaliteit van het product beleeft en zijn relatief duur om te herstellen, aldus Böhm.

Navigatiesysteem

Een organisatie kan zich afvragen hoe erg het is het om een fout in productie te introduceren als het slechts een kleine inspanning vraagt om die productiefout te herstellen. Daarom zal een tester vroeg in het proces in kaart brengen welke functionaliteiten van het systeem een groter risico voor de business zijn en welke niet. Deze Product Risico Analyse is een belangrijk handvat bij het bepalen van hoeveel inspanning er geleverd moet worden om een bepaalde functionaliteit productiegereed te maken.

Testen in Agile projecten is in veel opzichten te zien als het navigatiesysteem van een project. Ook tijdens een lange autoreis over onbekende wegen naar een nieuwe bestemming is het niet wijs om het navigatiesysteem pas in te schakelen op het moment dat het vermoeden bestaat dat de bestemming is bereikt. Ook niet als er vooraf goede plannen zijn gemaakt over de route. Hoogstwaarschijnlijk is de bestemming helemaal niet bereikt en is het nog een stuk rijden voordat het werkelijke doel in zicht komt. Als het navigatiesysteem bij vertrek was ingeschakeld, had het systeem bijgestuurd op het moment dat er een verkeerde afslag werd genomen. Dan was het eenvoudig geweest om terug te keren naar de snelste route. Hetzelfde geldt voor testen in een Agile omgeving: zorg ervoor dat een team snel de juiste feedbackloops op gang brengt. Dit vergroot de kans dat projectdoelstellingen binnen de gestelde tijd worden bereikt.