Testers voelen zich nog niet echt gewaardeerd
Hans van Loenhoud, voorzitter van de beroepsvereniging TestNet, bevestigt het beeld dat de testers zich niet helemaal serieus genomen voelen. "In het spanningsveld tussen ontwikkelen en testen acht de gemiddelde ontwikkelaar zich wat hoger gepositioneerd dan de tester, omdat de ontwikkelaar een creatief proces doormaakt waarbij hij iets nieuws maakt, terwijl de tester iets wat al bestaat aan de tand moet voelen. In de praktijk van alledag zie je dat bij veel organisaties de waardering voor softwaretesters vaak een niveautje lager ligt dan die voor ontwikkelaars. Kijk gewoon naar salarissen en dergelijke. TestNet vindt dat een volstrekt onterechte situatie." Er zijn wel wat verschuivingen de laatste tijd, constateert Van Loenhoud. "Je ziet dat de business er steeds meer genoeg van heeft dat software de beloften niet waarmaakt die ontwikkelaars en verkopers van software doen. Bedrijven stellen steeds vaker de eis dat een ontwikkelaar of verkoper bewijst dat de software doet wat hij moet doen. De waardering voor het testvak groeit dus langzamerhand omdat bedrijven zekerheid willen dat software geen risico inhoudt." In plaats van de gemankeerde ontwikkelaars die dan maar de nare testklusjes moesten opknappen, zijn testers nu professionals geworden die de bedrijfsrisico’s van software beperken. Die professionalisering wordt veelal gestimuleerd door de gebruikers, meent Van Loenhoud. "Gebruikers, applicatiebeheerders en met name businessmanagers zeggen ‘wij zijn het zat om software met bugs te krijgen’. Zeker in bijvoorbeeld de vliegtuigwereld is softwaretesten een gerespecteerd vak." En ook aan de embedded softwarekant komt men er volgens Van Loenhoud achter dat software vol met bugs zit. "Hoe toon je het nut van testen aan?", was de vraag voor Henk van Merode van de KLM. Hij moest met zijn afdeling Test Management een nieuw systeem voor het luchtpostvervoer testen dat nog voor kerst 2002 moest draaien. "Het moest goedkoop en snel", zo luidde de opdracht. KLM moest de eerste gebruiker worden van een standaardproduct van een externe leverancier. Maar in De Merodes ervaring moesten de testers nogal vechten voor erkenning van het nut van hun werk. Slechts in kleine stappen kon er mankracht vrijgemaakt worden voor het testen, uiteindelijk 2,7 FTE voor langere tijd. De Merode spreekt van ‘wederzijds wantrouwen tussen business en IT’. Aanvankelijk kregen de testers ook relatief meer de schuld van de opgetreden vertragingen. "Er gold een harde deadline, maar de business stelde niet genoeg middelen ter beschikking." Uiteindelijk ontstond er meer teamwerk. De Merode zegt te hebben geleerd dat de complexiteit van een goed testproces doorgaans wordt onderschat door ‘de business’, de opdrachtgevers. "Je moet betrokkenheid krijgen van die klant, dus je moet wel eens dingen doen die niet bij je eigen werk horen." Dat kan betekenen dat testmanagers niet alleen testcases moeten bedenken, maar ook businesscases, iets waar ze minder affiniteit mee hebben. Daarnaast is het zaak te zorgen voor een paar ‘quick wins’, kleine succesjes waarmee het nut van de testprocedure is aan te tonen. Inhaalslag Dat de waardering voor testers achterblijft, vindt Van Loenhoud ook weer niet zo vreemd. "Het testen als professie bestaat eigenlijk nog maar kort. Het uitkomen van de methode TMap was het moment dat het testen voor het eerst als vak werd erkend. Dat is nog geen tien jaar geleden. De testers zitten in een inhaalslag en die is nog niet achter de rug." Van Loenhoud hoort ‘in de markt’ van bedrijven als Sogeti, Logica CMG en Ordina wel dat testactiviteiten relatief in belang toenemen. "Verschillende grote generieke dienstverleners die ook een testpoot hebben, roepen allemaal ‘onze testpoot doet het op dit moment relatief veel beter dan onze ontwikkelpoot’. De klanten achten het belang van testen steeds hoger." Hij denkt dat er relatief meer tijd wordt gestoken in het testen van een beperkter aantal ontwikkelde applicaties. Binnen ontwikkelprojecten verschuift de verhouding tussen ontwikkelen en testen. "In plaats van 10 of 20 procent van de tijd vergt die fase nu 30 of 40 procent van de tijd." De Britse testwetenschapper Les Hatton betoogde op de bijeenkomst dat de meeste fouten in software ‘langzame fouten’ zijn. "Veel softwarefouten doen er erg lang over aan de oppervlakte te komen, of doen dat nooit." Juist die vertraging zorgt voor schade. Hij illustreert zijn stelling met een experiment met olie exploratiesoftware, die door negen oliemaatschappijen wordt gebruikt om de succeskans van dure proefboringen in te schatten, op basis van seismische data. "Zelfs na vele gebruiksjaren blijken dezelfde algoritmes en dezelfde parameters te leiden tot uiteenlopende beslissingen over wel of niet boren, terwijl dezelfde seismische data gebruikt zijn." Hatton heeft nog één tip voor testverantwoordelijken. "Als je software vrijgeeft, houd dan zelf niet op met zoeken naar fouten, want dat doe je beter dan je klanten. Bij clientsoftware is dat nog veel sterker het geval. Mensen raken steeds ongevoeliger voor GUIfouten. We nemen het voor lief als de computer de stomste dingen tegen ons zegt."