22 september 2026 · 3 minuten lezen
Niet welke tool beter is, maar welke past bij je software en bij wie de tests over een jaar onderhoudt.
De vraag wordt bijna altijd verkeerd gesteld. Welke tool is beter, Robot Framework of Playwright? Daar is geen antwoord op, net zomin als op de vraag of een bestelbus beter is dan een personenauto. De bruikbare vraag is: wat ga je testen, en wie onderhoudt het over een jaar nog?
Wij werken met beide, in opdrachten die uiteenlopen van landelijke ketens tot webshops. Hieronder de afweging zoals wij hem in de praktijk maken, zonder voorkeur vooraf.
Wie schrijft en onderhoudt de tests?
Dit is verreweg de belangrijkste vraag, en hij gaat niet over techniek. Een suite die niemand kan lezen wordt niet onderhouden, en een suite die niet onderhouden wordt staat binnen een half jaar op rood terwijl iedereen wegkijkt.
Zitten de mensen die de tests gaan schrijven in de operatie of in het testteam, zonder programmeerachtergrond, dan is Robot Framework de veiliger keuze. De keyword-stijl leest als een opsomming van stappen. Een functioneel beheerder kan meelezen en zien of er getest wordt wat hij bedoelde, ook zonder dat hij zelf ooit een test schrijft.
Schrijven je ontwikkelaars de tests, in dezelfde taal als de applicatie, dan is Playwright logischer. Tests staan dan naast de code, gaan mee in dezelfde review en worden bijgewerkt door dezelfde persoon die het scherm veranderde. Dat scheelt precies de vertraging waar testautomatisering vaak op stukloopt.
Wat test je precies?
Gaat het om een moderne webapplicatie met veel interactie, dan is Playwright in het voordeel. Het wacht uit zichzelf tot een element klaar is, vangt netwerkverkeer af, werkt met meerdere tabbladen en gebruikers tegelijk, en levert bij een fout een opname van wat er gebeurde. Dat scheelt uren zoekwerk bij tests die af en toe omvallen.
Loopt je proces door meerdere systemen heen, met berichten, koppelingen en databases, dan komt Robot Framework in beeld. De bibliotheken voor databases, berichtenverkeer en bestandsformaten zijn er, en je kunt een keten testen zonder dat je per systeem een andere aanpak nodig hebt.
Waar het bijna nooit om zou moeten gaan
- Snelheid van de tool zelf. Je doorlooptijd wordt bepaald door hoe je de suite indeelt en parallel draait, niet door de tool.
- Het aantal beschikbare bibliotheken. Je gebruikt er uiteindelijk een handvol.
- Welke tool populairder is. Populair zegt iets over de arbeidsmarkt, niet over jouw software.
- Dat het team er al een kent. Dat telt wel mee, maar het is geen reden om een keten te testen met een tool die daar niet voor gemaakt is.
De praktijk: allebei
In grotere landschappen zie je ze vaak naast elkaar, en dat is prima zolang het een keuze is en geen ongeluk. Playwright voor de webapplicaties waar ontwikkelaars aan werken, Robot Framework voor de ketentesten die de functioneel beheerders moeten kunnen lezen.
Wat wel misgaat, is twee tools voor hetzelfde doel, omdat twee teams los van elkaar begonnen. Dan betaal je het onderhoud dubbel en heb je twee keer een suite die half af is.
Wat wij zouden doen
Begin bij de vraag wie de tests over een jaar bijwerkt, en kies de tool die die persoon kan lezen. Kies daarna één tool per doel, niet per team. En spreek af wat je doet met een test die blijft wankelen, want dat is het moment waarop een suite zijn geloofwaardigheid verliest, ongeacht welke tool eronder zit.
De beste tool is die waarvan je over een jaar nog steeds gelooft wat hij zegt.