Testen is nog steeds booming business, ondanks de crisis waar we al geruime tijd in zitten. Het aantal professionele testers neemt nog steeds toe. De seminars schieten als paddenstoelen uit de grond en worden druk bezocht. ISTQB-cursussen worden overal gegeven en het aantal gecertificeerden neemt enorm toe. Veel publicaties zien het levenslicht! Je raakt bijna niet uitgelezen. Je zou zo denken; wat is het probleem? Je ziet dat de ict-community moeite heeft om het percentage succesvolle projecten te verhogen. De laatste onderzoeken laten zien dat nog steeds 55 procent van de projecten mislukken om diverse redenen. Als ict-community moeten we ons een flink achter de oren krabben. Hoe komt het dat het percentage gelukte projecten niet hoger wordt en wat kunnen we als testers daaraan doen? Om geschikte maatregelen te treffen moet je kijken naar de oorzaken. Zonder uitputtend te zijn wil ik de volgende mogelijke oorzaken aan stippen.
Vaak weten we niet wat we moeten testen. Requirements zijn er niet of zijn incompleet. Onze methoden schrijven voor dat we de testbasis (lees req) moeten hebben om überhaupt te kunnen starten. Deze insteek is achterhaald en niet realistisch. Ik zie weinig initiatief bij de testcommunity om dit probleem te tacklen. Dit bevreemdt mij uitermate. Hier kunnen we laten zien dat we als testers al vroeg in de lifecycle een toegevoegde waarde hebben om door het stellen van de juiste vragen de requirements, etc. boven tafel te krijgen, risico's te inventariseren en de doelen scherp te krijgen en te houden.
Een andere oorzaak is het kwaliteitsniveau van ons als tester. Veel mensen noemen zich professioneel tester zonder dat ze een degelijke basis hebben. Ja, we volgen ISTQB Foundation, etc. en denken dat we dan professioneel zijn.
Echt professioneel
Ik maak de vergelijking met een chirurg die bij de LOI een tiendaagse cursus Opereren volgt en dan een professioneel chirurg is. Nee, een arts in opleiding is tien jaar bezig om chirurg te worden en dient zich de rest van zijn leven permanent bij te scholen. Dat noem je een professional. Daar moeten we als testcommunity van leren. Ik pleit er dan ook voor om zo snel mogelijk een academische testopleiding op te zetten, zodat wij als testers ook echt professioneel worden.
Zo kan ik nog even doorgaan. De titel van dit stukje is; hoe goed zijn we als testers? Mijn conclusie is dat we gemiddeld goed zijn en dat we als community en individuen nog forse stappen moeten zetten. We spelen in de hoofdklasse maar zitten nog niet in de Champions League. Om echt goed te worden moeten we ondermeer invulling gaan geven aan de genoemde uitdagingen. Dan hebben we als tester een goede basis en zien een mooie toekomst tegemoet in staat om de nieuwe uitdagingen succesvol in te vullen.
Het probleem van niet complete requirements is al jaren geleden getackled door een van de bedrijven waar testers ook echt testers waren en niet consultants die toevallig geen opdracht hadden. CMG Joint testware development. Ik weet het niet zeker maar volgens mij kom je met Agile ook erg ver.
De methode die voorschrijft dat we de testbasis moeten hebben om überhaupt te kunnen starten, is achterhaald. Laat het los :)Leuk voor je boekenrek en om een globaal beeld van testen te krijgen.
Het probleem is volgens mij niet hoe goed we als testers zijn. Ik ben van mening dat veel testers over gekwalificeerd zijn. Het probleem zijn toch echt de bedrijven zelf.
Moet nu stoppen anders blijf ik aan de gang.
Software testing is een vrij jonge discipline in het informaticaveld en het is normaal dat er nog heel veel progressie valt te boeken in testing, maar dat geldt evenzeer bij andere informaticageralteerde onderdelen zoals requirements engineering en infrastructuurbeheer. Het heeft voor de geneeskunde ook vele jaren en zelfs eeuwen gekost om tot op dit niveau te komen. In de vroege middeleeuwen bestonden er ook geen of amper opleidingen en moesten (aspirant-)artsen illegaal lijken opgraven op begraafplaatsen om hun kennis te verbreden. Het is misschien een lugubere vergelijking, maar het illustreert wel dat ieder vakgebied tijd nodig heeft om te ontwikkelen.
Een opleiding die enkel gewijd is aan software testing lijkt me te nauw. Als tester heb je namelijk een brede achtergrond nodig om optimaal te functioneren. Een opleiding met een specialisatie in software testing is dan wel weer perfect mogelijk. De vraag blijft dan in welke mate zo’n opleiding je voorbereidt op het werkveld. Veel bedrijven klagen namelijk dat beroepsopleidingen jongeren niet genoeg voorbereiden op het echte werk, maar het blijft per slot van rekening een educatieve opleiding, geen bedrijfsopleiding voor een bepaalde functie. Dat geldt voor software testing, maar ook voor andere IT-functies zoals analisten.
@ Gert: een mooie vergelijking. Als testers helpen wij vooralsnog de lijken te verstoppen. Misschien moeten we starten met het opgraven van de figuurlijke lijken. Er gaat veel mis aan het begin van projecten. Door ons flexibel op te stellen als testers en te roeien met de riemen die we hebben houden we dit probleem in stand. Echter, houden we onze poot stijf dan is er vaak weinig begrip vanuit de opdrachtgever en wordt er toch weer gekozen voor de ‘snelle’ oplossing (die dan achteraf weer meer tijd en geld blijkt te kosten).
Met het kennisniveau en het praktisch toe kunnen passen is in mijn ogen dan ook niks mis. M.i. missen er twee belangrijke aspecten:
1. de durf om eisen te stellen aan het voortraject en ons minder flexibel op te stellen.
2. daarmee ook de kunde om opdrachtgevers er van te overtuigen dat de ogenschijnlijke vertraging die trajecten hier mee op lijken te lopen dik terug verdiend gaan worden (op korte danwel lange termijn).
Mijn oplossing is er een die ik zelf al jaren hanteer en is heel simpel.
drie zaken zijn belangrijk:
1. Stop eens met nadenken over te hanteren testmethoden en technieken en het bedenken van nieuwe ideeén over testen en ga eens aan het werk…, ga testen!
2. Gebruik je gezonde verstand, hanteer een pragmatische methode en blijf niet vasthouden aan methoden en technieken als dit niet werkt in de praktijk.
3. Ken en begrijp de functionaliteit en de bedrijfsprocessen die het te testen systeem of pakket ondersteunt.
Voorbeeld: als je een pensioensysteem test weet hoe een pensioenberekening in elkaar zit. ken de termen binnen de pensioenbranche en weet ze te plaatsen en te hanteren. Kortom: Ken de business waarin jij jouw testactiviteiten uitvoert.
4. Ken je plek. je bent niet degene die het hele ontwikkelproces voor wat betreft kwaliteit wel even kan aansturen en modelleren. Je bent adviseur en je moet met goeie argumenten komen. Het ontwikkelproces is leidend en bepaald, niet de testmanager of coördinator of tester.
1) het slagen van een project en het goed/niet goed testen staan compleet los van elkaar.
goed getest kan nog altijd betekenen => project niet geslaagd.
(daarentegen slecht getest kan ook betekenen => project toch geslaagd)
dat is 1.
2) Testers (ICT-erst) kunnen op testniveau komen, maar bedrijven niet.
reden:
informatie over testen, cursussen, aandacht voor testen etc etc kan groeien.
Maar bedrijven die opgestart worden en een applicatietje gaan bouwen waar ze rijk mee worden en dan er achter komen dat het ook mogelijk is om software te testen, zullen altijd blijven ontstaan.
nieuw bedrijf =>testniveau NUL.
Hoe goed we ook zijn, foutloze software zal nooit bestaan.
Het tijdperk van de uitgewerkte functionele specificaties is zeker voorbij. We moeten als testers flexibel zijn en meegaan met de tijd. Dus ons vak evolueert net als andere vakken. Waar het meer en meer op aankomt volgens mij is het vinden van de juiste informatie. Weten waar je die informatie kunt vinden. Als een bouwer weet wat hij/zij moet bouwen, moet een tester ook weten wat hij/zij moet testen. Dus het gaat om kennisdeling. Toch is het volgens mij niet zo dat je kan testen zonder enige vorm van specs. Het toetsen en testen gebeurt altijd op basis van wat het zou-moeten-zijn. Een tijdige toetsing met de klant van de requirements, dat is wat het hele project helpt om de boel weer op scherp te krijgen.
Scholing is belangrijk maar niet de enige voorwaarde voor een goede tester. Enige basiskennis is volgens mij zeker vereist, maar een academische opleiding gaat me wat te ver. Het lijkt me beter in groepen en company-opleidingen testers op een hoger niveau te krijgen. Meer opleidingen die aansluiten op deze tijd van verandering lijken me geen overbodige luxe. Dus meer Agile-opleidingen bijvoorbeeld. En meer uitwisseling tussen testers van verschillende bedrijven.
‘Het tijdperk v.d. uitgewerkte functionele specificaties is voorbij’. Helaas wel.
Ook hier geldt:
Informatie analyse of, tegenwoordig, requirements analyses is een vak. Een vak dat je kan leren, via een gedegen studie op opleiding. En dan heb ik het niet over een 3-daagse cursus of een studieblokje van 1 maandje waarin je ‘alles’ geleerd krijgen over dit mooie vakgebied. En bovendien: tegenwoordig noemt iedereen zich informatie analist of requirements engineer. Dit omdat de huidige schoolverlaters niet bij de bodem willen beginnen (good old programming), want dat past niet bij hun Informatie MANAGMENT opleidingen. Dan wordt je immers opgeleid om direct als projectmanager aan de slag te kunnen gaan. Of als business analist. Requirements engineer, dat kan er dan nog net van af.
Ben zelf nog in de 30, maar heb diep respect voor alle oudere collega’s die al die fraaie, complexe back-end systemen hebben ontworpen waar de jeugd van tegenwoordig via RUP enkel een ludiek front-endje tegenaan weet te gooien.
Als we allemaal weer eens gaan erken dat dit ook gewoon een vak is, waarbij tevens andere talent zoals inzicht, creativiteit en een stukje kunst bij om te hoek komt kijken, dan komt het allemaal weer goed.