Hoe goed zijn we als tester?

19-11-2010 10:33 | Door Jos van Rooyen | Lees meer artikelen over: Testing, ISTQB | Er zijn 17 reacties op dit artikel | Permalink
Computable Expert
Jos van Rooyen
Jos van Rooyen

principal consultant testen

Expert van Computable voor het topic Development

Meer

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.

Reacties op dit artikel
De redactie vindt deze reactie: OKMG, 19-11-2010 16:23
2 opmerkingen: ben het oneens met de auteur dat req. opstellen 'achterhaald en niet realistisch' is.
Een huis wordt ook nog altijd eerst ontworpen, het beton moet stevig genoeg zijn, lengte van de heipalen bepaalt, etc. Voor systeemontwikkeling zou dit toepasbaar moeten zijn.
 
Ik deel de mening van de auteur dat er een hiaat is op professioneel testing educatie op academisch niveau. Ik vraag me overigens af of NL hier uniek in is (mij zijn geen buitenlandse opleidingen vwb testing op academisch niveau bekend).
De redactie vindt deze reactie: OKRob van Steenbergen, 19-11-2010 16:40
Jos legt hiermee weer eens de vinger op de pijnlijke plek. Door gebrek aan goede opleidingen voor testers in IT studies komen we niet tot het niveau waar we eigenlijk op zouden moeten zitten. De enige manier om een bepaald niveau te halen in het testvak is dan ook het leren van het vak in de praktijk. Als je geluk hebt, krijg je goede begeleiding mee, met minder geluk leer je van je fouten. Met nog minder geluk haak je af als tester omdat het onderbelichte vakgebied ook bij veel organisaties niet populair is. Doordat het een onbekend gebied is voor veel IT specialisten, managers, enzovoort is de kreet "onbekend maakt onbemind" hier onverminderd van toepassing.
 
"De tester als pispaal, het minst populaire teamlid". Echt waar, beide kreten nog gehoord dit jaar en wij als testers moeten vanaf de werkvloer het testen zelf maar proberen te promoten. Houdt dat maar eens vol, kan je beter gaan programmeren, configuratie specialist worden of iets dergelijks.
En dan blijven er niet veel test-vakbroeders over om het testen ook nog eens te gaan verbeteren. Mijn motto is: zijn er geen goede requirements, dan maar rondvragen en informatie weghalen bij de kennisdragers en wat meer testuitvoer doen op een "onderzoekende manier", wat wij testprofesionals ook wel "Exploratory Testing" noemen. En dit doe ik dan om maar voortgang te houden binnen de deadlines van projecten onder druk.
 
Maar hoe dan verder? Vaak is testen in project het enige wat nog bijdraagt aan kwaliteits- inzicht en bewustzijn. De tijd en ruimte nemen om alternatieven te zoeken op missende requirements? Of toch maar eens de lead gaan nemen in het bevorderen van de totale kwaliteit met betrekking tot het maken van IT systemen? En dan niet op de manier van "proces-beschrijvingen-maken-en-iedereen-moet-het-maar-volgen", dat is al een tijdje achterhaald. Vanuit dezelfde 'drive' die veel testers hebben kan je hier op een creatieve manier zoveel meer doen.
 
Mijn eerste gedachten en kleine bijdrage op dit onderwerp, nu nog nadenken over hoe dit 'nieuwe testen' dan vorm zou moeten krijgen...
De redactie vindt deze reactie: OKWilco van Esch, 19-11-2010 22:20
Goed artikel.
 
In reactie op MG, er wordt niet gesteld dat het opstellen van requirements achterhaald is. Maar als het voorkomt dat requirements niet voldoen aan onze verwachtingen, dan moeten we flexibel genoeg zijn om toch aan de gang te gaan (op de genoemde manieren).
 
We hebben dan denk ik wel de verantwoordelijkheid te zorgen dat zoiets niet nog eens voorkomt, en dat testers ingepland zijn om de wireframes te evalueren, en het technisch ontwerp, etc.
 
Wat betreft de testopleiding, hoe zou zoiets eruit kunnen zien? Dat zou een interessante discussie zijn. Waar ik zelf het eerste aan denk is een (intensieve) Master, maar dat zeg ik voornamelijk omdat ik zeer verschillende achtergronden zo nuttig vind in test teams. Ik weet niet of er meerwaarde in een traditionele 4-jarige opleiding zou zitten.
De redactie vindt deze reactie: OKPaVaKe, 19-11-2010 23:15
Er wordt gesteld :
"Ja, we volgen ISTQB Foundation, etc. en denken dat we dan professioneel zijn."
 
En wanneer denken we dan "principal consultant testen" te zijn ???
 
Niet dat ik afbreuk wil doen aan de auteur. Ik ken hem niet, en wil dan ook geen oordeel vormen of hij die titel al dan niet terecht draagt.
 
Maar de stelling reikt vele malen verder dan alleen tester. Hoeveel van de "professionals" in de gehele ICT hebben zichzelf een dure titel aangemeten, noemen zcih expert, consultant of wat dan ook, terwijl ze net als de tester slechts één of enkele cursussen gevolgd hebben.
 
Zelf heb ik ook ISTQB foundation gedaan, maar ik noem me absoluut geen tester (bij mij was het een stukje horizonverbreding)
 
