Ben je manager of ondernemer en geef je geld uit aan it? Dan is de kans groot dat je je krom betaalt aan testen en daar (te) weinig voor terug krijgt. Als geld voor jou en jouw organisatie geen rol speelt hoef je niet verder te lezen. Als dat wel zo is, denk dan even met me mee.
Het is vakantietijd en we geven massaal geld uit. Organisaties doen dat het hele jaar door aan software testen in it-projecten: 20 tot 30 procent is voor een gemiddeld it-project heel normaal. Gartner en anderen reserveren zelfs 50 procent van het budget voor ‘unit testing, system testing, defect removal and quality management’. Soms is dat voorzien en gepland. Soms is het nauwelijks gepland en constateer je achteraf dat het test/hertest/acceptatietraject toch weer stroperiger en tijdrovender was dan voorzien. Of je constateert helemaal niets, omdat de kosten van testen verstopt zijn in ontwikkeling, implementatie en posten ‘onvoorzien’. Dikke kans dat de (vak)pers je dan al met jouw mislukte project in het vizier heeft.
Business waarde testen onderschat
De waarde van die vakantievilla met zwembad en het ijsje voor de kids begrijpen we heel goed. Maar hoe zit dat met de waarde van testen? Gartner beweert dat managers de business waarde van een goed testtraject systematisch onderschatten. Ik kan dat uit eigen ervaring bevestigen: testen wordt als een technisch feestje beschouwd. Dat is het óók, want het moet technisch werken, maar testen biedt zoveel meer. Meer business waarde, meer draagvlak en ‘customer buy-in’, meer kans op een succesvol project, meer felicitaties en minder frustraties. Dit voorjaar heb ik aandacht gevraagd voor een hogere roi en meer rendement van testen met mijn presentatie ‘Verdubbel de business waarde van testen’ op de Bridging the Gap conferentie. Ik borduur hier graag nog even op verder.
Want ik vind het nog steeds schokkend! Onlangs heb ik het boek De Zwakste Schakel van Eliyahu Goldratt weer eens gelezen. Helaas is de man te vroeg overleden, want zijn inzichten zijn zeer de moeite waard. Zijn punt: een proces is zo sterk als de zwakste schakel, dus elke investering en procesverbetering die niet op de zwakste schakel is gericht, is weggegooid geld, heeft een lage roi en een slecht rendement. Oké, je kunt ook andere metaforen dan de ketting kiezen, maar in dit geval hanteer ik hem graag.
Daarom deze stelling: De zwakste schakel van jouw it-project is test en acceptatie.
Dus wil je geld verdienen? Focus dan om te beginnen op het rendement van het test- en acceptatieproces want daar is veel te halen. En goed testen is effectief en efficiënt testen! Ik zeg het met moeite, vanwege een ernstige allergie voor deze twee woorden. Maar nu gebruik ik ze dan toch en dat schept verplichtingen. Hier komt ie:
Wat is effectief testen?
Dat is dezelfde vraag als ‘Waarom testen?’ of ‘Wat wil je met testen bereiken?’ of ‘Wat is het doel van testen?’. Het is wel handig als je dat voor je het zelf helder hebt, want hier zit het rendement en die business waarde die Gartner bedoelt. Ik doe regelmatig (test) proces audits en als ik aan mijn opdrachtgevers bovenstaande vragen stel, krijg ik maar zelden een volledig antwoord. Onderstaande lijstje heb ik altijd in mijn hoofd en in zo’n gesprek hoop ik iedere keer weer zoveel mogelijk punten te horen.
Testen is effectief als het:
– Risico’s elimineert of mitigeert;
– Problemen in productie en de operatie voorkomt;
– Je feitelijke stuurinformatie verschaft;
– Je helpt om ‘in control’ te zijn en goed te slapen;
– Je helpt om jouw leverancier op het goede moment (niet) te betalen of naar huis te sturen;
– Draagvlak bij de gebruikers creëert en een soepele ingebruikname verzekert;
– Waardevolle ideeën en feedback oplevert voor de product backlog en toekomstige ontwikkeling;
– Positief bijdraagt aan kwaliteitsbewustzijn en aan de productkwaliteit;
– Controlerende instanties tevreden stelt (indirecte business waarde die zwaar kan wegen).
Dat zijn de belangrijkste denk ik, maar als jouw favoriet er niet tussen staat dan hoor ik dat graag, want alles van waarde heeft meer gezichten! Maar dat we het hier over echte toegevoegde waarde hebben kan niemand bestrijden, naar mijn bescheiden mening. Dus wie testen niet serieus neemt doet zichzelf tekort.
Ik ben benieuwd welke aanvullingen ik van je krijg. Als het lijstje compleet is dan hoop ik in mijn volgende blogs in te gaan op:
1. Hoe je met testen bovenstaande doelen realiseert en dus effectief bent;
2. Hoe je dat zo slim en efficiënt doet dat je (ver) onder die 50 procent van Gartner blijft.
Mes met twee kanten
Ook met die tweede verdien je natuurlijk geld. Ik adviseer je om als opdrachtgever vast een goed gesprek met jouw it-leverancier, cio of it-manager hierover in te plannen. Ik beloof je nu alvast een lijstje met tien do’s en don’ts om met hem of haar door te nemen. Wie weet haal je volgend jaar dubbel zoveel waarde uit testen en heb je de kosten gehalveerd. Wie zijn mes aan twee kanten gebruikt krijgt meer roi en rendement terug!
Hoe verdien je geld met testen? Ik daag je uit om mij uit te dagen. Elk antwoord is welkom en elke vraag ook.
Egbert,
Ik vind het een erg interesant artikel, maar je laat me wel erg in het ongewisse. Ik kijk aldus erg uit naar je vervolg verhalen.
Je laatste regel hoe verdien je geld met testen.
Ach… ik kreeg vaker de vraag hoe verdien je geld met OpenSource…
Eigenlijk is die vraag net zo basaal als hoe verdien je geld met ICT.
Egbert,
Leuk artikel waarvoor dank. Echter sluit ik mij volledig aan bij Pascal.
Je titel wekt de indruk dat je ons gaat vertellen hoe we dat kunnen doen. Maar je laat ons juist achter met de vraag hoe je dat kan bereiken? Op zich prikkelend en interessant. Maar ik was toch ietwat teleurgesteld omdat ik wat meer concrete voorbeelden uit de praktijk had willen terug lezen.
Aan de andere kant moet ik wel eerlijk bekennen dat je wel heel leuk en slim een hopelijk mooie en leerzame discussie probeert uit te lokken. Dus ik ben erg benieuwd wat hier uit gaat komen.
Terug naar de basis: Je verdient geld met testen door na te gaan hoeveel de gevonden bevindingen in een testtraject gekost zouden hebben als deze op zouden treden na livegang. (Kosten om te fixen op productie, reputatie, omzetverlies, etc.). Zet deze kosten af tegen de investering van het testen (en toetsen!) van je producten en je weet precies hoeveel het testen je heeft opgeleverd.
(Ben je bekend met Boehm, dan weet je de uitkomst van de vraag.)
Dergelijke oefeningen worden maar vrij zelden uitgevoerd, waardoor het altijd de vraag blijft of de investering van het testen het allemaal waard is geweest.
Testen zwakste schakel in een ICT traject?
Hoewel het testen als laatste stap in een ICT traject nogal eens wordt afgeraffeld want a. budget is op, b. moet in productie, zie ik het niet als de zwakste schakel.
Volgens mij is dat de eerste stap. Als het daar mis gaat en de specificaties sluiten niet aan bij wat de gebruiker wil/verwacht dat kan je natuurlijk testen totdat je een ons weegt. Het gaat nooit meer goed komen. Tenzij je natuurlijk extra budget vrijmaakt. Ziehier weer een ‘mislukt’ project.
Desalniettemin, aandacht aan het onderwerp effectief en efficient testen kan natuurlijk geen kwaad. Er valt daar nog genoeg te ‘winnen’.
Ha Egbert,
Zoals altijd zijn je inzichten en verhalen interessant.
In dit geval vind ik echter wel dat je het nog wat ruimer had mogen benaderen.
Hoe verdien je geld met testen? Door het zo min mogelijk te doen. Testen is één van de vele mogelijke kwaliteitsmaatregelen. Door vooraf vast te stellen wat het benodigde kwaliteitsniveau is en vervolgens daar middels kwaliteitsregie een passend geheel van maatregelen over de hele applicatielevenscyclus op af te stemmen, bereik je een efficiënt en effectief IT-proces. En het uitvoeren van feitelijke testgevallen blijft natuurlijk nodig maar zou als hoofdtaak moeten hebben om te bevestigen dat het IT-proces inderdaad het juiste product met de juiste kwaliteit heeft opgeleverd.
Met testen toon je aan dat bepaalde risico’s niet zullen optreden, of je vindt fouten die tijdig opgelost kunnen worden. In de letterlijke zin “verdien” je daar geen geld mee, maar je kunt er wel heel veel ellende (en dus ook geld) mee besparen.
Wil je verder discussiëren over de “holistic view” op de activiteiten in de applicatielevenscyclus dan ben ik daar uiteraard graag toe bereid !!
Groet,
Rik
Ah daar is ‘ie weer. De aloude vraag/discussie wat testen oplevert/op kan leveren. Een zéér nuttige discussie, maar in dit hele stuk staat eigenlijk niets wat ik in de loop der jaren nog niet heb gehoord.
Belangrijkste in de discussie is de rol van zowel de opdrachtgever als de uitvoerende partij hierin. Wat verwachten ze van elkaar en belangrijker: hoe kunnen ze elkaar zo goed mogelijk aanvullen?
Hmmm, geld verdienen met testen?
Momenteel verdien ik vooral geld doordat testen achterwege gelaten wordt, tenminste stress-testen. Er wordt namelijk nog weleens gedacht dat de infastructuur oneindig schaalbaar is wat helaas dus meestal niet geldt voor het netwerk. De dromers vergeten nog weleens dat horizontaal schalen een enorme impact heeft op de ‘latency’ die niet alleen voor slechtere response zorgt maar ook steeds vaker tot verstoringen leidt.
Kom in de praktijk dan ook leuke verrassingen tegen zoals zoekresultaten die afwijken doordat indexen niet bijgewerkt zijn, databases die corrupt raken of hele services die omvallen als gevolg van een ‘DDoS’ tijdens piekuren. Dat een applicatie prima werkt met 10 gebruikers geeft dan ook nog geen garantie bij 100 of 1000 concurent gebruikers terwijl in de SLA wel vrolijk afspraken gemaakt worden over responsetijden, zonder enig voorbehoud over de tresholds.
@Ewout, dat is natuurlijk ook een mooie insteek.
Maar ik moet toegeven dat je bepaald niet de eerste nog de enige bent die deze ervaring heeft.
@Ewout … zo weet ik er nog wel eentje: geld verdienen met testen is het eenvoudigst als je tester wordt 🙂
Maar alle gekheid op een stokje: 2 dingen zijn van cruciaal belang (naar mijn bescheiden mening) om testen tot zijn recht te laten komen:
– zorg voor een stukje bewustwording bij de (vaak naïeve) managers. Waar gewerkt wordt, worden fouten gemaakt. En of je nu waterval, agile of devops gebruikt, er kunnen nog steeds fouten doorslippen. Testen (al dan niet als integraal onderdeel van de gekozen ontwikkelmethodiek) helpt deze fouten vroegtijdig te ontdekken en bieden een mogelijkheid ze op te lossen alvorens je product “naar buiten” gaat.
– zorg dat je de tijd krijgt om te testen. Het test-traject zit vaak aan het eind van de keten, en als ontwikkeling al alle buffers uit de planning opgemaakt heeft, dan is het verleidelijk om te beknibbelen op het testtraject om zodoende toch de deadlines te halen. Niet doen! Dit is funest!!!
Klinkt als open deuren, maar beiden komen helaas nog te vaak voor….
@Pascal
Het is helaas nog vaak ‘penny wise and pound foolish’ als het om middelenbeslag gaat. Zal niet uitwijden over de praktijkcases maar als je een paar duizend euro bespaard op het ijzer en vervolgens een miljoen verliest op productieverstoringen dan ben je volgens mij niet slim bezig.
Auteur heeft het over ‘stuurinformatie’ en problemen in de productie voorkomen wat ik als hardcore technicus vertaal naar tresholds, de muur die je raakt als je probeert meer te doen dan je infrastructuur aan kan. Meten is weten, als je in een performance grafiek een rechte horizontale lijn ziet dan is dat meestal een signaal dat je een grens bereikt hebt.
Nu valt het me op dat sommige bedrijven dit soort constateringen onder het tapijt willen laten verdwijnen, de politiek van projecten gaat vaak tegen alle logica in. Geld verdienen met testen is namelijk soms ook gewoon aan een dood paard lopen trekken als ik kijk naar de oplossingen die vaak gekozen worden met inefficiente code.
Maar ik had geloof ik al wat gezegd over geld verdienen met het achterwege laten van ‘stress-testen’ toch?
Hardware verkoopt zich tenslotte vanzelf als blijkt dat deze accuut gemist wordt, hoe meer inefficiente code er opgeleverd wordt hoe makkelijker het wordt. Eén voorbeeld van een praktijkcase om een idee te geven over hoe belangrijk je infrastuctuur keuzen zijn en hoe slecht ze soms passen bij de applicaties die gebruikt worden:
Klant (en dienstverlener) hadden een nijpend performance probleem waardoor densiteit van gebruiker versus hardware ongunstig was en de response werkelijk om te huilen, iets van 15 seconden of meer op elke muisklik. Na meting bleek dat het probleem in de bussen zat en commodity oplossing een veel betere doorvoer gaf met ook nog eens een TCO verlaging van een half miljoen. One size doesn’t fit all;-)
Kortom, functioneel testen is leuk maar je bespaard pas werkelijk geld als je rekening houdt met het middelenbeslag. Effectief versus efficient zullen we maar zeggen.