Veel laaghangend fruit bij besparen op testkosten

Computable Expert

Anko Tijman

Partner Agile Testen

Expert van Computable voor het topic Development

Meer

Geen enkel bedrijf ontkomt er aan, kostenbesparingen zijn aan de orde van de dag. Maar kun je op een creatieve manier van de nood een deugd maken? Kunnen testers ook bijdragen aan de noodzaak om kosten te besparen zonder concessies te doen aan de kwaliteit van de opgeleverde software? Ik vind dat er in Nederland testland veel laaghangend fruit te plukken is. Testers kunnen in mijn optiek hiervan zonder veel moeite drie vruchten plukken; die van procesaanpassingen, die van attitude en die van de inzet van tools.

De eerste vrucht: procesaanpassingen

Allereerst zal het uitvoeren van tests niet meer een eenmalige fase na het programmeren moeten zijn, maar veel meer een ondersteunde activiteit van het ontwikkelproces. Je ziet dit nu al in agile-projecten gebeuren: de tester is onderdeel van het ontwikkelteam en voert zijn tests parallel aan de ontwikkeling uit. Daarmee krijgt de programmeur directe feedback op zijn werk, worden eventuele fouten in een vroeg stadium ontdekt en kunnen ze ook snel weer opgelost worden. Immers, de code zit nog 'vers in het hoofd' van de ontwikkelaar, dus is de hersteltijd aanzienlijk korter dan bij feedback loops van weken. En als de ontwikkelaar en de tester toch zo nauw samenwerken, dan kan de tester ook wel meteen zijn testgevallen aan de ontwikkelaar laten zien. Op die manier wordt er code geschreven die voldoet aan de testcriteria. Als tester kun je dit dan kort valideren en je aandacht richten op andere testsituaties.

Op deze manier verkort je aanzienlijk de doorlooptijd van het ontwikkel- en testproces. Er is sprake van samenwerking in plaats van interne concurrentie. Kwaliteit is veel meer een integraal onderdeel van het proces in plaats van een toetsing achteraf. Dit voorkomt fouten en als ze gemaakt worden, worden ze in een vroeger stadium geconstateerd en sneller opgelost. Dat is een aanzienlijke verbetering in de efficiency van het ontwikkelproces.

De tweede vrucht: attitude

De tweede manier om kosten te besparen is het loslaten van de procesfocus die veel testafdelingen hebben. Voor iedere fase en iedere stap in het testproces is wel een template, een RACI-matrix en een escalatiepad gedefinieerd. Daarbij wordt als norm vaak het 'worst case-scenario' van een testproject gedefinieerd. Het zou zo ontzettend veel geld schelen als we voor minder belangrijke en minder kritische projecten ook eenvoudiger procesmodellen zouden hanteren. Dat kan door projecten te classificeren als hoog, midden of laag risico en ze ook zo te behandelen. De risicoclassificatie doe je uiteraard vanuit business én technologisch perspectief en dus met de business samen.

Door procesmodellen vereenvoudigd toe te passen bespaar je op directe kosten (minder activiteiten) en overhead (minder controle). En start nu niet meteen een project 'Vereenvoudiging procesmodellen testen' maar zet je knapste koppen een middag in een hok, produceer een resultaat en begin ermee in je eerstvolgende project. Bij een goede analyse van het type project hoeft dit helemaal niet ten koste te gaan van de kwaliteit. Je zult er wellicht achter gaan komen dat je jarenlang te veel geld aan testen hebt uitgegeven...

De derde vrucht: inzet van tooling

De derde en laatste vrucht is de inzet van geautomatiseerde hulpmiddelen, oftewel testtooling. Analoog aan de voorgaande suggestie: zet ook deze in als het echt nodig is. Bekijk dus kritisch waar je extra tooling kunt inzetten om sneller tot resultaten te kunnen komen en om duur en langzaam handmatig testen te vervangen. En begin uiteraard met het kijken bij open source-tooling, dat vaak verrassend goed ondersteunt!

Maar kijk ook eens tegengesteld: wordt testtooling wel efficiënt ingezet? Wordt er wellicht teveel regressie geautomatiseerd getest, bijvoorbeeld op die onderdelen van de software die moeilijk testbaar of helemaal niet kritisch zijn? Zijn de gerealiseerde testsets wel voldoende onderhoudbaar of kost iedere wijziging meer dan dat hij oplevert? Ik heb op afdelingen gewerkt waar zelfs eenvoudige schermwijzigingen alleen de afdeling Testautomatisering al drie dagen werk kostte! Dus ook bij het inzetten van testtooling is een op risico's gebaseerde aanpak te prefereren. Niet alles automatiseren, maar automatiseer wel die onderdelen die kritisch zijn en/of veel gewijzigd worden. En zorg ervoor dat het onderhoudbaar en wijzigbaar blijft, want dat gebeurt nu eenmaal bij systemen die in gebruik zijn.

Samengevat: stel je eigen aannames ten aanzien van je testprocesinrichting eens stevig ter discussie. Waarom hebben we bepaalde afspraken gemaakt en is die context waarin die destijds gemaakt zijn nog steeds van toepassing? Zijn er nieuwe risico-afwegingen te maken die besparingen opleveren en eenvoudig te implementeren zijn? Ik weet zeker dat je tot verrassende inzichten komt!