Inhoudelijk wil ik nog een paar dingen kwijt:
- dat een groot deel van de ICT projecten faalt, ligt in mijn ogen niet aan de testers. Deze voeren slechts een verificatie/validatieslag uit van hetgeen gespecificeerd is. Als de architecten, designers en programmeurs er een zootje van maken, zal de tester degene zijn die dit op zal merken, maar daarmee treft hem (of haar uiteraard) geen blaam voor het falen van het project
- met een paar goede testers in je organisatie ben je er nog lang niet; het moet ingebakken zijn in je ontwikkel en vrijgaveproces. Hierbij is belangrijk dat er geen enkel product de deur uit mag zonder dat het getest is. Nog belangrijker is dat testen niet als sluitpost in de planning wordt gezien. Ik heb al te vaak gezien dat, wanneer het maken van het product uitloopt, er beknibbeld wordt op de test-tijd om toch maar op tijd naar de markt te kunnen gaan.
- zoals met alle disciplines maakt een cursus volgen geen tester van je. Testen moet deels ook in je genen zitten; je hebt een bepaalde attitude, gedrevenheid en vasthoudendheid nodig om een goede tester te worden. Dit is niet iedereen gegeven
De redactie vindt deze reactie: OKKaspar, 20-11-2010 9:36
@Pavake: een aantal ICTers heeft zo'n titel zich niet zelf aangemeten maar wordt als zodanig verkocht door hun werkgever aan de klant... Als schoolverlater zijn ze dan 'consultant'. Wanneer ze 1 project hebben gedaan, dan wordt het etiketje vervangen door 'senior consultant'.
De redactie vindt deze reactie: OKPaVaKe, 20-11-2010 15:38
@Kaspar
 
Klopt, en dat vind ik zelfs nog veel erger; hoe "duurder" de titel, hoe meer de werkgever voor hem/haar kan vangen
 
Dit komt de inhoud die je van bepaalde titels verwacht niet ten goede.
 
De bescheiden specialist komt helaas nauwelijks meer aan de bak als hij zich specialist noemt. Noemt hij zichzelf consultant, geniet hij ineens meer aanzien
De redactie vindt deze reactie: OKRichard Enthoven, 22-11-2010 9:02
Goed artikel. Met name het stuk dat we meer op moeten en kunnen pakken op het gebied van requirements.
 
Overigens is er wel een minor 'Test engineering' bij de opleiding Informatie op de Hogeschool Rotterdam: http://hro.nl/eCache/DEF/1/68/872.html
 
Dit zijn echter geen vakken/college's, maar een duaal traject van 1,5 jaar bij een bedrijf.
De redactie vindt deze reactie: OKPeter Swaanenvelt, 22-11-2010 10:21
Ik denk dat we met testen al goed op weg zijn. De vraag is hoeveel verder we het testvak kunnen professionaliseren zonder dat andere vakgebieden hetzelfde doen. Testers maken een (master) testplan. Iedereen doet daar een plasje over ... ook ontwerpers en bouwers. Over iedere komma wordt soms gediscussieerd. Maar heeft iemand al eens een (master) bouwplan of ontwerpplan gezien.
 
Zonder professionalisering van alle vakgebieden binnen een IT project heeft het geen meerwaarde (in de vorm van hoger slagingspercentage van projecten) om 1 vakgebied er te veel bovenuit te laten steken. We moeten niet als testers stil gaan zitten, maar ook onze projectcollega's aanmoedigen.
De redactie vindt deze reactie: OKMG, 23-11-2010 12:14
@Richard;
dank voor je tip m.b.t. de minor. Heb je ervaring met deze minor? Hoe ziet deze minor er in de praktijk uit?
 
De redactie vindt deze reactie: OKRichard Enthoven, 23-11-2010 15:28
@MG:
Ja, ik heb deze minor zelf gevolgd. Vanuit de opleiding kreeg ik weinig tot geen testkennis. Alle testkennis die ik heb opgedaan is bij mijn duale bedrijf geweest. Sogeti in dit geval. Vanuit Sogeti was er geen speciaal programma voor mij, daarom draaide ik gewoon met de startende werknemers mee.
 
Verder weet ik wel dat er vanuit de Hogeschool Rotterdam steeds meer aandacht aan software testen wordt gegeven.
De redactie vindt deze reactie: OKTestNerd, 26-11-2010 14:58
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.
De redactie vindt deze reactie: OKGert, 28-11-2010 13:07
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.
De redactie vindt deze reactie: OKCaroline, 30-11-2010 16:00
@ 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).
De redactie vindt deze reactie: OKFT, 14-12-2010 12:03
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.
De redactie vindt deze reactie: Goedtestzorro, 01-02-2011 12:54
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.
De redactie vindt deze reactie: OKIris Ronnes, 14-02-2011 20:03
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.
De redactie vindt deze reactie: OKInfoAnalist, 14-02-2011 20:52
'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.
94 vacatures
Developer

Matthat Sofware B.V. , Gouda

Web Developer ASP.NET C# (Medior / Senior)

NiDiDo BV , Barneveld

PHP Programmeur

BWSS B.V. , Deventer

.NET (C#) Programmeur

Let's build IT , Hoorn NH

Pielen in PHP, of on Rails in Ruby?

ForecastXL (via Quoratio BV) , Groningen

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1575 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1272 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 1000 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 528 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0