Auteur: John Kronenberg ● John.Kronenberg@closesure.nl
In de afgelopen tien jaar is de rol van de tester drastisch, dramatisch voor velen, veranderd. De tester van nu moet naast testvaardigheden ook heel goed technisch onderlegd zijn. De tester van nu moet ook testautomatisering kunnen inrichten en bijvoorbeeld zelf fixtures in Java, Selenium Webdriver scripts of Cucumber stepdefinitions kunnen programmeren.
Bij mijn huidige klant ben ik in de positie om CV’s voor nieuwe inzetten te mogen beoordelen. Wat me opvalt aan de CV’s is dat veel van de sollicitanten, met een ijzersterke testachtergrond, testautomatisering in hun CV’s hebben geschreven, omdat dat de aanvraag was of omdat hij/zij anders nooit meer aangenomen wordt voor een testrol. Maar niet omdat ze de ambitie en persoonlijke kwaliteiten hebben goed te worden in testautomatisering. Testautomatisering en testen zijn twee verschillende rollen. Een goede bakker is over het algemeen geen goede slager, dit gaat ook op voor een tester versus een testautomatiseerder. De vraag die ik in dit stuk wil beantwoorden is of dat erg is. Moeten we (technische) testers niet gewoon goede (technische) testers laten zijn? Is er op de huidige projecten niet zowel ruimte voor goede (technische) testers als goede testautomatiseerders / developers?
Wat is testautomatisering?
Voordat ik mijn punt probeer te maken wil ik eerst beschrijven wat ik onder testautomatisering versta. Eigenlijk dekt het woord testautomatisering helemaal niet accuraat genoeg waar het in dit stuk over gaat. Geautomatiseerd testen is een beter begrip. De volgende, niet door mij opgestelde, definitie dekt mijns inziens de lading dus ik neem hem hier integraal over: ‘Automated testing is the act of conducting specific tests via automation (i.e., a set of regression tests) as opposed to conducting them manually, while test automation refers to automating the process of tracking and managing the different tests.’
Zo bezien is maar een klein onderdeel van testautomatisering het automatiseren en geautomatiseerd uitvoeren van regressietesten, waarbij testautomatisering zelf ook weer een klein onderdeel uitmaakt van een ander containerbegrip: Continuous Testing. Waar een senior testautomatiseerder vaardig in is, maakt in essentie maar een klein gedeelte uit van wat het veld op dit moment verwacht dat een goede tester moet kunnen. Een testautomatiseerder is skilled in het implementeren van een testautomatiseringsframework, waarbinnen test-artefacten een plaats hebben, en het programmeren van de code (Java, Python, Javascript etc.) om deze test-artefacten geautomatiseerd uit te kunnen voeren. Als iemand mij vraagt wat mijn rol bij mijn klanten is, dan zeg ik dat ik Software Engineer in Test ben, ik automatiseer testen.
Om BDD als voorbeeld te nemen. Het maken van feature files, het opstellen van testscenario’s en het definiëren van teststeps kan prima door een tester, of in een Three Amigo’s setting worden opgesteld. Een testautomatiseerder kan verantwoordelijk worden gemaakt om deze teststeps in testautomatiseringscode (stepdefinitions) vast te leggen.
Goede testers zijn nodig
Ik ben van mening dat er op dit moment voor goed geschoolde, moderne testers, met een gezonde portie technische kennis, maar zonder kennis van en affiniteit met het maken van testautomatiseringscode, veel kansen (zouden moeten) liggen. Testautomatisering is een specialistische rol die door een testengineer die zich erin heeft bekwaamd, of door een developer kan worden uitgevoerd. De vaardigheden om een goede tester te zijn, zijn niet de vaardigheden om een goede testautomatiseerder te zijn en dat zou niet erg moeten zijn. De rol die een tester mijns inziens zou moeten pakken is het ondersteunen van de testautomatiseerder of developer. Hij kan testautomatiseringscode onderhouden, hij helpt bij het maken van Jenkins jobs en voert exploratory testing sessies uit, heeft veel technische bagage, begrijpt wat webservices en api’s zijn. Naast testautomatisering hebben projecten nog steeds goede testers nodig. Het is mooi meegenomen dat testers ook de testautomatiseringsrol kunnen pakken, maar noodzakelijk is dit mijns inziens niet.
Conclusie
Toen ik mijn carrière als testautomatiseerder begon, was TestFrame erg hot. Binnen TestFrame was er een duidelijke afbakening van de rollen tester en testautomatiseerder. De tester maakt de Excelsheets met actiewoorden en de testautomatiseerder programmeert de actiewoorden. Dit is een hele krachtige rolverdeling. Ik zou wensen dat het veld zich realiseert dat testers, weliswaar met voldoende begrip van de werkzaamheden van testautomatiseerders, bezig zouden moeten zijn met waar zij goed in zijn geworden, testen, en niet verplicht moeten worden om een rol te pakken die niet goed bij die persoon past. Dat is in het voordeel van de gehele testgemeenschap, zowel testen als testautomatisering als vak wordt dan (weer) serieus genomen.
Beste John, Ik vind het een goed duidelijk artikel. Dit lijkt mij inderdaad de wenselijke situatie. Mijn ervaring bij solliciteren in detachtering is echter dat je geen kans hebt als je niet aangeeft je loopbaan als tester volledig technisch te willen richten en er wordt mijns inziens op de eerste plaats naar je technische vaardigheden gekeken. Testautomatisering lijkt een volledige hype te zijn. Ik echter als tester de combinatie (functioneel en automatisch testen) en ik denk ook dat niet alles is te automatiseren.
Beste John,
Ben het geheel met je eens.
Laat staan, tegenwoordig zeggen ze dat een ‘technische tester’ gelijk is aan een ‘test automatiseerder’.
Hiermee ben ik het dus ook niet eens.
Ik zie mijzelf als een ‘technische tester’ en hieronder versta ik voornamelijk backend testen (API testen, jobs, Databases, DWH testen, enz.).
Tevens willen veel bedrijven mee op de ‘hype’ van ‘test automatisering’.
Alleen mij is ooit geleerd (ja bij dezelfde werkgever (L CMG) als waar jij toen werkte) dat je pas moet gaan automatiseren als er ‘een stabiele basis’ is en niet gelijk in de start van een nieuw project.
Helaas is dit blijkbaar tegenwoordig wel wat veel bedrijven willen.
Ook als je testautomatisering niet op je CV hebt staan, kom je vaak al niet eens meer op gesprek voor een intake.
Terwijl test kennis/inzicht volgens mij belangrijker is dan maken van een automatische test.
Maar ja, we zullen zien waar de markt naar toe gaat.
Gr.
Bas Rauwers
Gedeeltelijk akkoord.
Niet iedereen moet een test framework kunnen opzetten en onderhouden. Ik vind echter wel dat iedere tester toch wel een minimum aan technische vaardigheden moet hebben: een SQL query maken, enkele Batch/Bash/Powershell scripts kunnen maken, etc. Dus enige kennis van programmeren is zeker meegenomen voor iedere tester. Al is het maar om te begrijpen waar de ontwikkelaars het over hebben.
Aan de andere kant vind ik dat de test automatiseerder ook moet kunnen testen en de business kennis heeft om te weten wat hij aan het testen is. Je vermeld TestFrame, heb ik vroeger ook gebruikt. Als je echter de keywords (of BDD step definitions) laat implementeren door een technisch persoon zonder business kennis, kan je wel eens voor akelige verrassingen komen te staan: bepaalde controles in het keyword die niet (voldoende) gedaan worden, essentiële stappen die overgeslagen worden, etc.
Het gedrag zit ‘verborgen’ in de code van het keyword, dus als de tester die code niet kan begrijpen, veronderstelt hij dat bepaalde controles gedaan worden, terwijl dat misschien niet zo is. Goede communicatie helpt natuurlijk, maar dat is ook weer overhead.
Dus: het team moet zowel technische als de business kennis hebben. Moet iedere persoon in het team dat hebben? Neen, maar liefst wel zoveel mogelijk.
Ik denk dat het de keiharde realiteit is, dat puur functionele testers (black box testers met bedrijfskundige achtergrond zonder technische affiniteit) overbodig zijn geworden, net zoals testcoördinatoren, project- en testmanagers. Er wordt niet meer met PRINCE2 en de watervalmethode gewerkt, organisaties werken lean en agile en hebben het middle management weggesneden. TestFrame is een reliek uit het verleden, daar doet vrijwel niemand nog iets mee, het kan er ook aan liggen dat CMG allang niet meer bestaat, dat er geen vraag meer naar is.
Hooguit in omgevingen waar gebruikersacceptatietests een grote rol spelen wordt er nog “ouderwets” gewerkt, de rest werkt met scrum- en DevOps teams waar geen duidelijke definitie is wat eenieder doet, je bent “engineer”. Wel met je specialisme, het is echt onzin dat je alles moet weten van development of beheer, echter je moet wel snappen waar ze het over hebben. In de moderne wereld waarin het pushen van nieuwe features naar productie zo snel mogelijk (lees: geautomatiseerd) dient te gebeuren, is een “testfase” waarin handmatig wordt getest alleen maar hinderlijk. Ja, kwaliteit gaat daarbij vaak het putje in en ja, dat doet pijn als je al 20 jaar getest hebt, maar wie betaalt, bepaalt. De belangrijkste rol die je als tester in dit geheel hebt, is het vaststellen waar de grootste risico’s zijn en verlangen dat het team c.q. de product owner daar prioriteit op legt. Maar als je niets met automatisering kunt of wilt doen, dan wordt het vrij lastig om in dergelijke teams te functioneren (uitzonderingen daargelaten uiteraard)
Hi John, we hebben destijds (2012) bij het schrijven van het boek “Bepaal je koers! Toekomst en trends in testen” deze ontwikkeling gesignaleerd en erover geschreven. We kwamen toen tot de conclusie dat testers drie ontwikkelpaden konden kiezen:
1. Richting techniek en testautomatisering
2. Richting (business) inhoud; in de praktijk zie je steeds meer dat een rol als tester en een rol als requirements engineer of business analist worden gecombineerd of dat een tester zich ontwikkelt tot Product Owner
3. Richting faciliteren / coachen. Waarbij je ziet dat testers een Scrum Master rol erbij pakken of fulltime Scrum Master of Agile coach worden.
Overigens is er een “tussenweg” op het gebied van testautomatisering die ik in je verhaal mis. Met een framework als Robot Framework, kun je keyword drive testen (= met actiewoorden) zonder die actiewoorden te hoeven programmeren. Er zijn talloze open source bibliotheken met actiewoorden die gebruikt kunnen worden en waarmee je “out-of-the-box” al veel testen kunt automatiseren. Indien gewenst kan een tester die goed is in testaumatisering of een developer aanvullende custom keyword definitions programmeren. Dat gaat heel laagdrempelig in het framework.
En natuurlijk zijn er commerciële tools als Tosca, waarbij de actiewoorden door de leverancier zijn geprogrammeerd en indien gewenst worden die uitgebreid door een consultant van de leverancier (waar je dan uiteraard dan wel voor betaalt).
Een ander aspect is dat er steeds meer mogelijkheden komen op het gebied van unit testen / frameworks voor testen op component niveau of integratie van componenten. Als de testpiramide dan wordt gevolgd en 80-90% van de testen op “low-level” niveau (door developers) worden uitgevoerd, blijft er steeds minder werk over voor de functionele testen en regressietesten op systeemtest niveau. Vaak zoekt een team dan iemand die zowel die functionele testen handmatig kan uitvoeren en wat exploratory testen kan doen en die óók een stukje testautomatisering van de regressietest op systeemtestniveau kan doen. Ik begrijp dat wel.
Ik waardeer je pleidooi voor de kwaliteiten van de functionele tester, maar denk dat de meesten echt een keuze moet maken om er wat bij te gaan doen (zoals ik schreef m.b.t. bijv. business analist taken of een Scrum Master rol).
Om snel en continue te kunnen leveren is de inzet van testautomatisering essentieel. Maar er moeten daarnaast ook eisen worden gesteld aan de rest van de organisatie, inclusief de te ontwikkelen software. Oude legacy is vaak moeilijk te automatiseren. Ik zou dit soort opdrachten dan ook weigeren. Ik laat ze liever over aan de functionele testers, die gelukkig blijven met klik-en-klak werk. De vraag is echter hoe lang je dit nog kan blijven doen.
Om duurzame testautomatisering te ontwikkelen is technische kennis nodig. Hoe kun je risico’s detecteren als je geen programmeerkennis hebt en onderliggende, potentiele gevaren niet snapt? Ik snap gewoon niet dat nog zoveel testers weigeren zich over te geven aan het feit dat kennis van een taal als Java of C# een absolute must is. Door testautomatisering steeds over te laten aan de developer geven we ons werk uit handen….
Veel is al gezegd.
Ik wil nog wel toevoegen dat je als tester het beste weet wat er getest moet worden. Een developer weet meestal het beste hoe het getest kan worden. Je kan wel jezelf bekwamen als Engineer/automatiseerder maar je wordt niet snel zo goed als mensen die er voor geleerd hebben en jaren ervaring hebben.
Daar tegenover staat dat er veel legacy systemen zijn waarbij developers absoluut geen zin/tijd hebben om de test-automatisering (AFT heb ik het dan over) te doen.
Naar mijn mening voor engineers: unit testen, test driven development, integratietesten (deels), AFT opzet en low level keywords (bv in Python). Voor tester: integratietesten controleren en aanvullen. AFT schrijven op functioneel niveau, explorarory en functioneel testen.
Ik denk dat test-automatisering ook vaak wordt overschat. de meeste fouten worden gevonden tijdens het maken van een test. Daarna vooral om stabiliteit te checken en zelfs dat heeft zijn keerzijden. Als je volledig vertrouwt op AFT mis je vaak dingen die de AFT niet ziet. DIe test alleen dingen die je zelf erin hebt gestopt.
Verder willen/moeten veel testers het kunnen, maar niet iedereen kan het.
Gelukkig willen de meeste Software engineers het niet doen. Dus dan kunnen wij het als tester mooi overpakken. Pas wel op voor te grote investering met weinig rendement als je vanaf scratch zonder veel technische kennis gaat programmeren.
En Robert, ik snap dat jij dat zegt, jij kan programmeren.
Maar genoeg werk voor een Functionele tester voorlopig.
Ik ben wel benieuwd naar de invloed die AI kan hebben. Tot woensdag dus!
Goed stuk!
Verbaas mezelf er al tijden over dat men vaak testautomatisering als toverwoord gebruikt. Testen is namelijk veel meer dan het automatiseren van de testuitvoering. Ik vraag me dan ook vaak af wat er geautomatiseerd wordt uitgevoerd. Wordt hier nog wel over nagedacht en wordt hier wel een weloverwogen keuze voor gemaakt?
Dus testautomatisering op zich zegt niets, het gaat er meer om wat je uiteindelijk automatiseert en daar kan m.i. alleen de ‘echte’ tester (testen is een vak!) een goed antwoord op geven!