Branża wytwarzania oprogramowania przeżywa bezprecedensowy skok produktywności w wielu wymiarach. Po pierwsze, za sprawą transformacji z Quality Assurance (QA) na Quality Engineer (QE), czyli przejścia od reaktywnego znajdowania błędów do proaktywnego projektowania jakości w całym cyklu życia oprogramowania. Po drugie, wdrożenie AI-assisted coding – od GitHub Copilot po wbudowanych asystentów w IDE – sprawia, że kod powstaje szybciej niż kiedykolwiek wcześniej. To świetna wiadomość dla zespołów projektowych, ale jednocześnie ogromne wyzwanie dla Quality Engineerów.
W swojej pracy zauważam, że zespoły QE coraz częściej stają przed dylematem: Jak utrzymać pokrycie testowe, kiedy tempo dostarczania kodu rośnie wykładniczo, a zasoby ludzkie pozostają na tym samym poziomie?
Na rynku pojawia się odpowiedź: Agentic Testing – koncepcja, w której narzędzie testowe nie jest już pasywnym wykonawcą skryptów, lecz staje się autonomicznym, cyfrowym członkiem zespołu (ang. Digital Teammate) zdolnym do interpretacji, podejmowania decyzji i adaptacji. Przykład realizacji tej wizji w narzędziu mabl chciałbym szerzej omówić.
Zanim jednak przyjrzymy się konkretnym funkcjonalnościom, warto zrozumieć, jak mabl definiuje samą koncepcję Agentic Testing i na jakim fundamencie ją buduje.
Czym jest Agentic Testing w ujęciu mabl?
Moim zdaniem kluczowe jest rozróżnienie pomiędzy AI-enhanced testing (gdzie AI wspiera człowieka punktowo, np. przy self-healingu lokatorów) a właśnie Agentic Testing.
mabl definiuje Agentic Testing jako podejście, w którym nasz cyfrowy współpracownik interpretuje, decyduje i adaptuje się jak człowiek.
Platforma określa tę zdolność jako wynik fuzji dwóch filarów.
Pierwszy filar
Sophisticated Automation – odpowiada za solidne fundamenty techniczne. Z perspektywy praktycznej oznacza to, że platforma obsługuje nie tylko standardowe scenariusze webowe i mobilne, ale radzi sobie również z elementami, które w wielu konkurencyjnych narzędziach wymagają obejścia – mam tu na myśli choćby Shadow DOM czy testowanie treści osadzonych w plikach PDF. Istotna jest też możliwość równoległego uruchamiania testów, co przy dużych zestawach regresyjnych przekłada się na realną oszczędność czasu.
Drugi filar
Advanced Intelligence – to warstwa, którą mabl rozwijał od momentu powstania platformy. Warto zwrócić uwagę, że nie jest to wyłącznie duży model językowy „doklejony” do istniejącego narzędzia. Ważne jest, że w zależności od kontekstu zadania platforma sięga po różne mechanizmy – od klasycznego uczenia maszynowego, przez systemy reguł eksperckich, aż po generatywną AI. Takie hybrydowe podejście pozwala unikać sytuacji, w których GenAI jest stosowane tam, gdzie prostszy algorytm byłby szybszy i tańszy.
Zdaniem twórców mabla, agent sukcesywnie gromadzi dane o systemie, co pozwala na optymalizację pracy własnej oraz wsparcie wydajności całego zespołu.
Pięć kluczowych umiejętności Agentic Testera w mabl
mabl definiuje swojego agenta testowego przez pryzmat pięciu Core Skills, czyli zestawu kompetencji, które odzwierciedlają sposób pracy doświadczonego testera.
Poniżej krótko omówię każdą z nich.
Acting – interakcja jak prawdziwy użytkownik
Zgodnie z dokumentacją mabl, agent wchodzi w interakcję z aplikacją tak, jak zrobiłby to człowiek. Pod nagłówkiem Acting platforma wymienia:
- klikanie, wpisywanie danych i nawigację w przeglądarkach webowych,
- przewijanie i wprowadzanie danych w aplikacjach mobilnych (iOS, Android),
- bezpośrednie wywoływanie i walidację API.
Często spotykamy się z wyzwaniem, że narzędzia automatyzacji nie radzą sobie z bardziej złożonymi elementami UI. Warto zauważyć, że mabl w ramach swojego ogólnego fundamentu automatyzacji (wspomnianego wcześniej Sophisticated Automation) informuje o obsłudze Shadow DOM, e-maili i plików PDF.

