Browserautomatisering heeft drie generaties doorlopen. Elke generatie loste het knelpunt van de vorige op, maar verplaatste het volgende probleem. Begrijpen wat elke generatie onopgelost laat, is nuttiger dan gereedschapsnamen onthouden.
Browserautomatisering bestaat al meer dan twintig jaar en heeft in die tijd drie grote routes gevolgd. Het interessante is dat elke generatie een ander soort probleem oplost en dat het knelpunt daarna weer naar een andere plek verschuift.
Eerste generatie: op besturingssysteemniveau doen alsof iemand de muis beweegt
De eerste automatisering vond eigenlijk helemaal niet in de browser plaats, maar op het niveau van het besturingssysteem. Een script verplaatste de muis en drukte toetsen in; de browser ontving die invoer alleen maar passief.
Het voordeel was de brede toepasbaarheid: alles wat op het scherm stond kon worden aangeraakt, of het nu een webpagina, clientapplicatie of oude desktopsoftware was, zonder dat de browser een interface hoefde aan te bieden. De nadelen waren net zo direct. Het script werkte met schermcoördinaten, dus een andere resolutie, aangepaste systeemschaal of verplaatst venster kon dezelfde actie op de verkeerde plek laten klikken. Het wist ook niet of de pagina werkelijk geladen was en moest daarom vertrouwen op vaste wachttijden. Parallel werken was nog lastiger: één machine heeft maar één muis en toetsenbord, dus tien omgevingen betekenden tien machines.
Het probleem dat deze generatie achterliet was eenvoudig: ze kon de pagina niet zien.
Tweede generatie: het scherm omzeilen en rechtstreeks met de browser praten
Met WebDriver ging automatisering van pixelniveau naar elementniveau: er werd naar een specifiek element op de pagina gezocht in plaats van naar de positie van pixel 800 op het scherm. Dezelfde code kon verschillende browsers aansturen en in verschillende talen worden geschreven. Dat is ook waarom WebDriver later een standaard in softwaretesten werd.
Later brachten oplossingen op basis van browserdebugprotocollen deze route veel verder. Puppeteer en Playwright communiceren rechtstreeks met de browser-engine en kunnen interne paginastatus ophalen: automatisch wachten tot elementen klaar zijn, verzoeken onderscheppen en herschrijven, verbinding maken met een al geopende browserinstantie, headless draaien en meerdere contexten parallel openen. Veel functies die nu vanzelfsprekend zijn, werden in deze fase volwassen.
Hiermee werden controle en stabiliteit verbeterd, maar twee andere problemen bleven bestaan. Ten eerste werden scripts nog steeds door mensen vastgelegd. Als de paginastructuur veranderde of een selector niet meer werkte, moest de code worden aangepast en namen de onderhoudskosten toe naarmate het project groter werd. Ten tweede was er een fundamenteler punt: de techniek regelt hoe er wordt gewerkt, niet hoe de gebruiker eruitziet. Directe protocolbesturing maakt de controle nauwkeuriger, maar automatiseringssporen verdwijnen niet alleen doordat de communicatiemethode verandert. Zelfs een zeer stabiel script kan voor anderen nog altijd als een script overkomen.
Derde generatie: mensen schrijven niet meer elke stap en het probleem verschuift opnieuw
Bij de derde generatie verandert niet de besturingsmethode, maar de manier waarop beslissingen worden genomen. In de eerste twee generaties moesten mensen elke stap uitschrijven: welke knop moet worden aangeklikt, welk veld moet worden ingevuld en in welke volgorde. In de modelgestuurde generatie geef je een doel op, plant het model zelf het pad en kan het na een herontwerp een nieuwe ingang vinden.
Daardoor worden oude details, zoals het schrijven van selectors en het instellen van wachttijden, geleidelijk minder bepalend. Maar nieuwe problemen verschijnen meteen.
Het belangrijkste is dat het model zelf de webpagina niet bezoekt. De browser blijft de pagina openen, bronnen laden en de aanmeldstatus bewaren. Als een taak instabiel wordt, ligt de oorzaak daarom vaak niet bij een verkeerde modelbeslissing, maar bij de uitvoeringsomgeving eronder: meerdere taken delen één browser en vervuilen elkaars cookies en cache; fingerprintkenmerken lijken sterk op elkaar, waardoor het platform die taken als afkomstig van dezelfde machine ziet; accounts worden tussen taken gedeeld, zodat één afwijking een hele groep kan raken; omgevingen moeten tijdelijk worden aangemaakt en na gebruik worden vrijgegeven, maar er is geen uniforme planning. Het model lost op hoe de taak moet worden uitgevoerd en maakt waar dat gebeurt tot het nieuwe knelpunt.
De extra laag in de architectuur
Als je de drie generaties naast elkaar zet, gaat het verschil niet simpelweg over welke moderner is. Elke generatie moet opvangen wat de vorige niet oploste. In de eerste twee was de omgeving nauwelijks een probleem, omdat je de browser op je eigen machine gebruikte. In de Agent-fase zijn taken grootschalig, parallel en onbeheerd, waardoor de omgeving expliciet moet worden beheerd: elke taak draait in een eigen geïsoleerde omgeving; fingerprints en sessies raken niet vermengd; aanmeldstatus blijft tussen taken behouden zodat opnieuw inloggen niet steeds nodig is; IP, tijdzone en taal worden als set op elkaar afgestemd; en omgevingen worden op aanvraag aangemaakt en teruggewonnen zoals rekenresources.
PurpleMark werkt precies in deze laag: browseromgevingen worden planbare resources, zodat de Agent zich op de taaklogica kan richten.
Daardoor is de keuze ook beter te plaatsen. Bedrijfsteststacks en bestaande scripts kunnen op hun huidige route blijven; complexe webapplicaties die controle op verzoekniveau nodig hebben passen bij de protocolgestuurde generatie; voor taken die door een model worden gepland en langdurig stabiel moeten draaien, blijven de technieken uit de eerste twee generaties bruikbaar, maar de omgevingslaag moet apart worden opgelost. Als je scenario eruit moet zien alsof een echte gebruiker de handelingen uitvoert, kan een automatiseringsframework dat op zichzelf niet leveren, ongeacht de generatie.
Naast de technische route is er nog een grens: geautomatiseerde handelingen moeten voldoen aan de regels van het doelplatform en de lokale wetgeving. Dat iets technisch werkt, betekent niet automatisch dat het zakelijk passend is.
