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.
Beste Egbert,
Dank voor je artikel. Zeer interessant en toepasselijk.
Het aanstippen dat testen erg belangrijk is, ondersteun ik ter harte. Ik kom nog steeds te veel tegen dat testen (zowel technisch als functioneel, maar vooral functioneel) een onderschoven kindje is die veels te vaak, met de franse slag moet gebeuren omdat de productie live-gang gehaald moet worden. Of dat het testtraject zo weinig budget krijgt toegereikt dat het testen, her testen en acceptatie een farce wordt. Ik kom zelfs tegen dat managers (kan ik veel beter begrijpen) en zelfs product leveranciers (hier verbaas ik me wel over, omdat ik ervan uit ga dat leveranciers, wel moeten weten hoe belangrijk testen is) vaak denken dat door snel, zonder focus en zonder de nodige aandacht te testen, een volledig systeem goed door getest is. Door dit soort verkeerde percepties kan je je als tester zelf schuldig gaan voelen, als je cruciale fouten vindt, want je wordt zo zoetjes aan degene die de ‘succesvolle’ productiegang tegenhoudt.
Testen is erg belangrijk om vooral de acceptatie bij gebruikers te vergroten en om cruciale fouten uit het systeem te halen, voordat de live-gang plaatsvindt. Alleen dit al bespaart kosten en zorgt ervoor dat systemen niet alleen in de juiste staat worden opgeleverd, maar ook daadwerkelijk gebruikt worden door de beoogde gebruikers.
Ik kijk uit naar je vervolg.
Beste mensen, bedankt voor de mooie reacties. Het gevraagde en reeds beloofde vervolg komt er zeker aan!
@Ruben: helemaal eens met jouw benadering en de verwijzing naar Boehm, maar de business waarde van testen gaat verder dan ‘slechts’ de kosten van fouten in productie voorkomen.
@Kurt: goede requirements en specificaties zijn inderdaad je fundament en in die zin belangrijker dan testen. Maar twee dingen om over na te denken:
1. De essentie van de ‘Theory of Constraints’ van Goldratt is dat het niet uitmaakt wat het fundament en wat gevolg is: de keten is zo sterk als de zwakste schakel, of die nu voor of achteraan zit.
2. In agile en Scrum (niet voor niets populair) denk je ook goed na vooraf, maar belangrijker is toch dat je gewoon begint, en niet te lang blijft hangen in (detail)specificaties vooraf. Veel belangrijker is regelmatige oplevering en continue feedback. En 90% van die feedbackloop bestaat uit testen, volgens mij.
@Rik: Dankjewel voor je compliment! En je hebt een terecht punt natuurlijk: testen is een van de kwaliteitsmaatregelen, net als reviews, audits (ook vormen van testen), versiebeheer en je build-proces, goede design-standaarden, opleiding, team collaboration met een passende IDE, etcetera. Maar testen is wel een relatief grote component in het geheel van kwaliteitsmaatregelen. Dat is voor mij zowel een constatering (testen pakt altijd weer meer tijd dan je dacht) als een visie (testen verdient meer aandacht). En met geld verdienen bedoel ik uiteraard ook ‘ellende’ vermijden (frustratie, uitloop, gedoe) die direct naar geld te vertalen zijn. Het lastige van testen is dat ‘vermeden ellende’ achteraf niet in de boeken komt. Het oogt dus altijd als een kostenpost.
Wat de holistische visie betreft:
Vroeger zei ik altijd (als advocaat van de duivel): ‘Testen moet je niet willen, First Time Right is het ideaal’. Inmiddels zie ik dat anders: systeemontwikkeling is een creatief proces en in het optimale voortbrengingsproces zit veel testen. Nadenken vooraf blijft essentieel maar First Time Right is niet ideaal want te duur en negeert het belang van trial & error en gebruikers feedback. De hele agile trend is ‘liever werkende software dan uitgebreide documentatie’. De equivalent in het agile test manifesto is wat mij betreft: ‘liever concrete testen dan indirecte kwaliteitsmaatregelen zoals audits’. Uiteraard met de bekende toevoeging ‘while there is value to the latter…’.
Om geen te lange lap tekst te maken reageer ik hieronder verder op Rilo en verder.
Vervolg op vorige …
@Rilo: Mee eens dat verwachtingen opdrachtgever / opdrachtnemer belangrijk zijn. En hoe krijg je die helder? Je weet vast wel waar IKIWISI voor staat! Dus ga niet teveel tijd aan specs en requirements besteden. Maar maak een stijgende spiraal van specificeren, bouwen, TESTEN , specificeren, bouwen, TESTEN , enzovoort. En Test Driven Development komt enorm op, dus eigenlijk wordt het TESTEN, bouwen, TESTEN, bouwen, TESTEN, bouwen, enzovoort. Waarmee ik niet beweer dat TDD in essentie een testactiviteit is overigens.
@Ewout: Als ik je goed begrijp verdien je een lekkere boterham omdat je de ellende als gevolg van slechte schaalbaarheid en onvoldoende stress-testen opruimt. Van harte gegund, maar dat geld wil ik nou juist beter besteden aan voorkomen in plaats van genezen! En je introduceert een belangrijk punt: je architectuur en je infrastructuur moeten schaalbaar en toekomstvast zijn, met oog voor de problemen van ‘horizontaal schalen’ en middelenbeslag die je schetst. Dan hoef je niet elk risico uit te sluiten (ook niet met testen), omdat je snel en flexibel kunt opschalen op het moment dat dat nodig blijkt. Dat geldt zeker voor performance (capaciteit, snelheid) maar zelfs voor functionaliteit want in een cloud/SaaS omgeving kun je bliksemsnel functionele aanpassingen maken. Maar alles hangt af van de risico’s, sommige problemen wil je toch echt uitsluiten voordat je live gaat. En je zegt het terecht: je kunt niet elk capaciteitsprobleem oplossen met meer ijzer. Dus je architectuur en schaalbaarheid vooraf valideren (met stress testen?!) is een erg gezond idee.
@Pascal: zie reactie op Ewout.
@Pa Va Ke: helemaal eens, dit zijn belangrijke dimensies, jouw ‘open deuren’ zijn maar al te relevant, nog steeds! En wat waterval/agile/DevOps betreft: Ik zou zeggen: Google eens op ‘W-model opvolger V-model’. Erg bruikbaar als je klassiek en agile testen in balans wilt brengen!
@Marianne: wat je schetst is zeer herkenbaar, als tester ben je de boodschappers van slecht nieuws op het moment dat het beroerd uitkomt. Dan heb je plotseling wel even de aandacht van (business) managers. Je schrijft dat je wel begrijpt dat managers ‘too little, tool late’ waardering voor testen hebben. Waar ik – mede met mijn artikeltje – graag naartoe wil is een situatie dat jij dat NIET meer begrijpt. Omdat de business managers van deze wereld allemaal weten wat testen voor ze doet en ze dus geen excuus meer hebben. Laten we daar met z’n allen voor gaan!
Iedereen bedankt voor zijn/haar intelligente en professionele bijdrage aan deze discussie, dit is genieten!
Voor ik half augustus met vakantie ga hoop ik een vervolg te plaatsen.
Hallo Egbert,
Goed artikel.
Vooral je “audit-lijstje” Testen is effectief als…
Je daagt me uit om het lijstje aan te vullen.
Ik vind zelf de belangrijkste:
Testen is effectief als je voordat je in productie gaat kunt nagaan in hoeverre het product “fit for purpose” is. Controleren of het doet wat het moet doen.
Belangrijke kanttekening.
Je bent blijkbaar meer allergisch voor het woordje efficient dan voor het woordje effectief, want in je artikel werk je de eerste term wel en de tweede niet uit.
Dat schept verplichtingen! Ik zie uit naar je vervolgartikel.
Guido
@Egbert
Allereerst fijn te zien dat je reageert op de gegeven reacties. Op deze manier krijgen we tenminste vruchtbare discussies; iets wat sommige schrijvers nog steeds niet begrijpen helaas.
Een fragment uit je reactie triggerde me: ‘Testen moet je niet willen, First Time Right is het ideaal’.
Continue bouwen, integreren en testen is iets wat we de laatste jaren steeds vaker zien, en heeft absoluut voordelen. Keerzijde van deze continue aanpak is dat men gaat vertrouwen op de bouw- testcyclus, en omdat men meestal toch binnen 15 minuten terugkoppeling heeft, krijg je al snel een “trial and error” benadering die overheerst over het “first time right”.
Mijn ervaring is dat een “first time right” houding misschien initieel iets meer tijd kost, maar bij grote complexe systemen/projecten blijkt de kwaliteit vaak toch wel beter.
Ik heb me in Spanje vaak afgevraagd hoe het mogelijk is met een testbudget van 0 tot 10 procent toch veel producten succesvol te plaatsen.
Het antwoord ligt vooral bij de klanten. Als de klant een lage acceptatiedrempel heeft is het mogelijk producten te ontwikkelen met weinig test kosten. Als je het ook nog voor elkaar krijgt dat de klanten voor de maintenance betalen heb je het helemaal voor elkaar. Niet testen brengt dan geld op.
Misschien moeten we de klanten in Nederland leren minder kritisch te zijn. De zwakste schakel is de gebruiker.
Very interesting article…