Observing – inteligentna percepcja stanu aplikacji
Jak wszyscy wiemy, sam fakt wykonania akcji to za mało – agent musi rozumieć, co widzi. W sekcji Observing platforma zbiera trzy rodzaje danych podczas wykonywania testu:
- zrzuty ekranu, które później zasilają funkcje Visual AI,
- migawki struktury DOM, nieocenione przy debugowaniu (pozwalają porównać, jak wyglądał DOM w momencie sukcesu vs. awarii),
- wyniki wywołań API, co zamyka obraz tego, co dzieje się „pod maską” aplikacji.
To właśnie na fundamencie obserwacji budowana jest jedna z najciekawszych funkcjonalności – Visual AI, o której piszę szerzej w dalszej części artykułu.
Deciding & Reasoning – autonomiczne podejmowanie decyzji
To serce koncepcji agentic. Agent mabl nie tylko wykonuje zaprogramowane kroki – on rozumuje i podejmuje decyzje. Agent ma samodzielnie analizować sytuację, wyciągać wnioski i reagować na zmiany w aplikacji bez potrzeby ludzkiej interwencji.
W praktyce przekształca się to w konkretne funkcjonalności. Auto-Healing automatycznie naprawia testy, gdy zmienia się UI. Visual Assist dodaje natomiast analizę wizualną screenshotów, dzięki której agent „widzi” układ strony podobnie jak człowiek. Połączenie dwóch metod analizy – klasycznej (DOM) i wizualnej – sprawia, że testy są znacznie bardziej odporne na refaktoryzację frontendu.
Auto TFA (Test Failure Analysis), czyli automatyczna analiza awarii testów i planów
Mabl automatyzuje proces analizy niepowodzenia – na podstawie wyników uruchomienia agent samodzielnie stawia diagnozę, kategoryzuje problem (np. błąd w aplikacji vs. niestabilność testu) i wskazuje, od czego zacząć naprawę. Działa to zarówno na poziomie pojedynczego testu, jak i całego planu testowego.
W swojej pracy zauważam, że to właśnie Auto TFA jest funkcjonalnością o ogromnym potencjale, która przyczynia się do skrócenia czasu od wykrycia defektu do jego rozwiązania. W praktyce możemy uniknąć ręcznej analizy logów, przechodząc od razu do gotowej diagnozy.

