Trendsz, Hard & soft skills

Van huis uit zijn software testers geen trendsetters. Het testvak is bijna per definitie reactief. Zo ook ten opzichte van trends in de markt. Agile softwareontwikkeling komt op en testers kiezen positie. Als iedereen zich richting de cloud beweegt, dan bewegen testers mee. Hetzelfde geldt voor mobile. Maar dat wil niet zeggen dat er binnen het testvak geen trends te benoemen zijn. Dit zijn geen trends die testers ineens voorop laten lopen bij het inzetten van nieuwe IT-trends, maar wel degelijk ontwikkelingen die het vak van software testen in zijn geheel verder brengen. Testen in een agile context is hier een goed voorbeeld van. De realiteit wijst uit dat testers van de oude stempel snel kopje onder gaan in het hoge ritme dat veel agile teams erop nahouden, terwijl testers die in staat zijn om mee te bewegen, bepalend kunnen zijn voor het succes van een team.

Agile softwareontwikkeling is het stadium van nieuwe trend alweer een tijdje voorbij en termen als Scrum, Continuous Delivery en zelfs DevOps beginnen in steeds meer organisaties gemeengoed te worden. Amazon, Twitter, Google en Facebook zijn voorbeelden van bedrijven die hun succes te danken hebben aan de vaardigheid om hun product steeds aan te passen aan de wensen van gebruikers. Dit doen ze door dagelijks tientallen, zo niet honderden, kleine wijzigingen in hun productiesystemen door te voeren. Continuous Delivery en DevOps stellen

dit soort organisaties in staat om op ieder moment de software in productie te hebben die op dat moment de meeste waarde oplevert. Een organisatie die dit nastreeft moet niet alleen precies weten met welk product de klant optimaal bediend wordt, maar ook in staat zijn om continu met kwalitatief hoogwaardige software te reageren op de steeds

wijzigende klantvraag. Niet in staat zijn om te reageren op de behoefte van gebruikers zou hen uit de markt prijzen. Het consequent opleveren van een te lage softwarekwaliteit heeft hetzelfde effect. In deze markt stapt een klant snel over naar de concurrent.

"De tijd dat iedereen kan testen is voorbij...."

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.

“De realiteit wijst uit dat testers van de oude stempel snel kopje onder gaan in het hoge ritme dat veel agile teams erop nahouden."

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.

140201 – Testers zijn geen trendsetters – Robert Lourens

Schrijf je in voor
de nieuwsbrief

werkenbij overall

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz