Die Browser-Automatisierung hat drei Generationen durchlaufen. Jede löste den Engpass der vorherigen und verlagerte ihn zugleich an eine neue Stelle. Wichtiger als Werkzeugnamen ist daher, die offenen Probleme jeder Generation zu verstehen.
Browser-Automatisierung gibt es seit mehr als zwanzig Jahren, und ihr technischer Weg hat sich dreimal grundlegend verändert. Interessant ist, dass jede Generation eine andere Problemklasse löst und der Engpass danach jeweils an eine neue Stelle wandert.
Erste Generation: Auf Betriebssystemebene so tun, als würde jemand die Maus bewegen
Die früheste Automatisierung fand gar nicht im Browser statt, sondern auf Betriebssystemebene. Ein Skript bewegte die Maus und drückte Tasten; der Browser war lediglich der passive Empfänger dieser Eingaben.
Der Vorteil war die Allgemeingültigkeit: Alles, was auf dem Bildschirm erschien, konnte angesprochen werden – Webseiten, Client-Anwendungen und alte Desktop-Software gleichermaßen – und der Browser musste keinerlei Schnittstelle bereitstellen. Der Preis war ebenso direkt. Das Skript orientierte sich an Bildschirmkoordinaten; änderte sich die Auflösung, die Systemskalierung oder die Fensterposition, traf dieselbe Aktion plötzlich die falsche Stelle. Ob eine Seite wirklich fertig geladen war, wusste das Skript ebenfalls nicht und musste sich mit festen Wartezeiten behelfen. Noch schwieriger war Parallelität: Eine Maschine hat nur eine Maus und eine Tastatur, also brauchten zehn Umgebungen zehn Maschinen.
Das ungelöste Problem dieser Generation war im Kern: Sie konnte die Seite nicht sehen.
Zweite Generation: Den Bildschirm umgehen und direkt mit dem Browser sprechen
WebDriver hob die Automatisierung von der Pixel- auf die Elementebene: Gesucht wurde ein bestimmtes Element auf der Seite statt Position 800 auf dem Bildschirm. Derselbe Code konnte verschiedene Browser steuern und in unterschiedlichen Sprachen geschrieben werden. Das ist auch ein Grund, warum WebDriver später zum Standard im Testbereich wurde.
Später führten Ansätze auf Basis von Browser-Debugging-Protokollen diesen Weg konsequent weiter. Puppeteer und Playwright kommunizieren direkt mit der Browser-Engine und können internen Seitenzustand nutzen: automatisch auf bereite Elemente warten, Anfragen abfangen und verändern, sich mit einer bereits laufenden Browserinstanz verbinden, headless laufen und mehrere Kontexte parallel öffnen. Viele Fähigkeiten, die heute selbstverständlich wirken, wurden in dieser Phase vervollständigt.
Damit wurden Kontrolle und Stabilität verbessert, doch zwei andere Probleme blieben. Erstens waren die Skripte weiterhin von Menschen festgeschrieben. Änderten sich Seitenstruktur oder Selektoren, musste der Code angepasst werden, und die Wartungskosten stiegen mit der Projektgröße. Zweitens gab es ein grundlegenderes Problem: Geregelt wurde, wie etwas bedient wird, nicht aber, wie der Akteur nach außen wirkt. Direkte Protokollkommunikation macht die Steuerung präziser, lässt die Spuren der Automatisierung aber nicht allein durch einen anderen Kommunikationsweg verschwinden. Selbst ein sehr stabiles Skript kann für andere weiterhin wie ein Skript aussehen.
Dritte Generation: Schritte werden nicht mehr einzeln geschrieben – der Engpass wandert erneut
Bei der dritten Generation ändert sich nicht die Art der Steuerung, sondern die Art der Entscheidung. In den ersten beiden Generationen musste jeder Schritt explizit beschrieben werden: welcher Button geklickt, welches Feld ausgefüllt und welche Reihenfolge eingehalten wird. In der modellgesteuerten Generation gibt man ein Ziel vor, das Modell plant den Weg selbst und kann nach einem Redesign einen neuen Einstieg finden.
Damit verlieren frühere Detailprobleme wie Selektoren oder Wartezeiten allmählich an Gewicht. Dafür treten sofort neue Schwierigkeiten auf.
Entscheidend ist: Das Modell selbst greift nicht auf die Webseite zu. Die Seite wird weiterhin vom Browser geöffnet, Ressourcen werden von ihm geladen und der Anmeldestatus wird dort gehalten. Wenn Aufgaben instabil werden, liegt die Ursache deshalb oft nicht in einer falschen Modellentscheidung, sondern in der Ausführungsumgebung darunter: Mehrere Aufgaben teilen sich einen Browser und verunreinigen gegenseitig Cookies und Cache; Fingerprint-Merkmale ähneln sich stark, sodass die Plattform die Aufgaben derselben Maschine zuordnet; Konten werden zwischen Aufgaben vermischt und eine einzelne Auffälligkeit zieht weitere nach sich; Umgebungen müssen kurzfristig erstellt und danach wieder freigegeben werden, ohne dass es eine einheitliche Planung gibt. Das Modell löst das Wie und macht das Wo zum neuen Engpass.
Die zusätzliche Architekturschicht
Betrachtet man alle drei Generationen zusammen, geht es nicht darum, welche „fortschrittlicher“ ist. Jede muss das auffangen, was die vorige offenließ. In den ersten beiden Generationen war die Umgebung kaum ein Problem, weil der Browser auf der eigenen Maschine bedient wurde. In der Agent-Phase laufen Aufgaben jedoch in großen Mengen, parallel und unbeaufsichtigt. Deshalb muss die Umgebung ausdrücklich verwaltet werden: Jede Aufgabe läuft in einer isolierten Umgebung, Fingerprints und Sitzungen werden nicht vermischt; Anmeldestatus bleibt über Aufgaben hinweg erhalten, sodass nicht jedes Mal neu eingeloggt werden muss; IP, Zeitzone und Sprache werden als Paket aufeinander abgestimmt; Umgebungen werden wie Rechenressourcen bedarfsgerecht erstellt und wieder freigegeben.
PurpleMark arbeitet genau auf dieser Ebene: Browser-Umgebungen werden zu planbaren Ressourcen, damit sich der Agent auf die Aufgabenlogik konzentrieren kann.
Damit lässt sich auch die Wahl klarer einordnen. Unternehmens-Teststacks und vorhandene Skriptbestände können auf ihrem bisherigen Weg bleiben; komplexe Webanwendungen mit Bedarf an Kontrolle auf Anfrageebene passen zur protokollgesteuerten Generation; bei Aufgaben, die vom Modell geplant werden und langfristig stabil laufen sollen, können die Technologien der ersten beiden Generationen weiterverwendet werden, doch die Umgebungsschicht muss separat gelöst werden. Wenn ein Szenario so wirken muss, als bediene ein echter Nutzer den Browser, kann ein Automatisierungsframework allein das unabhängig von der Generation nicht liefern.
Neben der technischen Route gibt es eine weitere Grenze: Automatisierung muss die Regeln der Zielplattform und die örtlichen Gesetze einhalten. Technische Machbarkeit bedeutet nicht automatisch geschäftliche Angemessenheit.
