Automatyzacja przeglądarek przeszła przez trzy generacje. Każda usuwała główne ograniczenie poprzedniej, jednocześnie przenosząc wąskie gardło w inne miejsce. Ważniejsze od nazw narzędzi jest zrozumienie, jakie problemy pozostawia każda generacja.
Automatyzacja przeglądarek rozwija się od ponad dwudziestu lat i w tym czasie przeszła przez trzy główne podejścia. Ciekawe jest to, że każda generacja rozwiązuje inny rodzaj problemów, a po ich rozwiązaniu wąskie gardło po prostu przenosi się gdzie indziej.
Pierwsza generacja: udawanie na poziomie systemu operacyjnego, że ktoś porusza myszą
Najwcześniejsza automatyzacja wcale nie działała wewnątrz przeglądarki. Odbywała się na poziomie systemu operacyjnego. Skrypt poruszał myszą i naciskał klawisze, a przeglądarka tylko biernie odbierała te działania.
Zaletą była uniwersalność: skrypt mógł obsługiwać wszystko, co było widoczne na ekranie — stronę internetową, aplikację kliencką czy stare oprogramowanie desktopowe — bez potrzeby udostępniania jakiegokolwiek interfejsu przez przeglądarkę. Koszt był równie oczywisty. Skrypt rozpoznawał współrzędne ekranu, więc zmiana rozdzielczości, skalowania systemu albo położenia okna mogła sprawić, że ta sama akcja kliknęła w złe miejsce. Nie wiedział też, czy strona rzeczywiście się załadowała, dlatego musiał opierać się na stałych opóźnieniach. Jeszcze trudniejsza była praca równoległa: jedna maszyna ma tylko jedną mysz i klawiaturę, więc dziesięć środowisk oznaczało dziesięć maszyn.
Problem pozostawiony przez tę generację był prosty: nie widziała strony.
Druga generacja: pominięcie ekranu i bezpośrednia rozmowa z przeglądarką
Pojawienie się WebDrivera przeniosło automatyzację z poziomu pikseli na poziom elementów: wyszukiwano konkretny element strony zamiast pozycji odpowiadającej osiemsetnemu pikselowi na ekranie. Ten sam kod mógł sterować różnymi przeglądarkami i być pisany w różnych językach, co jest jednym z powodów, dla których podejście to stało się standardem w testowaniu.
Później rozwiązania oparte na protokołach debugowania przeglądarek doprowadziły ten kierunek znacznie dalej. Puppeteer i Playwright komunikują się bezpośrednio z silnikiem i mogą uzyskać wewnętrzny stan strony: automatycznie czekać na gotowość elementów, przechwytywać i modyfikować żądania, łączyć się z już uruchomioną instancją przeglądarki, działać bez interfejsu graficznego i otwierać wiele kontekstów równolegle. Większość funkcji, które dziś traktujemy jako oczywiste, dojrzała właśnie na tym etapie.
Rozwiązało to kwestie kontroli i stabilności, ale pozostawiło dwa inne problemy. Po pierwsze, skrypty nadal były na sztywno pisane przez ludzi. Gdy zmieniała się struktura strony lub przestawał działać selektor, trzeba było wrócić do kodu, a koszt utrzymania rósł wraz ze skalą projektu. Po drugie, pozostał problem bardziej fundamentalny: rozwiązanie kontroluje sposób działania, ale nie to, na kogo wygląda wykonawca. Bezpośrednia komunikacja protokołowa zwiększa precyzję, ale ślady automatyzacji nie znikają tylko dlatego, że zmieniono sposób komunikacji. Nawet bardzo stabilny skrypt może nadal wyglądać jak skrypt.
Trzecia generacja: człowiek nie zapisuje już każdego kroku, a problem znowu zmienia miejsce
W trzeciej generacji zmienia się nie sposób sterowania, lecz sposób podejmowania decyzji. W pierwszych dwóch człowiek musiał dokładnie opisać każdy krok: który przycisk kliknąć, które pole wypełnić i w jakiej kolejności. W generacji opartej na modelach podaje się cel, model sam planuje ścieżkę i po zmianie układu strony potrafi znaleźć nowe wejście.
Dzięki temu dawne drobiazgowe problemy, takie jak dobór selektorów czy długość oczekiwania, stopniowo tracą znaczenie. Od razu pojawiają się jednak nowe trudności.
Kluczowe jest to, że sam model nie odwiedza strony internetowej. To nadal przeglądarka otwiera stronę, ładuje zasoby i utrzymuje stan logowania. Gdy zadanie zaczyna działać niestabilnie, przyczyną często nie jest błędna decyzja modelu, lecz środowisko wykonawcze pod nim: wiele zadań współdzieli jedną przeglądarkę i wzajemnie zanieczyszcza pliki cookie oraz pamięć podręczną; cechy fingerprintu są bardzo podobne, więc platforma widzi te zadania jako pochodzące z tej samej maszyny; konta są używane pomiędzy zadaniami i jeden problem może objąć wiele z nich; środowiska trzeba tworzyć tymczasowo i zwalniać po użyciu, ale brakuje wspólnego harmonogramowania. Model rozwiązuje problem jak coś zrobić, a pytanie gdzie to zrobić staje się nowym wąskim gardłem.
Dodatkowa warstwa w architekturze
Kiedy spojrzeć na wszystkie trzy generacje razem, różnica nie polega na tym, która jest bardziej zaawansowana. Każda musi przejąć problemy, których poprzednia nie rozwiązała. W pierwszych dwóch środowisko nie stanowiło większego problemu, ponieważ automatyzacja działała w przeglądarce na własnej maszynie. Na etapie Agentów zadania są masowe, równoległe i wykonywane bez nadzoru, więc środowisko trzeba zarządzać jawnie: każde zadanie działa w odizolowanym środowisku, fingerprinty i sesje nie mieszają się; stan logowania jest zachowywany pomiędzy zadaniami, więc nie trzeba logować się za każdym razem; IP, strefa czasowa i język są dobierane jako spójny zestaw; środowiska są tworzone i zwalniane na żądanie jak zasoby obliczeniowe.
PurpleMark działa właśnie na tej warstwie, zamieniając środowiska przeglądarkowe w zasoby, które można planować, tak aby Agent mógł skupić się na logice zadania.
Dzięki temu łatwiej też określić wybór podejścia. Firmowe stosy testowe i istniejące zasoby skryptów mogą pozostać przy obecnej ścieżce; złożone aplikacje webowe wymagające kontroli na poziomie żądań pasują do generacji sterowanej protokołem; a przy zadaniach planowanych przez model, które mają stabilnie działać długoterminowo, nadal można korzystać z technologii pierwszych dwóch generacji, ale warstwę środowiska trzeba rozwiązać osobno. Jeśli scenariusz wymaga, aby działanie wyglądało jak wykonane przez prawdziwego użytkownika, sam framework automatyzacji nie zapewni tego niezależnie od generacji.
Poza ścieżką techniczną istnieje jeszcze jedna granica: automatyzacja musi przestrzegać zasad platformy docelowej i lokalnego prawa. To, że coś działa technicznie, nie oznacza automatycznie, że jest odpowiednie biznesowo.
