02 nov 2026 Testautomatisering tools kiezen: zo kies je er een die over twee jaar nog past

In het kort: Kies testautomatisering tools vanuit je applicatie, je team en de mensen die de tests straks onderhouden. Vergelijk tools daarna op aansluiting, kennis, onderhoud, pipeline, kosten en afhankelijkheid. Bouw één echt bedrijfsproces in de tool voordat je tekent. De tool zelf telt minder dan hoe goed de tests blijven draaien.

Een tool kiezen voelt als de eerste stap in testautomatisering. In de praktijk zetten teams die stap vaak te vroeg. Een jaar later werkt de tool prima, maar de testset niet. Tests breken na elke wijziging, en maar één persoon weet hoe je ze repareert. De keuze tussen testautomatisering tools is een echte beslissing, met een licentie en jaren onderhoud eraan vast. Zo maak je een keuze die over twee jaar nog klopt.

Wat beslis je voordat je tools gaat vergelijken?

Beslis eerst drie dingen: wat je wilt testen, op welke laag, en wie de tests onderhoudt. Met die antwoorden wordt een lijst van vijftig tools er drie of vier. Een webshop, een mobiele app en een Salesforce-omgeving vragen elk om iets anders. Bedrijfsregels test je sneller via de API, de laag waarop systemen gegevens uitwisselen, dan via het scherm. En een tool die past bij developers die elke dag programmeren, past niet altijd bij testers die dat niet doen. Sla je deze vragen over, dan heb je straks een tool die voor iemand anders de juiste keuze was.

Bij klanten zien we vaak wat er gebeurt zonder die eerste stap. API-tests en UI-tests draaien naast elkaar, zonder plan. Postman, SoapUI, Robot Framework, Selenium, Playwright of Tosca zijn gekozen door wie toevallig begon. Geen van die tools is slecht. Maar niemand koos ze als één geheel, dus niemand kan zeggen wat de testset als geheel beschermt.

Bij het werven van testers zien we hetzelfde. Vacatures vragen om ervaring met Playwright of Tosca. Toch tellen risicoanalyse, testontwerp en kennis van het bedrijfsproces minstens zo zwaar. Een toolexpert die de verkeerde dingen test, laat je nog steeds kwetsbaar.

Welke criteria tellen het zwaarst bij je keuze?

Zes criteria bepalen of een tool na het eerste jaar nog voor je werkt. Op een lijst met functies zie je ze zelden terug. Elk criterium komt neer op een vraag die je een leverancier kunt stellen, of zelf in een week kunt uitzoeken. Weeg ze voor je eigen situatie. Een team van developers vindt low-code minder belangrijk. Een team met één tester let juist op hoe makkelijk je een kapotte test repareert.

Veel tools krijgen er nu AI-functies bij. Ze maken een eerste opzet van tests uit een user story, of passen een test aan als een knop verschuift. Dat scheelt tijd, en in ons stuk over AI in testautomatisering lees je waar precies. Maar een mens beslist nog steeds of een test het juiste controleert. Exploratief testen vanuit een echte gebruiker blijft mensenwerk, net als acceptatietesten door je gebruikers uit de business. Zie AI als een functie van een tool, nooit als de reden om hem te kiezen.

Open source of een commerciële tool?

Geen van beide is vanzelf goedkoper. Open source tools als Playwright, Selenium en Robot Framework kosten geen licentie. Maar je hebt mensen nodig die kunnen programmeren, en iemand moet er een framework omheen bouwen en bijhouden. Commerciële tools hebben support, kant-en-klare bouwstenen en vaak een low-code editor. Daar staat een licentie tegenover, vaak per gebruiker en elk jaar opnieuw. In beide gevallen is de grootste kostenpost dezelfde: de tests laten werken terwijl je software verandert.

Vergelijk daarom de totale kosten over drie jaar, niet de prijs op de website. Tel de uren voor de eerste tests en voor het repareren na elke release. Tel daar de kosten bij op van de mensen die dat kunnen. Twijfel je tussen de twee grote open source namen? Onze vergelijking Playwright of Selenium gaat daar dieper op in.

