Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Verdien meer geld met testen

 

Computable Expert

ing. Egbert Bouman
Practice Manager bij Valori, Valori. Expert van Computable voor de topics Development en Overheid.

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.
Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5141813). © Jaarbeurs IT Media.

6,4


Lees meer over


 

Reacties

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.

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...

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×