Redactie: Paul Beving
Auteur: Gerben de la Rambelje ● g.delarambelje@maxmin.eu
Een aantal jaar geleden werd steeds vaker verkondigd dat wij als testers op termijn niet meer nodig zijn. Reden voor deze stelling was dat er in de toekomst steeds meer testen geautomatiseerd zullen worden, waardoor wij als beroepsgroep overbodig zouden zijn. Zeker met de introductie van DevOps zou dat helemaal verleden tijd zijn, dat testers onderdeel zijn van het softwareontwikkelproces. De laatste tijd hoorde ik weer een paar keer: ‘de tester is history’. Wat gek is dit, toch zie ik dat er geen grote ontslaggolf is geweest of dat die ophanden zijn. Sterker nog, onze vereniging TestNet is met een ledental van tweeduizend groter dan ooit. Vind maar een vereniging van specialisten in Nederland en wellicht ook in Europa, die minimaal net zo groot is. Dat wij als TestNet zoveel leden hebben, geeft aan dat er heel wat bedrijven in Nederland zijn die testers in dienst hebben of inhuren, omdat ze gewoonweg nodig zijn.
Testen is onzichtbaar
Hoe kan het dan toch dat wij als testers zo onzichtbaar zijn, dat mensen denken dat we geen toegevoegde waarde hebben? Ik denk zelf dat het ligt in feit dat wij als testers niets anders produceren dan alleen maar testplannen en bevindingen. Al die activiteiten, die wij als bruggenbouwer uitvoeren tussen de business en IT worden niet onderkend of voor lief genomen. Over de zin van het testen in de IT, daar heeft Huib Schoots een mooi artikel over geschreven: ‘Testen is dood. Nee hè, toch niet alweer?’
Het testvak is volop in ontwikkeling
Dat het testvak volop in ontwikkeling is, dat valt niet te ontkennen. Fatih Topcuoglu geeft in zijn artikel ‘De Nieuwe Tester Anno 2018’ aan dat de tester tegenwoordig meer moet kunnen dan alleen maar testen. En natuurlijk heb je als tester ook veel meer toegevoegde waarde als je ook op het technische vlak alleen al in discussies kan meekomen, of complexe oplossingen ook echt snapt. Het zou meegenomen zijn als je al tester je skills kunt verbreden door je een moderne programmeertaal eigen te maken.
Ontwikkelen technische vaardigheden
Maar de vraag is dan hoe je als tester je technische skills kunt verbeteren, zodat je op korte termijn daar snel profijt van hebt. De vraag is welke cursussen je hiervoor kunt volgen en waar moet je nou heen om deze te volgen? Nuttig is dat je eerst op je huidige werkplek uitzoekt welke technologieën er zoal gebruikt worden en welke voor jou echt van toepassing zijn in je dagelijkse werkzaamheden. Op de onderstaande websites vind je nagenoeg altijd wel goede online trainingen waar je echt heel erg veel van kunt leren:
Of wil je de basisprincipes van een programmeertaal goed begrijpen met het doel te leren programmeren, dan is er wat mij betreft één held bij wie je dat goed kunt leren: Bucky Roberts. Via zijn youtube kanaal kun je video-tutorials van vele programmeertalen vinden.
Wil je daarnaast een goed stappenplan volgen om je als tester te verbeteren, dan kan het artikel ‘Testers, neem de regie over je eigen toekomst!’, geschreven door Marco de Vink en Willem ten Brinke, je wellicht daarbij helpen.
De tester en de toekomst
Ik verbaas me elke keer weer hoeveel goede testers ik dagelijks tegenkom. Want of ze nu veel technische bagage hebben of functioneel heel veel weten over de business, ze zijn onmisbaar. Zijn ze er niet meer, dan gaan organisaties dat direct merken. Ik verwijs alleen al naar de vele nieuwsberichten, die in de media verschijnen over producten of diensten die gefaald hebben door onder andere een fout in de software. Kennelijk waren die organisaties vergeten dat je een goed slot op de deur nodig hebt.
Het gevaar dat nu overigens dreigt, is dat op lange termijn geen hardcore-testers meer worden gevormd. Mede doordat vele testers in grote mate ‘alle werkzaamheden’ doen (T-shaped), kunnen zij zich niet meer alleen focussen op uitsluitend het testen. Dus iemand die netto vijf tot tien jaar software heeft getest, wordt erg zeldzaam en dat is echt iets om over na te denken.
Hoe dan ook, wat ze over ons mogen denken of schrijven, wij als testers zijn de laatsten die het licht uit doen.
Hallo Paul,
bedankt voor interessante artikel.
Het lijkt mij als tester nuttig afhankelijk van de context waarin je werkt dat je kennis hebt van programmeren. Hierdoor kan je je beter verplaatsen in de programmeurs. De specifieke programmeertaal lijkt mij minder belangrijk maar vooral de principes (b.v. if-constructies/ lussen). Deze komen in veel programmeertalen voor. Ik zelf heb door mijn studie Informatica kennis van JAVA. Daarnaast heb ik vanuit mijn werk als functioneel beheerder ervaring opgedaan met VBA en SQL.
Daarnaast wordt volgens mij vaak vanuit de markt kennis en ervaring van testautomatisering gevraagd. Ik vraag me soms wel af in hoeverre dit ook echt noodzakelijk is bij je werk aangezien lang niet bij alle bedrijven succesvol testautomatisering wordt toegepast. Als er al testautomatisering wordt toegepast, is dat vaak voor een beperkt gedeelte van het testwerk, namelijk regressietesten (alhoewel natuurlijk belangrijk). En volgens mij houdt zich vaak binnen een organisatie een specifieke tester bezig met testautomatisering. Het valt namelijk tegen hoeveel tijd dit kost (je kan het niet zomaar erbij doen). Maar ik probeer wel de markt te volgen door een cursussen te doen: ISTQB advanced technical analist en SOAP UI. Voor testautomatisering blijkt vaak programmeren noodzakelijk te zijn.
Hi,
Je hebt helemaal gelijk dat Testautomatisering opzetten en onderhouden niet zomaar een klus is die je zomaar doet. In feite zet je een extra Software ontwikkelstraat op, waar dus ook versiebeheer op gedaan moet worden. In de praktijk zie je vaak dat testautomatisering wel wordt opgezet, maar niet goed wordt onderhouden waardoor het zijn doel niet bereikt.
Hi,
We hebben volgens mij beide wel gelijk. Maar van de andere kant wordt het dus wel het heel vaak gevraagd bij test vacatures en steeds meer. Dus je kan maar beter die kennis en ervaring hebben…
Ik probeer dus zelf me wat bij te scholen. Maar dit op zich wel leuk.
“Mede doordat vele testers in grote mate ‘alle werkzaamheden’ doen (T-shaped), kunnen zij zich niet meer alleen focussen op uitsluitend het testen. ”
Is het zo erg dat een tester breder kijkt dan alleen het testen? Wordt de tester daar minder “hardcore” van? Ik denk het niet, hoewel het voor de traditionele tester die het liefst volgens het watervalprincipe test in hiërarchisch georganiseerde testteams, steeds lastiger zal worden. Vooral voor testcoördinatoren en testmanagers is in de meeste organisaties geen plaats meer.
Nu ik daar toch op kom. Waarom zijn het alleen de testers waarvan verlangd wordt dat ze ‘alle werkzaamheden’ doen. Een developer die gaat testen is extreem zeldzaam, die verdiept zich liever verder in de techniek dan in een andere discipline, zoals testen. Een business-analist zal met tegenzin gaan testen, die wil zich bezighouden met de business. Een tot scrum master of product owner gebombardeerde teamleider resp. projectmanager zal zich niet met de inhoud bemoeien. Juist aan testers die zowel van de techniek als de business verstand hebben, die weten hoe het scrumproces werkt (zowel binnen als buiten het team) en die weten hoe het proces van software-ontwikkeling zich afspeelt van ontwerp tot beheer, daar is behoefte aan. Want een tester heeft een natuurlijk ingebakken nieuwsgierigheid die zich niet alleen beperkt tot het te testen stukje software zelf.
Het is zeker niet verkeerd dat een tester breder kijkt, de ware tester doet dat maar al te graag. Maar Paul heeft wel gelijk dat het ‘dedicated’ testen er op deze manier bij gaat inschieten. Een mens is nou eenmaal beperkt en kan maar een ding tegelijk als-ie het goed wil doen. Iemand die volledig op testen is gericht ontdekt vaak andere dingen dan iemand die meerdere aandachtsgebieden heeft. Beide zijn niet verkeerd, maar anders en dat lijkt me in dit vak juist van belang. Ik zou zeggen: houdt de tester die testen als zijn hoofdtaak ziet in ere, voor je het weet zijn ze inderdaad zeldzaam.
Hier is een leuk statement: Test automatisering bestaat niet.
Een test tool maakt geen mentaal model van de applicatie, architectuur, risico’s en projecten. Een testtool zal geen overleg plannen met een business analist, product owner of -manager om informatie in te winnen. Een test tool heeft ook geen geweten en zal niet escaleren als een organisatie een risico bewust of onbewust negeert. Exploratory testen laat zich m.i. niet automatiseren – althans, nog niet.
Eigenlijk is de term test automatisering al misleidend, en suggereert dat testen zich laat automatiseren. Iets wat volgens James Back – mijn held – pas mogelijk is als AI realiteit wordt.
De kracht van tooling – mits goed opgezet – ligt in het uitvoeren van grote volumes aan checks die een vast script volgen, die te tijdrovend zijn om handmatig af te werken. Maar checklists afwerken is niet hetzelfde als testen.
Bedankt voor het leuk artikel! Ik zie het testvak niet heel gauw ophouden te bestaan hoor. Vooral niet met de hoge snelheid waarop de technologie vooruitgaat. Hoe belangrijk zijn testers dan niet? Een computer kan bevindingen vastleggen, maar mensen hebben emoties.