Stagehand: Przełom w Automatyzacji Testów End-to-End
Kilka Słów Wstępu
Jakiś czas temu miałam okazję przetestować możliwości Stagehand.
To, co mnie uderzyło, to fakt, że nie jest to kolejny nudny framework, ale prawdziwa ciekawostka, która może fundamentalnie zmienić sposób, w jaki fani Playwright podchodzą do testów.
Stagehand to innowacyjny framework do automatyzacji testów end-to-end (E2E), który łączy deterministyczną warstwę kodu z adaptacyjną warstwą sztucznej inteligencji.
Został on stworzony przez Browserbase na bazie Playwright. Dzięki temu zapewnia solidne fundamenty do precyzyjnego sterowania przeglądarką. Stagehand odpowiada na kluczowe wyzwania tradycyjnej automatyzacji, takie jak wysokie koszty utrzymania i kruchość testów. Problemy te często są spowodowane dynamicznymi zmianami w interfejsie użytkownika (UI).
TIP:
🔗Żródło: https://www.stagehand.dev/
Ewolucja Automatyzacji E2E: Od Selektorów do Inteligencji Kontekstowej
Tradycyjne narzędzia do automatyzacji, takie jak Selenium czy Playwright, do lokalizowania elementów na stronie używają statycznych selektorów, np. CSS czy XPath. W dynamicznych środowiskach, takich jak aplikacje SPA, elementy UI często zmieniają swoje atrybuty, tekst lub położenie.
To sprawia, że testy stają się kruche.
Wymagają też ciągłego, ręcznego aktualizowania, co spowalnia cykl deweloperski i generuje wysokie koszty.
Stagehand rozwiązuje ten problem, wprowadzając warstwę AI, która rozumie kontekst i intencję działania, a nie tylko sztywne selektory.
Architektura Hybrydowa
Sercem Stagehand jest jego hybrydowa architektura.
Framework ten nie zastępuje Playwright, lecz rozszerza go o AI.
To połączenie pozwala inżynierom na precyzyjne, oparte na kodzie podejście do krytycznych, statycznych elementów, np. formularza logowania. Jednocześnie mogą przełączać się na elastyczne, sterowalne operacje AI w scenariuszach, gdzie kluczowa jest odporność na zmiany.
W przeciwieństwie do narzędzi opartych wyłącznie na AI, które mogą być nieprzewidywalne, hybrydowy model Stagehand zapewnia powtarzalność i niezawodność, co jest kluczowe w testach produkcyjnych.
Architektura oparta na Zewnętrznych Modelach AI
Kluczowe innowacje Stagehand, takie jak Agent Mode i funkcja samonaprawiania, są możliwe dzięki integracji z zaawansowanymi modelami AI. Stagehand wykorzystuje najnowocześniejsze modele od dostawców takich jak OpenAI i Anthropic.
Ta zależność oznacza, że choć Stagehand jest otwartoźródłowy, do pełnego wykorzystania jego możliwości niezbędny jest dostęp do API tych komercyjnych usług.
Ten aspekt jest istotny dla inżynierów i decydentów, ponieważ wiąże się z potencjalnymi kosztami licencji oraz koniecznością zarządzania kluczami API. Warto również zwrócić uwagę, że Stagehand, będąc fundamentem, prowadzi do komercyjnej platformy Browserbase. Oferuje ona pełną integrację, skalowalność i zaawansowane funkcje monitorowania
Kluczowe Innowacje i Wyróżniki
Stagehand wyróżnia się na tle konkurencji dzięki kilku kluczowym, rewolucyjnym funkcjonalnościom.
Są one bezpośrednią konsekwencją jego hybrydowej architektury.
Automatyzacja Językiem Naturalnym
Jedną z przełomowych cech jest tryb “Agent Mode“.
Umożliwia on koordynację skomplikowanych zadań za pomocą jednej instrukcji w języku naturalnym. Zamiast pisać dziesiątki linii kodu, które precyzyjnie definiują każdą interakcję, użytkownik może opisać cel, który ma zostać osiągnięty. To podejście zmienia paradygmat tworzenia testów. Ułatwia ich pisanie nawet osobom z ograniczoną wiedzą programistyczną.
Przykład:
- Playwright: Wymaga precyzyjnego kodowania każdego kroku, np.
page.goto(), page.click(), page.fill().
- Stagehand: Jedna instrukcja uruchamia cały przepływ:
stagehand.agent({ instructions:
"Jesteś testerem automatycznym. Przejdź na stronę DemoQA, znajdź sekcję 'Text Box', wypełnij formularz przykładowymi danymi i wyświetl wynik."
})
Samonaprawiające się Testy (Self-Healing)
Funkcja Self-Healing pozwala testom na adaptację do drobnych zmian w UI.
To bezpośrednio rozwiązuje problem ich kruchości. Zamiast opierać się na twardo zakodowanych selektorach, warstwa AI Stagehand rozumie kontekst działania. Przykładowo, jeśli tekst przycisku zmieni się z „Submit” na „Wyślij”, Stagehand nadal potrafi go zidentyfikować i kliknąć. Dzieje się tak, ponieważ rozumie, że jego przeznaczeniem jest wysłanie formularza, a nie jest zdefiniowany wyłącznie przez jego tekst.
Ta funkcja znacząco redukuje czas i zasoby przeznaczane na utrzymanie testów.
Ekstrakcja Ustrukturyzowanych Danych przez AI
Stagehand rozszerza możliwości weryfikacji funkcjonalnej o zdolność do ekstrakcji ustrukturyzowanych danych za pomocą języka naturalnego. Funkcja
page.extract() jest kluczowym elementem tej możliwości.Zamiast pisać złożony kod do parsowania elementów, tester może wydać polecenie w rodzaju:
Wypisz wszystkie widoczne przyciski na stronie wraz z ich tekstem.Stagehand zwróci ustrukturyzowaną listę danych. Pozwala to na bardziej kompleksową weryfikację spójności danych, np. porównanie cen produktów na stronie z danymi w bazie danych.
Zastosowania Praktyczne i Przykłady Kodu
Stagehand łączy różne podejścia do automatyzacji, co czyni go niezwykle wszechstronnym. Poniżej przedstawiamy przykłady techniczne, ilustrujące jego możliwości.
TIP:
Klasyczna Automatyzacja (Playwright)
Stagehand jest w pełni kompatybilny z kodem Playwright. Pozwala to na precyzyjne, krok po kroku, automatyzowanie interakcji z UI. Możliwe jest również użycie wbudowanej funkcji
page.extract() do inteligentnego wyodrębnienia danych po interakcji.
await page.goto("https://demoqa.com/text-box");
await page.fill("#userName", "Jan Kowalski");
await page.fill("#userEmail", "jan.kowalski@example.com");
await page.fill("#currentAddress", "ul. Przykładowa 1");
await page.fill("#permanentAddress", "ul. Stała 2");
await page.click("#submit");
const result = await page.extract("Extract the output text after submitting the form");
console.log("Form result:", result);
Ekstrakcja Danych przez AI
Funkcja
page.extract() nie ogranicza się tylko do prostych scenariuszy.Potrafi wyodrębniać ustrukturyzowane dane na podstawie instrukcji w języku naturalnym. Poniższy przykład pokazuje, jak łatwo można wyciągnąć listę przycisków z ich tekstem.
await page.goto("https://demoqa.com/elements");
const buttonsAI = await page.extract("Wypisz wszystkie widoczne przyciski na stronie wraz z ich tekstem");
console.log("AI-extracted buttons:", buttonsAI);
Agent AI: Pełna Automatyzacja Złożonego Zadania
Najbardziej przełomową funkcjonalnością Stagehand jest tryb agenta.
Pozwala on na orkiestrację całego złożonego scenariusza za pomocą jednej instrukcji.
Poniższy kod przedstawia, jak Stagehand wykonuje zadanie wypełnienia formularza bez konieczności pisania kolejnych selektorów.
const agent stagehand.agent({
instructions: "Jesteś testerem automatycznym. Przejdź na stronę DemoQA, znajdź sekcję 'Text Box', wypełnij formularz przykładowymi danymi i wyświetl wynik."
});
const agentResult = await agent.execute("Wykonaj zadanie");
console.log("Agent result:", agentResult);
Dla porównania, ta sama operacja w czystym Playwright wymagałaby ręcznego kodowania każdego kroku, co jest znacznie bardziej czasochłonne i mniej odporne na zmiany.
await page.goto("https://demoqa.com/");
await page.click("div.card: has-text('Elements')");
await page.click("span:has-text('Text Box')");
await page.fill("#userName", "Jan Kowalski");
await page.fill("#userEmail", "jan.kowalski@example.com");
await page.fill("#currentAddress", "ul. Przykładowa 1");
await page.fill("#permanentAddress", "ul. Stała 2");
await page.click("#submit");
const result = await page.textContent("#output");
console.log("Form result:", result);
Test Samonaprawiający się (Self-Healing)
Self-healing to funkcja, która pozwala testom Stagehand adaptować się do drobnych zmian w UI. Poniższy kod, używający funkcji
page.act(), pokazuje jak Stagehand rozumie kontekst akcji (“Kliknij przycisk wysyłania formularza”), a nie tylko twardo zakodowany selektor. Dzięki temu, nawet jeśli tekst przycisku zmieni się z “Submit” na “Wyślij”, test nadal zadziała.
await page.act("Kliknij przycisk wysyłania formularza");
Dodatkowe Przykłady Automatyzacji
Stagehand umożliwia również automatyzację bardziej złożonych scenariuszy interakcji z UI. Oto kilka dodatkowych przykładów, które demonstrują wszechstronność frameworka.
// Web Table
await page.act("Get all values from the web table and display them.");
// Upload and Download
await page.act("Upload 'sample.txt' file from 'D:/' and download the 'sample-file.txt'.");
// Drag and Drop
await page.act("Drag the element with id 'draggable' and drop it into element with id 'droppable'.");
Integracja z CI/CD
Jak widać na przykładzie poniższego kodu, Stagehand jest w pełni przystosowany do integracji z nowoczesnymi systemami CI/CD, takimi jak GitHub Actions.
Konfiguracja jest prosta i pozwala na automatyczne uruchamianie testów przy każdym zdarzeniu w repozytorium.
name: Stagehand Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '22'
- name: Install dependencies
run: npm install
- name: Run Stagehand tests
run: npm start
- name: Upload test report
uses: actions/upload-artifact@v3
with:
name: stagehand-report
path: stagehand-report.html
Strategiczne i Operacyjne Korzyści
Wdrożenie Stagehand przynosi wymierne korzyści zarówno na poziomie operacyjnym, jak i strategicznym.
Korzyści Operacyjne
- ✅ Szybkość pisania testów
Wykorzystanie języka naturalnego znacząco redukuje ilość kodu, co przyspiesza tworzenie testów i zwiększa pokrycie testowe.
- ✅ Zredukowany narzut na utrzymanie
Funkcja samonaprawiania eliminuje konieczność ręcznej naprawy testów spowodowanej drobnymi zmianami w UI.
- ✅ Elastyczność i precyzja
Możliwość przełączania się między sterowaniem AI a precyzyjnym kodem daje zespołom optymalną kontrolę nad testami.
Korzyści Strategiczne
- ✅ Optymalizacja zasobów
Czas zaoszczędzony na utrzymywaniu testów może zostać przeznaczony na bardziej wartościowe zadania, takie jak testowanie eksploracyjne czy rozwój nowych funkcjonalności.
- ✅ Szybszy czas wprowadzenia produktu na rynek (Time-to-Market)
Szybsze pisanie i większa niezawodność testów, w połączeniu z integracją CI/CD, pozwala na szybsze i bardziej pewne wdrażanie nowych funkcjonalności.
Podsumowanie i Pozycjonowanie Rynkowe
Stagehand zajmuje unikalne miejsce na rynku. Wypełnia lukę między tradycyjnymi frameworkami opartymi na kodzie a rozwiązaniami czysto agentowymi.
Nie jest bezpośrednim konkurentem Playwright, lecz jego ewolucją. Eliminuje kluczowe słabości, takie jak kruchość i wysoki nakład pracy manualnej. Stagehand zapewnia kontrolę i niezawodność, co jest kluczowe w testach produkcyjnych. Stagehand to otwartoźródłowy framework stworzony przez Browserbase. Sugeruje model, w którym narzędzie działa jako magnes dla deweloperów. Natomiast pełnoskalowe wdrożenie na poziomie przedsiębiorstwa wymaga skalowalności i zaawansowanych funkcji monitorowania. Należą do nich np. podgląd sesji na żywo oraz zaawansowane raportowanie. Takie wdrożenie prowadzi do komercyjnej platformy Browserbase. Jest to istotna kwestia dla decydentów, którzy rozważają wdrożenie na dużą skalę.
Porównanie Stagehand vs Playwright
|
Cecha
|
Playwright
|
Stagehand
|
|
Język naturalny
|
❌ Nie
|
✅ Tak
|
|
Samonaprawiające się testy
|
❌ Nie
|
✅ Tak
|
|
Agent (przepływy AI)
|
❌ Nie
|
✅ Tak
|
|
Ekstrakcja danych przez AI
|
❌ Nie
|
✅ Tak
|
|
Odporność na zmiany UI
|
Niska
|
Wysoka
|
|
Integracja z chmurą
|
Ograniczona
|
Pełna (opcjonalnie, z platformą Browserbase)
|
|
Szybkość pisania testów
|
Średnia
|
Bardzo wysoka
|
|
Utrzymanie testów
|
Pracochłonne
|
Szybkie, proste
|
|
Model kosztów
|
Zazwyczaj darmowy, koszty związane z infrastrukturą i pracą inżynierów
|
Otwartozródłowy, ale korzystanie z funkcji AI wiąże się z opłatami za API (np. OpenAI, Anthropic), a pełna integracja, oferująca funkcje takie jak podgląd sesji na żywo i zaawansowane raportowanie, jest dostępna na komercyjnej platformie Browserbase ( https://www.stagehand.dev/evals )
|
Link do zasobów zewnętrznych
- https://github.com/emiliakkomenda/StagehandDemo – repozytorium z kodem i przykładami
- https://www.stagehand.dev – strona główna Stonehand
- https://docs.stagehand.dev/first-steps/introduction – oficjalna dokumentacja Stonehand
- https://github.com/browserbase/stagehand – oficjalne repozytorium Stonehand
- https://www.browserbase.com/blog?search=Stagehand&page=1 – oficjalny blog o nowościach
- https://playwright.dev/ – strona główna Playwright
- https://github.com/microsoft/playwright – repozytorium Playwright
- https://jaktestowac.pl/darmowy-playwright/ – darmowe materiały i kursy o Playwright
Emilia Krzemińska-Komenda
Emilia to doświadczona inżynierka QA w Hicron Software, łącząca w swojej pracy analityczny umysł testera z pasją do automatyzacji. Mocno wierzy, że technologia, w tym sztuczna inteligencja, powinna służyć ludziom, dlatego aktywnie rozwija swoją wiedzę w kierunku testowania AI oraz dostępności cyfrowej. Wierzy, że testowanie to droga do tworzenia lepszych i bardziej inkluzywnych produktów. |
Spotkałem się z podobnym narzędziem pod nazwą Zero Step – jako płatna usługa, ale widziałem też open sourcową wersję gdzie podawało się własny API key.
Nie miałem jednak jeszcze sposobności wdrożenia jego albo porównania/poszukania alternatyw.
To co mnie przekonuje w tym hybrydowym podejściu (w przeciwieństwie do testów wykonywanych w pełni przez AI agenta na podstawie języka naturalnego – które są dla mnie trochę pochodną podejści record-replay i zero-code), jest jednak większa deterministyczność testów, szybkość egzekucji i możliwość wyrażenia bardziej niż banalne logiki w najprostszy sposób – czyli jako kod.
Cały clue tego rozwiązania to umiejętne zbalansowanie tego gdzie wykorzystywać prompty a gdzie goły kod.
Zastanawia mnie też jak to ma się do innego tematu związanego z AI czyli self-healing tests. Czy te podejścia raczej stosować rozdzielnie czy można z nich jednak korzystać razem (i czy to się opłaca 😉 ).
Jeśli głównym celem narzędzi gdzie w kodzie używamy prompty, jest stabilizacja testów (co może być oznaką suboptymalności CI z którą nie zawsze można/opłaca się coś robić) to pytanie brzmi czy “samonaprawianie” się testów nie jest bardziej efektywniejsze bo angażuje AI (czas wykonania i koszty) tylko w momencie faktycznego faila w teście.
Nie musi być wybór ‘albo-albo’. Dzięki hybrydowemu modelowi mamy możliwość połączyć sztywny kod (Playwright) dla elementów stabilnych z AI (page.act) dla elementów dynamicznych. To optymalizuje koszty i szybkość. Masz rację — oparcie wszystkiego na promptach jest drogie (API). Dlatego najsensowniejsza strategia to używanie AI „chirurgicznie” — tylko tam, gdzie koszt ciągłego utrzymania selektorów przewyższa koszt tokenów, czyli AI wstrzykujemy tylko tam, gdzie UI jest dynamiczne/kruche, aby zredukować kosztowny maintenance. Prewencja (hybryda) jest tańsza niż ciągłe leczenie (reaktywny self-healing), pod warunkiem, że używasz AI tylko tam, gdzie to konieczne.
Zastanawiałem się też na możliwością połączenia narzędzi jak Stagehand i self-healingu testów.
Problemy jakie wiążą się z self-healingiem to dodatkowa infrastruktura (i pozostawienie człowieka w pętli (review zmian, compliance itp.).
Z drugiej strony przy Stagehand clue leży w tym gdzie go używać (dynamicznie rozwijane części aplikacji) a gdzie nie (stabilny UI). A potem jak robić przejście z jednego do drugiego – bo pewnie jak jakaś część się ustabilizuje to wolelibyśmy jednak mieć deterministyczne i szybsze (nie mówiąc tańsze) testy w czystym kodzie.
Tutaj nasuwa mi się koncepcja w której przy retry (powiedzmy ustawionym na 2), w pierwszej próbie robimy normalny retry (buffor na flaky testy) a przy drugim retry używamy już Stagehanda by zapewnić autonaprawę.
Tutaj oczywiście potrzebne było by odpowiednie tagowanie testów (np, flaky i broken) oraz odpowiedni follow-up proces to auto-healingu kodu (by nie być zależnym od AI w kolejnych runach).
Sama implementacja retry przez Standhand może być opakowana w test stepy które z jednej strony służą jako abstrakt testu i jego dokumentacja, a z drugiej są promptem dla AI jako retry ostatniej szansy 😉
Koncepcja „AI Fallback” przy ostatnim retry to strzał w dziesiątkę pod kątem ekonomii.
Widzę tu tylko jedno wyzwanie: kontekst. Playwright przy błędzie zgłasza brak selektora, a Stagehand potrzebuje instrukcji (intencji). Żeby to zadziałało, musielibyśmy mapować kroki testu na prompty. Pełna zgoda też co do „pętli zwrotnej” — AI powinno służyć do jednorazowej naprawy, a nie jako stała proteza, bo koszty API nas zjedzą. Widzę tu potencjał na PoC 😉
Jeśli kroki testu opakować w abstrakty typu
await testStep("Accept changes", async () => { await page.getByRole("button", { name: "OK" }).click(); });To możemy pod spodem opakować to w test.step, i dołożyć obsługę “AI fallback” (kradnę to słówko 😉 ).
Wygląda na super rozwiązanie spinające Playwright i Stagehand: string “Accept changes” faktycznie może służyć jednocześnie jako dokumentacja dla człowieka i prompt dla AI w razie awarii.
Jedynie zastanawia mnie jedna rzecz: zazwyczaj w Playwright traktujemy test.step jako sposób na grupowanie logiczne (np. „Dodaj do koszyka i przejdź do kasy”). Jest to dobre dla czytelności raportów, ale przy pokazanym przez Ciebie podejściu może być ryzykowne.
Jeśli w takim zgrupowanym kroku kod wywali się w połowie (np. na kasie), to AI wtedy wejdzie na stronę, gdzie pierwsza część zadania jest już wykonana przez kod. Wtedy AI może wpaść w pułapkę False Positive: zobaczy produkt w koszyku, uzna, że zadanie z promptu jest już spełnione i zakończy krok sukcesem, pomijając realne przejście do kasy. Alternatywnie – spróbuje dodać produkt ponownie (duplikat).
Żeby to zadziałało bezpiecznie, musielibyśmy narzucić rygorystyczną dyscyplinę: jedna akcja zmieniająca stan = jeden testStep. Ciekawa jestem Twojego zdania na ten temat :)!
Spoko art. Ale…
Powiem krótko:
1. Technologia fascynująca – eliminuje kruchość testów, przyspiesza pisanie
2. Ekonomia wątpliwa – w skali enterprise koszty mogą przekroczyć oszczędności z automatyzacji
Ja obecnie używam Claude Code z MCP Playwright i inne cuda custom commands etc – do ogarniania struktury, kodu i zmian w testach – ale też do zwykłego kodzenia.
Widząc ile przy dziesiątkach, setkach testów zajmuje pracy (tokenów) – review, bug fixing etc – bałbym się to puścić po API (tutaj w planie MAX mam stałą stawkę. Cisnę, aż się serwery gotują). Po API – oczami wyobraźni widzę bankructwo portfela 😛
Na chwilę obecną ten bliżej nieokreślony koszt jest mega barierą przy takim codziennym kodzeniu testów i weryfikacji every day.
Hej,
Dzieki za perspektywę!
Zgadzam się z tym punktami – ROI jest tutaj mega ważne.
Koszty zapytań po API nie sa jakieś porażające… ale jak się zacznie z tego intensywniej korzystać (a tokeny pójdą w setki tysięcy…), to tak jak piszesz – kolorowo nie będzie 😅
Warto to policzyć przy POC/MVP 😉
Warto znać te narzędzia – idee, architekturę i sposób rozwiązywania problemów. Dzięki temu zyskujemy nie tylko praktyczne umiejętności, ale też szerszy obraz tego, w jakim kierunku zmierza automatyzacja i jakie kompromisy trzeba brać pod uwagę😉