20 okt 2026 Test automation engineer aannemen: waar let je echt op?

In het kort: Een test automation engineer bouwt en onderhoudt geautomatiseerde tests die bij elke wijziging je grootste risico’s controleren. Neem je er een aan, dan telt toolkennis minder dan je denkt. Een tool leer je in een paar weken. Risico’s inschatten, testontwerp en je bedrijfsproces begrijpen kosten jaren, en juist die bepalen of je automatisering je releases beschermt.

De vacaturetekst is meestal het makkelijke deel. Er staat Playwright of Selenium in, misschien Tosca, een paar jaar ervaring en een ISTQB-certificaat. Je vindt iemand die aan alles voldoet, en een jaar later heb je honderden geautomatiseerde tests. Toch voelt elke release nog spannend, en niemand kan zeggen wat die tests eigenlijk afdekken. Dat begint bij hoe je de rol omschrijft. Daar beginnen we dus ook.

Wat doet een test automation engineer?

Een test automation engineer bepaalt welke controles een computer voor je herhaalt, bouwt die controles en houdt ze werkend. De tests draaien in je pipeline, elke nacht of bij elke wijziging, en waarschuwen het team als er iets breekt. De tool is alleen het middel. Het echte werk is kiezen wat je test. Denk aan de bedrijfsregels die geld kosten als ze fout gaan, de koppelingen met andere systemen en de routes die je klanten elke dag gebruiken. Een goede engineer houdt de testset ook klein genoeg om snel te draaien en stabiel genoeg om te vertrouwen. Faalt een test, dan moet het team dat geloven, en niet zijn schouders ophalen en hem opnieuw starten. Dat betekent tests schrijven als goede code: leesbaar, herbruikbaar en makkelijk aan te passen door een collega. En het betekent uitkomsten in gewone woorden uitleggen aan mensen die niet testen. De product owner en de manager bepalen of een release live gaat, dus zij moeten het begrijpen.

De functienaam wisselt. Je ziet QA engineer, SDET, testautomatiseerder of test automation specialist. De taken lijken sterk op elkaar. Waar het om gaat: denkt iemand eerst als tester en pas daarna als programmeur?

Waarom gaat aannemen op toolkennis mis?

Aannemen op toolkennis gaat mis, omdat de tool het deel is dat je het makkelijkst leert en het makkelijkst vervangt. Bij klanten zien we vaak dat de werving draait om Playwright, Selenium of Tosca. Maar risicoanalyse, testontwerp en het begrijpen van bedrijfsprocessen zijn minstens zo belangrijk. Het gevolg is automatisering zonder grip. Er zijn genoeg tests, maar ze controleren wat makkelijk te automatiseren was, niet wat riskant is. De dekking ziet er goed uit, en toch blijven er ernstige productie-incidenten komen.

Er is nog een effect. Een team dat één toolspecialist aanneemt, eindigt vaak met een framework dat alleen die persoon begrijpt. Vertrekt hij of zij, dan vertrekt de kennis van de testopzet mee. De volgende engineer begint met opnieuw bouwen, vaak in een andere tool. De tool is veranderd, het probleem niet.

Tools veranderen bovendien snel. Een paar jaar geleden gebruikten veel teams nog geen Playwright. Wie testen begrijpt, stapt in een paar weken over op een andere tool. Wie alleen een tool kent, leert niet zomaar in risico’s denken.

Welke vaardigheden tellen zwaarder dan de tool?

Vijf vaardigheden bepalen of een test automation engineer je releases veiliger maakt. Toolkennis helpt, maar komt daarna:

• Risicoanalyse. Ziet iemand welk deel van het systeem de meeste schade doet als het breekt, en test hij dat eerst?
• Testontwerp. Kan iemand een paar slimme testgevallen kiezen in plaats van honderden die op elkaar lijken? Denk aan grenswaarden en combinaties die ertoe doen.
• Het bedrijfsproces begrijpen. Vraagt iemand eerst hoe een bestelling, een claim of een boeking echt loopt, voordat er een test komt?
• Onderhoudbare code. Zijn de tests leesbaar, met duidelijke namen en gedeelde bouwstenen, zodat een collega er een kan repareren?
• Uitkomsten uitleggen. Kan iemand een product owner in twee zinnen vertellen wat er faalde en waarom dat telt?

