Wie is bang van de boze tester?

Cliché 1: Testen kost veel maar levert eigenlijk weinig op.

De cijfers lopen nogal uiteen maar volgens de meeste bronnen moet een derde tot een vierde van de voorziene tijd voor het bouwen van een nieuwe toepassing worden gereserveerd voor het testen van deze toepassing. Volgens Gartner bedraagt het testen zelfs tot 40 procent van de projecttijd. Dat lijkt enorm veel en voor buitenstaanders ook moeilijk te verantwoorden. Maar het wordt eenvoudiger als u het volgende bedenkt: uit cijfers die Jean-Yves Van Liefde, technical director van Compuware Belux, ons ter beschikking stelde, blijkt dat de kost voor het herstellen van een fout slechts 139 dollar bedraagt als die fout wordt vastgesteld bij het opstellen van de requirements, de concrete behoeften die de toepassing moet invullen. “Maar deze kost neemt geleidelijk toe naarmate de fout later in het traject wordt vastgesteld en kan zelfs oplopen tot ruim 14.000 dollar wanneer de fout pas in de maintenance mode wordt vastgesteld, als de toepassing al live aan het draaien is dus.”
Een goede test op het juiste moment kan u dus duizenden dollars besparen, een dergelijke redenering maakt het uitgebreid testen al veel makkelijker te verantwoorden. Vooral het verschil tussen een bug die ontdekt wordt vóór de toepassing live gaat en erna, is enorm en maakt uitvoerig testen in de pre-live fase een verstandige investering.

Cliché 2: Als alles ontwikkeld is, kan men beginnen testen

Het is niet alleen van het grootste belang dat er voldoende tijd wordt uitgetrokken voor het testen, maar ook dat er doorheen het traject voldoende testmomenten worden ingepast. Uit het bovenstaande voorbeeld blijkt zelfs dat het testteam best al van bij de ontwerpfase, bij het vastleggen van de behoeften van de business, in het project worden betrokken. En ook doorheen het hele ontwikkeltraject moeten testmomenten worden ingelast, sommige meer op technisch niveau, andere meer op het niveau van de gebruikerservaring en -acceptatie.
Om deze verschillende testniveaus te illustreren, wordt vaak naar het V-model verwezen, waarbij elke stap in het traject een equivalent aan de testzijde heeft (zie figuur 1). Of de user requirements wel degelijk worden ingevuld met de toepassing wordt in de user acceptance testfase nagegaan. Maar voor dit wordt gecontroleerd, heeft de toepassing al een volledig testtraject afgelegd:
– component testing of unit testing, waarbij elke afzonderlijke module wordt gecontroleerd;
– integration testing, waarbij wordt nagegaan hoe de modules met elkaar samenwerken;
– system testing, waarbij de applicatie wordt getest op een goede werking binnen de omgeving waar ze uiteindelijk zal draaien. Vaak wordt ook hier de grotere integratietest voorzien: hoe de toepassing integreert met de reeds bestaande toepassingen, met de database, de aanwezige middleware (integratiesoftware), …. Maar soms gebeurt dit ook in de integration testing fase hierboven.
Zo legt het ontwikkel- en testtraject een hele weg af van het high-level beschrijven van behoeften tot de meest elementaire codeeropdracht en terug. Maar zelden verloopt het helemaal zo rechtlijnig: vaak worden kleine modules al voorgelegd aan de eindgebruiker voor acceptatie, voor ze verder worden geïntegreerd met andere modules. Deze aanpak leunt nauwer aan bij extreme programming en andere agile methodologieën waarbij de cycli van ontwerpen, ontwikkelen, testen en acceptatie elkaar veel sneller opvolgen, vaak zelfs aan het ritme van één cyclus per dag. In de praktijk ziet men steeds vaker combinaties van verschillende methodieken.
Cliché 3: Testen is voor techies
Het belangrijkste gevolg van bovenstaande aanpak is dat de testgroep steeds nauwer bij de eindgebruikers betrokken raakt, en dat het hele testtraject meer dan alleen technische kennis vergt.
Bedrijven als Capgemini laten hun nieuw talent vaak starten in de testafdeling, vertelt Bernard Ghigny, vice president van Capgemini België. “Hier leren onze young professionals met een kritische blik naar de hele business kijken, een leerschool die hen goed op weg helpt voor de rest van hun carrière.” Maar ook wie van testen en kwaliteitscontrole zelf zijn carrière wil maken, kan het zich niet meer veroorloven om zich niets van de business aan te trekken. Steeds meer worden de testers trouwens betrokken bij de allereerste fase, bij het capteren van de behoeften, merkt Dirk Vanderlooven, senior ICT-architect bij EDS Belux, op: “Dat helpt vaak om snel fouten te ontdekken bij de captatie: de tester en programmeur zullen merken dat ze een verschillende interpretatie gaven van wat de klant als behoefte had geformuleerd. Dan kan snel worden nagegaan bij de klant wat nu eigenlijk zijn bedoeling was, en is kostbare programmeertijd uitgespaard.”

