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.
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).
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…
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.
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
@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’.
@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
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.
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.
@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?
@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.