En ISTQB? Het certificaat ISTQB Foundation Level laat zien dat iemand de gedeelde taal van het testvak kent. Dat is handig, want dan praat het team dezelfde taal. Het bewijst niet dat iemand een goede testset kan ontwerpen. Zie het als basis, niet als bewijs.

Hoe dat er in de praktijk uitziet: bij een operationeel centrum van de overheid veranderde een platform voortdurend, en er waren geen regressietests. Onze tester combineerde use-case-testen en exploratief testen met Selenium-automatisering in meerdere browsers. Na elke testcyclus gaf de tester een releaseadvies. De automatisering was één deel van dat werk. Bepalen wat je test en adviseren over de release was de rest. Je leest het in onze casestudies.

Hoe toets je die vaardigheden in een sollicitatiegesprek?

Je toetst die vaardigheden met een klein, echt probleem in plaats van een toolquiz. Drie opdrachten werken goed, en elke opdracht kost ongeveer een kwartier:

1. Een user story. Geef één story uit je backlog en vraag: wat test je als eerste, en waarom? Let op risico en impact op het bedrijf, niet op een lange lijst.
2. Een flaky test. Laat een test zien die soms slaagt en soms faalt. Vraag hoe de kandidaat de oorzaak zou vinden. Een goed antwoord noemt testdata, timing en de omgeving, voordat de tool de schuld krijgt. Daarover schreven we in waarom geautomatiseerde tests falen terwijl er niets is veranderd.
3. Wat automatiseer je niet? Vraag wat de kandidaat aan mensen overlaat. Een goede engineer noemt exploratief testen en acceptatietesten met gebruikers, en legt uit waarom.

Vraag daarna naar een testset die de kandidaat bouwde en die een jaar later nog draait. Wie onderhoudt hem nu? Het antwoord vertelt je of iemand bouwt voor zichzelf of voor het team.

Wat betekent dit voor je team?

Schrijf de vacature rond risico’s, testontwerp en je bedrijfsproces, en zie de tool als detail. Toets die vaardigheden met een echte story uit je backlog. En reken op meer dan één persoon. Een testset die van één engineer afhangt, is zelf een risico: vakantie, ziekte en een nieuwe baan leggen hem allemaal stil. Je teststrategie moet zeggen wie eigenaar is van de automatisering, niet alleen welke tool je gebruikt.

Dat profiel vinden kost bovendien tijd. In een markt waarin 44,7% van de QA-teams zegt onderbezet te zijn, zijn maanden zoeken normaal. Daar komen inwerken, een framework bouwen en onderhoud bij dat met elke release groeit. Soms is aannemen de juiste stap. Soms heb je nu een ervaren tester in je team nodig, en soms een testset die blijft draaien zonder dat hij van één aanname afhangt. Wij doen allebei. Onze testconsultants schuiven aan in je team, in jouw tools en jouw sprints, van teststrategie tot het testen zelf. Technolution, al zes jaar klant, zegt dat onze testers heel goed opgaan in hun projecten. Lees hoe dat werkt op onze pagina over QA en testen. En is wat je echt nodig hebt een regressieset die blijft draaien, dan is daar Test Automation as a Service voor.

Veelgestelde vragen

Heb je ISTQB nodig als test automation engineer?

Nee. ISTQB laat zien dat iemand de gedeelde taal van het testvak kent, en dat helpt een team. Het laat niet zien dat iemand een goede testset kan ontwerpen. Gebruik het als basis en toets de echte vaardigheden in het gesprek.

Wat is het verschil tussen een QA engineer en een test automation engineer?

De functienamen overlappen en bedrijven gebruiken ze verschillend. Een QA engineer doet vaak testen in de breedte, van teststrategie tot handmatige controles. Een test automation engineer richt zich op het bouwen en onderhouden van geautomatiseerde tests. In beide rollen telt testvaardigheid zwaarder dan de tool.

Kan een handmatige tester doorgroeien naar testautomatisering?

Ja, en vaak met goed resultaat. Een ervaren tester denkt al in risico’s en kent het bedrijfsproces. Onderhoudbare testcode leren schrijven kost moeite, maar het is de makkelijkste helft om te leren.

Hoe lang duurt het om een test automation engineer aan te nemen?

Dat hangt af van de markt en je eisen, maar reken op maanden, niet op weken. Tel daar een paar maanden inwerken bij op voordat iemand je systemen goed genoeg kent om de juiste tests te kiezen.