Cliché 4: De moderne tools en omgevingen maken sneller testen mogelijk
Dit is misschien het gevaarlijkste cliché uit de hele reeks. Elke evolutie wordt meestal als vooruitgang beschouwd maar dat is niet noodzakelijk het geval. “De evolutie van een homogene mainframeomgeving naar een heterogene, gedistribueerde omgeving heeft de klant wel veel meer keuzes bezorgd maar maakte het testen er niet eenvoudiger op,” waarschuwt Paul Roevens, delivery manager van Fujitsu Services, “Er zijn dan misschien wel meer geautomatiseerde testen die het testproces versnellen, maar de ICT-architectuur is zoveel complexer dat je heus niet minder tijd kan vrijmaken voor de testfase.” Toch laat iedereen zich wat meeslepen in die jacht naar steeds kortere ontwikkeltrajecten, die vaak ten koste gaan van de testtijd. “Je kan de beste visuele tools gebruiken maar als je niet steeds dezelfde grondige methodiek voor ontwikkelen én testen gebruikt, dan wordt de kans op fouten en zelfs mislukte projecten oneindig veel groter.”
De grote servicebedrijven hebben allemaal hun eigen methodiek en bijhorende tools. Gemeenschappelijk kenmerk voor allen is de aandacht die wordt besteed aan het documenteren van elke fase, inclusief de testfase. Dit wordt des te belangrijker naarmate de trend van outsourcing – al dan niet in het buitenland – toeneemt. Er moet dus voldoende tijd en aandacht worden besteed aan het documenteren enerzijds van wat er in de testfase dient te gebeuren en anderzijds van wat tijdens het testen foutloopt. Niet alleen om de communicatie tussen alle partijen optimaal te laten verlopen maar ook omdat de documentatie vaak het enige is waar de manager zich op kan baseren. Ghigny: “Er moet voldoende materiaal zijn om de manager het vertrouwen te bezorgen dat alles verloopt zoals het hoort. Een belangrijke steeds terugkerende vraag bij de keuze van documentatie is dan ook: welke rapportering hebben we nodig voor het management.”
Ook deze aandacht voor het documenteren van de testen maakt het testverloop er uiteraard niet sneller op. Maar ook hier geldt: wie het testverloop zou willen versnellen door minder te documenteren, dreigt op het einde met een snel afgewerkt maar slecht werkend eindresultaat achter te blijven.
Cliché 5: Testen kan best worden uitbesteed
Door de natuurlijke aversie en/of onverschilligheid die vooral langs businesszijde bestaat tegenover testen, is de algemene uitbestedingsdrang die de hele ICT-sector in zijn greep houdt, misschien nog sterker aanwezig bij het testen. Maar wie aandachtig de vorige clichés heeft gelezen, kan het antwoord op dit cliché al raden: testen uitbesteden is lang niet altijd de beste oplossing.
Wel is het een goed idee om de testen niet door dezelfde persoon te laten uitvoeren of zelfs te laten schrijven als degene die de software ontwikkelt. Los van het verschil in karakter tussen een ontwikkelaar en een tester (zie ook hieronder), is het altijd een goed idee om een externe een blik te laten werpen op de software. En van een externe persoon naar een externe partij lijkt maar een kleine stap.
Toch is het uitbesteden van testen allesbehalve een evidentie. Ten eerste vergt zowel het programmeren als het testen een gedegen kenn
is van de business waarvoor men software ontwikkelt. Als men het testen loskoppelt van het programmeren betekent dit dat minstens twee partijen de business van de klant moeten leren kennen. “Er bestaan wel manieren om dit probleem op te lossen,” vertelt Yves Seynaeve, senior manager van Capgemini België, “zoals het externe testteam eerst een tijdje laten meedraaien bij het interne testteam en hen zo de business van de klant te laten ervaren, maar dit werkt enkel bij engagementen op lange termijn.”
Bovendien is het testen niet zomaar een activiteit die je over het muurtje kan gooien en nadien netjes afgewerkt terugkrijgt. Sommige stappen in het testproces vergen een sterke interactie tussen het testteam, het ontwikkelteam en de eindgebruiker, en hoe meer deze partijen uiteen liggen, hoe complexer het wordt om deze interactie vlot te laten verlopen. “Je kan eigenlijk vlotter het opstellen van de requirements uitbesteden dan het testen van de software,” besluit Paul Roevens.
Ook wie het testen uitbesteedt om van de opvolging en de verantwoordelijkheid af te zijn; dreigt van een kale reis thuis te komen. Ten eerste heeft het bedrijf toch een grote rol te spelen in de vertaalslag van de requirements naar de ontwikkeling en testing. En niet onbelangrijk, aldus Yves Seynaeve: “als de klant de ontwikkeling en testing naar twee verschillende partijen uitbesteedt, blijft hij wel zelf aansprakelijk. Dit wordt door bedrijven vaak uit het oog verloren. En een derde partij inhuren om de coördinatie tussen die twee andere partijen te beheren kan wel maar dat is ook geen eenvoudige opdracht.”
Cliché 5A: Uitbesteden doe je best offshore
Wanneer de stap wordt gezet naar uitbesteding van testen, lijkt offshore uitbesteding de logische volgende stap. Niet alleen omdat de kost per tester nog steeds heel voordelig uitvalt en men de klok rond kan testen indien nodig, maar ook omdat bijvoorbeeld de internationale dienstenleverancier Capgemini heeft ondervonden dat de Indische testteams heel gestructureerd werken, wat zeker een voordeel is.
Toch is offshore niet altijd werkbaar. “Voor het technische gedeelte levert dat niet al te veel problemen op,” zegt Paul Roevens, “maar beeld je eens in hoeveel werk je krijgt als je de user interface moet laten testen door Indiërs, terwijl die toch meestal in één of beide landstalen is gemaakt.” Bovendien kan je ook niet naar eender welk klein bedrijf je testen uitbesteden, vervolgt Roevens: “je testpartner moet een voldoende grote testinfrastructuur hebben om realistische performantietests te kunnen uitvoeren. Als je je testen offshore uitbesteedt, ga je dus best eerst even de situatie ter plekke evalueren.”