Do tego wszystkiego należy dodać jeszcze Intelligent Waits, czyli algorytm automatycznie dobiera czasy oczekiwania, eliminując problem „flaky tests” wynikający z opóźnień sieciowych.
Learning & Remembering – ciągłe budowanie wiedzy
Jednym z ciekawszych wyróżników jest to, że mabl Agent stale uczy się na podstawie realizowanych testów, co pozwala mu na budowanie zaawansowanych modeli zachowań i wydajności aplikacji. Kluczowym elementem wprowadzonym w październiku 2025 jest AI Vectorization & Test Semantic Search.
Kluczowa zmiana polega na sposobie indeksowania testów, co w praktyce oznacza, że agent nie ogranicza się do identyfikacji słów kluczowych, lecz rozpoznaje faktyczne przeznaczenie i operacyjną funkcję testu w systemie. Pozwala to np. na wykrywanie, że dwa testy o zupełnie różnych nazwach de facto pokrywają ten sam scenariusz.
Integrating & Collaborating – praca w ekosystemie zespołu
Ostatnia umiejętność to integracja z istniejącymi narzędziami i przepływami pracy.
Szczególnie interesującą rolę pełni mabl MCP Server (Model Context Protocol). Dla mnie jest to jeden z najbardziej obiecujących elementów całej architektury.
W praktyce działa to tak: Deweloper pracuje w swoim IDE, wprowadza zmianę w kodzie i bez opuszczania edytora może zapytać agenta: „Jakie testy mogą być dotknięte moją zmianą (Test Impact Analysis)?”. Agent zwraca listę powiązanych testów, a w przypadku wykrycia awarii – podpowiada, co może być przyczyną. To istotna zmiana w porównaniu z tradycyjnym flow.
Powyższe pięć Core Skills to ogólna mapa kompetencji agenta. W kolejnych rozdziałach przyjrzymy się bliżej wybranym zdolnościom, które wyrastają z tego fundamentu – zaczynając od jednej z najbardziej zaawansowanych: Visual AI.
Visual AI – kontekstowa detekcja regresji wizualnej
W tradycyjnym podejściu testy regresji wizualnej porównują piksele. Jednak w praktyce może oznaczać to false positives.
Jako główne źródła problemów należy wskazać:
- dynamiczny content,
- specyfikę renderowania fontów w różnych środowiskach,
- zmienność komponentów zewnętrznych.
Wywołują one nieuzasadnione alerty, mimo braku faktycznych błędów w logice aplikacji.
Pojawia się zatem pytanie: Jak Visual AI rozwiązuje ten problem?
Zgodnie z dokumentacją mabl, Visual AI nie porównuje pikseli – interpretuje znaczenie wizualne. Jest to opisywanie na 3 poziomach:
- Semantic Understanding of UI Elements – system rozpoznaje, czym jest dany element i ocenia zmiany w kontekście. Opierając się na prostym, ale trafnym przykładzie – tło przycisku zmienia się (np. z niebieskiego #0066CC na granatowy #003366). Visual AI natomiast oceni zmianę z perspektywy użyteczności – czy element nadal jest rozpoznawalny jako przycisk, czy spełnia wymogi dostępności i czy nie zlewa się z tłem. Jeśli odpowiedź na te pytania brzmi „tak” – zmiana jest akceptowana.
- Pattern Recognition Across States – czyli rozpoznawanie wzorców w obrębie różnych wariantów tego samego widoku. Każda nowoczesna aplikacja webowa może wyglądać inaczej w zależności od kontekstu – inny układ widzą zalogowani użytkownicy i goście, inaczej prezentuje się interfejs na telefonie i na desktopie, a do tego dochodzi jeszcze dark mode, spinnery ładowania czy komunikaty błędów. Zamiast flagować każdą z tych różnic jako potencjalny problem, Visual AI buduje model tego, jak aplikacja powinna wyglądać w danym stanie i zgłasza tylko odchylenia od wyuczonego wzorca.
- Visual Intent Recognition – na najwyższym poziomie Visual AI ocenia zmiany wizualne nie pod kątem „co się zmieniło”, ale „czy strona nadal spełnia swoją funkcję”. Opierając się na przykładzie formularza logowania – może się zmienić font, kolor tła, odstępy, ale kluczowe pytanie brzmi, czy użytkownik wciąż jest w stanie się zalogować. Czy pola są widoczne? Czy wie, gdzie kliknąć? Czy w razie pomyłki dostanie informację zwrotną? Takie podejście – oceniające intencję interfejsu, a nie pikselową zgodność – eliminuje większość fałszywych alarmów, z którymi borykają się tradycyjne narzędzia.
Visual AI pokazuje, jak agent radzi sobie z percepcją. Ale agentyczne podejście mabl sięga dalej – obejmuje również samo tworzenie testów od zera.
Test Creation Agent – autonomiczne tworzenie testów
Jedną z przełomowych funkcji ogłoszonych w połowie minionego roku i od tego momentu rozwijanych jest Test Creation Agent.
Proces wygląda następująco: Tester opisuje w języku naturalnym, co test powinien sprawdzać (np. „zweryfikuj, że użytkownik może dodać produkt do koszyka i przejść do płatności”). Agent na tej podstawie samodzielnie planuje kolejność kroków, identyfikuje, które fragmenty testu mogą być współdzielone z innymi scenariuszami (np. flow logowania) i generuje gotowy test zdolny do uruchomienia w środowisku chmurowym mabl. Oczywiście wynik wymaga ludzkiej weryfikacji – ale punkt startowy jest nieporównywalnie lepszy niż puste płótno.
W swojej pracy zauważam, że to właśnie tworzenie nowych testów pochłania najwięcej czasu przy wdrażaniu nowych funkcjonalności. Jeśli agent jest w stanie zbudować solidny szkielet testu, który następnie ręcznie zweryfikujemy i dopracujemy – oszczędzamy czas, nie tracąc przy tym na jakości.
Application Summaries – kontekst, który zmienia jakość generowanych testów
W styczniu 2026 mabl wprowadził nową funkcjonalność wzmacniającą zdolności Test Creation Agent: Application Summaries. Jest to mechanizm automatycznego generowania opisu testowanej aplikacji webowej, który służy jako dodatkowy kontekst przy tworzeniu nowych testów.
Jako jedno z największych wyzwań przy korzystaniu z agentów AI do generowania testów wskazuje się właśnie dostarczenie odpowiedniego kontekstu.
Jak działają Application Summaries?
Mechanizm działa automatycznie i nie wymaga interwencji użytkownika. Gdy tworzony jest test dla nowej aplikacji webowej, mabl rozpoczyna generowanie podsumowania aplikacji (ang. application summary) w ciągu kilku godzin. Podsumowania są następnie okresowo aktualizowane na podstawie ostatniej aktywności testowej. Co najważniejsze – Test Creation Agent wykorzystuje ten opis jako dodatkowy kontekst przy planowaniu kroków nowego testu.
Warto podkreślić istniejące na ten moment dwa ograniczenia: Podsumowania są generowane automatycznie i nie podlegają ręcznej edycji, a ich przetwarzanie i wygenerowanie mogą zająć kilka godzin. Jednak mimo tych dwóch wad, moim zdaniem, to istotny krok naprzód. Application Summaries adresują problem, który zna każdy, kto próbował generować testy za pomocą AI – konieczność pisania szczegółowych promptów opisujących, czym w ogóle jest testowana aplikacja. Funkcja ta zmniejsza obciążenie związane z pisaniem idealnego promptu i daje większą pewność co do procesu planowania agenta.

Podsumowanie – co to oznacza dla nas, testerów?
Moim zdaniem kluczowe jest to, że Agentic Testing nie zastępuje testera – zmienia charakter jego pracy. mabl konsekwentnie pozycjonuje swojego agenta jako cyfrowego współpracownika, który uzupełnia ludzką ekspertyzę, a nie ją eliminuje.
Z mojej perspektywy bardzo ważne jest, abyśmy my sami traktowali wszystkie nowości w tym temacie z ciekawością, ale też pewną dozą sceptycyzmu. Nie zapominajmy, że technologia ma nam pomóc lepiej wykonywać naszą pracę i uwalnia nas często od powtarzalnych, czasochłonnych zadań, dzięki czemu zyskujemy czas na spojrzenie na temat testów z szerszej perspektywy strategii i architektury jakości.
Zostaw komentarz