Standaardpakketten zijn een apart geval. Salesforce bouwt zijn schermen bijvoorbeeld op een manier die algemene UI-tools lastig kunnen volgen. Een tool die voor dat platform is gemaakt, kan veel reparatiewerk schelen. In onze Lease Company-case onderzocht onze tester eerst de mogelijkheden voor testautomatisering in Salesforce Service Cloud. Daarna voerde hij Provar in. Het bedrijf gebruikte Provar later ook bij andere Salesforce-projecten. Zo ziet een goede keuze eruit: hij blijft passen na het eerste project. Wij zijn Provar-partner, dus weeg die opmerking daarmee mee.

Hoe test je een tool voordat je tekent?

Doe een korte proef op één echt bedrijfsproces, niet op de demo-app van de leverancier. Een demo is gemaakt om soepel te lijken. Jouw applicatie heeft de trage pagina’s, lastige logins en koppelingen die bepalen of een tool werkt. Laat de mensen die de tests straks onderhouden het werk doen, zodat je ziet wat het van hen vraagt. Twee tot vier weken is meestal genoeg. Met deze stappen blijft de proef eerlijk.

1. Kies één kritiek proces. Bijvoorbeeld een bestelling plaatsen, met een login en één koppeling.
2. Bouw het in de tool. Gebruik je eigen testomgeving en je eigen testdata.
3. Verander iets. Verplaats een veld of hernoem een knop, en meet hoe lang de reparatie duurt.
4. Draai het in je pipeline. Kijk of het rapport duidelijk is voor iemand die de test niet schreef.
5. Schrijf de kosten op. De uren, de licentie en de hulp die je nodig had.

Doe dit als het kan voor twee tools naast elkaar. De verschillen worden snel zichtbaar, en het zijn zelden de verschillen uit de functielijst.

Wat betekent dit voor je team?

De tool is de kleinere beslissing. De grotere is wie de tests na de keuze laat draaien. Elke release verandert schermen, regels en data, en elke wijziging kan een test breken. Dat reparatiewerk concurreert met nieuwe functies, en het verliest meestal. Dan vertrouwt het team de testset steeds minder, op welke tool hij ook draait.

Wij zijn onafhankelijk: geen aandeelhouders, geen moederbedrijf en geen quota van leveranciers. Daardoor kunnen we de tool adviseren die bij je applicatie en team past, of zeggen dat je huidige tool prima is. Met Test Automation as a Service bekijken we eerst samen met je team hoe er nu getest wordt. Binnen de eerste maand staat er een werkende proef. Daarna bouwen, documenteren en onderhouden we de testset, zodat hij van jou blijft en niet van één persoon afhangt. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je team houdt de regie over wat er live gaat.

Een eerste stap voor deze week: schrijf op wat je test, op welke laag, en wie dat nu onderhoudt. Is het antwoord op die laatste vraag één persoon, begin dan daar.

Veelgestelde vragen

Wat is de beste tool voor testautomatisering?

Er is geen beste tool voor iedereen. De beste past bij je applicatie, de kennis in je team en je pipeline, en is makkelijk te onderhouden. Een korte proef op één echt proces zegt meer dan elke ranglijst.

Zijn gratis testautomatisering tools goed genoeg?

Voor veel teams wel. Playwright, Selenium en Robot Framework worden breed gebruikt. Maar gratis betekent geen licentie, niet geen kosten. Je hebt mensen nodig die er een framework omheen bouwen en onderhouden.

Vervangt AI straks testautomatisering?

Nee. AI helpt bij een eerste opzet van tests en bij kleine reparaties, en dat scheelt tijd. Iemand moet nog steeds bepalen wat je test, de tests draaien, ze betrouwbaar houden en de uitslag beoordelen. Exploratief testen en acceptatietesten blijven mensenwerk.

Hoe lang duurt het om van tool te wisselen?

Dat hangt af van de grootte van je testset. Veel teams verhuizen niet alles tegelijk. Ze bouwen nieuwe tests in de nieuwe tool, zetten eerst de kritieke processen over en ruimen oude tests op zodra ze breken.