Cliché 5B: Uitbesteden doe je best naar een CMMI 5-partner
U kent het wellicht, het fameuze CMMI (Capability Maturity Model Integration), een waardemeter voor de maturiteit van de processen en methodiek van een bedrijf. Bedrijven kunnen hierop een score van 1 tot 5 behalen, waarbij 5 staat voor een volledig beheerde omgeving die bovendien in staat is steeds naar een beter niveau te evolueren. Uiteraard is de verleiding groot om bij het uitbesteden op zoek te gaan naar een partner met de hoogst mogelijke maturiteit.
Maar dit garandeert niet per se de beste resultaten. “Als je zelf slechts CMMI-niveau 1 behaalt, dan baat het niet om een Indische partner met level 5 te gaan zoeken,” stelt Paul Roevens, “want dan kan je daar toch niet het volle potentieel van benutten. Dan haal je nog betere resultaten als je allebei niveau 3 bent.” De redenering is een beetje zoals met de KMO die naar SAP stapt voor zijn ERP-pakket: wellicht heb je zoveel niet nodig en wellicht betaal je er te veel voor, en waarschijnlijk praat je niet eens dezelfde taal, ongeacht of het nu een binnenlandse of offshore partner betreft.
Cliché 6: Testers zijn pesters
Voor bedrijven als Capgemini vormt de testafdeling vaak de ideale springplank voor de rest van hun carrière. Maar sommige medewerkers worden bewust uit de testafdeling weggehouden omdat zij absoluut niet beantwoorden aan het profiel van de ideale tester. Anderen zijn dan weer geneigd om in deze afdeling te blijven omdat zij hier precies wel hun gading vinden en perfect beantwoorden aan de ideale tester. Maar hoe ziet die ideale tester er dan uit?
“Eigenlijk moet een tester bijna de tegengestelde beginhouding hebben als een programmeur,” zegt Dirk Vanderlooven, “Een programmeur moet vertrekken vanuit het standpunt dat hij het programma wel zal doen werken, en dat hij er alles aan zal doen om daar ook in te slagen. Een tester moet vertrekken vanuit de veronderstelling dat er wel dingen fout zullen zijn aan het programma, als het al werkt. Zijn kwaliteiten moeten gericht zijn op het zo efficiënt mogelijk vinden van zoveel mogelijk fouten. Als er geen fouten zijn gevonden, besluit een programmeur dat hij goed werk heeft geleverd. Als een tester geen fouten vindt, vraagt hij zich af welke fouten hij heeft gemist.”
Moet men dan besluiten dat een programmeur constructief bezig is en een tester destructief, alleen gericht op het pesten van de programmeur en het afbreken van wat die heeft opgebouwd? “Absoluut niet,” weerlegt Yves Seynaeve: “een tester kan zijn creativiteit kwijt in het bouwen van de best mogelijke testscenario’s en test tools. Het cliché van de tester als negatief ingesteld persoon klopt dus absoluut niet.”