'Testen is ict-projectleiders opvoeden'
Om de kwaliteit van software garanderen heeft de testmanager twee vaardigheden nodig: een rechte rug en de gave om projectleiders op te voeden. Het woord nee mag nooit een taboe zijn.
Om de kwaliteit van software garanderen heeft de testmanager twee vaardigheden nodig: een rechte rug en de gave om projectleiders op te voeden. Het woord nee mag nooit een taboe zijn.
'Testen is ict-projectleiders opvoeden'
Om de kwaliteit van software garanderen heeft de testmanager twee vaardigheden nodig: een rechte rug en de gave om projectleiders op te voeden. Het woord nee mag nooit een taboe zijn.
Dat stelt Onno Verdonk, ondernemer en sinds 1997 bezig met testmanagement. Hij neemt contact op met Webwereld na een artikel over een andere testmanager, die volgens hem wat overspannen overkwam. Hij herkent het beeld van slechte tests bij banken niet.
Projectleiders africhten
Volgens Verdonk is testen altijd werken in een hekselketel. “Er staat altijd druk op de ketel. Wanneer een project uitloopt in de bouw dan komt het testen onder druk”, vertelt hij. “Daar moet je tegen wapenen. Je moet 'Nee' kunnen zeggen. Te vaak proberen mensen op jouw stoel te gaan zitten.”
Voor hem is testen vooral het afdekken van risico's en dat is iets wat bij de projectleiders en managers tussen de oren moet komen. “Aan het eind weet ik welke risico's je hebt afgedekt en welke restrisico's er overblijven. Die rapporteer je. Wanneer een verantwoordelijke die risico's acceptabel vindt dan is het prima. Dat moet je ze wel tussen de oren zien te krijgen.”
Hij ziet dan ook een deel van zijn werk om het begrip risico goed uit te leggen en mensen op te voeden in het accepteren dat het afdekken van gevaren wat tijd kost. Aan de andere kant ziet hij ook mogelijkheden in de werkdruk op projecten. “Dat maakt mensen ook creatief.”
Niet persoonlijk
Wat volgens Verdonk bij de testmanager uit het eerdere artikel duidelijk mis ging, is dat hij de problemen persoonlijk begon op te vatten. “Er staat altijd druk op een project om zo snel mogelijk iets in productie te nemen. Dan zullen mensen proberen ruimte te vinden waar het niet is”, vertelt hij dan ook. “Dat is niet iets persoonlijks, maar een zakelijke beslissing.”
De crux is volgens hem dan ook het proces goed te begrijpen. “Veel mensen vergeten dat als we aan het bouwen er van alles verandert: de wensen, de business, de omgeving en de technologie. Daar moet je goed op inspelen”, betoogt hij. “Als testmanager moet je goed de eindconclusie trekken en risico's in kaart brengen. Die wil je afdekken en dan maak je de slotsom voor wat je test of juist niet.”
Banken wel netjes
Er wordt bij banken “goed” getest. “Dat moet ook wel, want het gaat om geld”, legt hij uit. “Natuurlijk is er businessdruk, want als je de eerste bent dan hou je een groter deel van de markt. Zo simpel is het.”
Toch bestrijdt hij het beeld dat er bij banken dan maar met de pet naar wordt gegooid. Eerder testte hij in andere industrieën. “Dan zie dat zaken veel eerder in productie worden gezet”, vertelt Verdonk. “Dan constateer je wel eens dingen waarvan ik nu denk dat zoiets bij bank never nooit gebeurd zou zijn.”
Je kunt een (of meer) stap(pen) hogerop gaan met je verhaal, en je kunt op zoek gaan naar een andere baan.
Als Verdonk dat zegt, dan heeft hij te weinig ervaring met banken. Ooit, ging de ABN samen met de Amro bank.
De hoge heren beslisten en bij de automatisering van het kantorennet werd een "manager" van ABN het opperhoofd.
Deze beslissing was het gevolg van een manager met een grote bek.
Later zeiden de insiders, we wisten niet dat de Amrobank al zover was met kantoorautomatisering.
Kort en goed, DOS was niks en men ging een systeem met RTOS bouwen. Dat werd niets en men ging iets met windows 3.x bouwen, waarbij de halve kernel werd herschreven wegens beveiliging. Na heel veel vertraging werd het buggy produkt toch in de proefkantoren neergezet omdat langer uitstel echt niet meer te verkopen was aan het hoger management.
In de proefkantoren bleek dat het traag en instabiel was en veel slechter dan de DOS implementatie, maar wat gebeurde er? Degenen in de proefkantoren die moesten beslissen over het productie rijp zijn of niet, werden ontzettend onder druk gezet door die verantwoordelijke manager en zachtjes ingefluisterd dat bij het niet goedkeuren het gevolgen had voor hun carrière.
Tegen dit soort smerige trucks kan je als test manager echt niet op.
Zeg nooit never nooit...
Ik heb in projecten gewerkt waar er een 'ontwikkelteam' was en een 'testteam', ieder met eigen management. Dan krijg je turf wars en als er dan van 'bovenaf' druk komt, dan kan het er stevig aan toe gaan (als lijkt "vendetta" me wat erg sterk uitgedrukt).
Ik zou nog een fase eerder beginnen en alle stakeholders, incluis opdrachtgevers, eindgebruikers, ontwikkelaars en wie er nog maar meer bij betrokken is, opvoeden nog voordat er zelfs maar sprake is van een project. De opvoeding bestaat uit één simpele boodschap: de kans op uitmuntende software is nagenoeg gelijk aan nul, ergens zul je concessies moeten doen.
Het testen werkt in dat opzicht niet om kwaliteit te garanderen (de kans dat garanties teleurstellingen opleveren is eenvoudigweg te groot) maar slechts om aan te geven welke kwaliteit het opgeleverde product en het gevolgde proces dan wel heeft.
Dat duidt op een structureel verkeerde aanpak. Omdat testen continu en integraal deel uitmaakt van het project kan het dus nooit de bouw zijn die uitloopt maar alleen het gehele project, tenzij testen geen deel uitmaakte van het project maar dan kan de bouw fase pas af zijn als dat door middel van testen is vastgesteld. Of een derde mogelijkheid: de ontwikkelaars gewoon geloven dat het goed is (waarbij 'structureel verkeerde aanpak' een eufimisme is ook al werkt het prima voor m'n eigen persoonlijke software).
Het impliceert vooraf vastgelegde requirements in functionaliteit: dat kan maar dan moet je geen vaste einddatum stellen en geen vaste kwaliteitseisen hebben (en dus geen druk vwb. het testen). Alternatief: iteratieve ontwikkeling waarna er op een gegeven moment geconcludeerd moet worden dat het wel mooi genoeg is geweest voor nu en dat er wat functionaliteit op de plank blijft liggen. Hoe dan ook, verwachtingen-management blijft noodzakelijk.
edit: ik bedoel dit niet zo negatief, uiteindelijk wordt er een heleboel software opgeleverd die goed genoeg is, min of meer op tijd en ongeveer binnen budget.
If you pay monkeys, you get peanuts =P
Ha! Vond hem wel goed bedacht. Precies andersom, maar toch blijft er een kern van waarheid in zitten. Je betaald apen en krijgt troep. Of nootjes dan, mag ook.
Het testen van software ken ik niet vanuit persoonlijke ervaring, maar simpele logica dicteert dat kosten vaak (meestal, altijd?) de beslissende factor zal zijn. Vaak worden voor bepaalde projecten deadlines gesteld die niet of nauwelijks haalbaar zijn. Het testen schiet er dan vaak even bij in. Als na het testen dan ook nog eens blijkt dat ze de boel niet op orde hebben, dan wordt de deadline alleen maar verder gepushed. Een simpele kosten-baten analyse doet de rest van het werk.
Als ik in het testvak zou zitten wist ik het wel. Ik ga in ieder geval niet voor Jan met de korte achternaam de boel testen. Dat doe ik voor twee dingen, te weten 1) meewerken aan kwaliteit en veiligheid van het product verhogen (misschien meer, ik ken het vakgebied niet goed genoeg, maar dit lijkt me een mooie basis) en 2) salaris. Doe je vervolgens niks met mijn bevindingen, dan zoek ik een nieuw project, dan wel een ander vakgebied, op.
Of ik maak er een persoonlijke vendetta van, dat schijnen bepaalde mensen in dit vakgebied ook nog wel eens te doen ;-)
Wat bij banken de laatste tijd vooral telt qua geld is dat projecten zo goedkoop mogelijk moeten. Er is geen geld meer voor goede projectleiders en inkopers die willen scoren bepalen de kwaliteit. Mede hierdoor liggen de problemen zoals altijd binnnen de IT vervolgens aan het eind van een project. Als banken voor een projectleider minder willen uitgeven dan voor een loodgieter dan weet je wel wat het resultaat is. Opvoeden heeft dan weinig zin. Penny wise pound foolish komt nog heel veel voor bij een aantal grootbanken.
Inderdaad het gaat om geld. Wat betekent dat de mogelijke schade altijd tegenover de mogelijke winst word gezet. De som die die daar uitkomt bepaalt de keuze's. Zo simpel is het
Mooi en leerzaam artikel!
Reageer
Preview