AI jako Architekt Testów: Beyond Codegen 2.0🤖🧪

Jak LLM i Playwright współpracują, aby generować odporne scenariusze brzegowe

Beyond Codegen 2.0

W nowoczesnych, dynamicznych aplikacjach webowych, największym wyzwaniem dla zespołów QA jest utrzymanie stabilności testów E2E (End-to-End). Aplikacje te są bogate w JavaScript i często zmieniają się wizualnie, co sprawia, że tradycyjne metody automatyzacji zawodzą.

Dla zespołów QA i szerszego procesu wytwarzania oprogramowania, ma to bezpośrednie i bolesne konsekwencje:

• Lawinowy wzrost kosztów utrzymania (maintenance)
  Dynamicznie zmieniające się interfejsy użytkownika (UI) prowadzą do niestabilności testów (flakiness) z powodu kruchych lokatorów. Zespoły QA zamiast skupiać się na rozwoju jakości i budowaniu nowych scenariuszy, walczą z naprawą zepsutych testów.
• Efekt mechaniczny charakter tradycyjnych narzędzi
  Narzędzia do nagrywania, takie jak Playwright Codegen, zautomatyzowały generowanie bazowego kodu, ale są z natury mechaniczne. Rejestrują interakcje, ale nie posiadają inteligencji scenariuszowej (z ang. scenario intelligence, czyli zdolności do projektowania scenariuszy testowych).
• Luka w pokryciu testami (coverage gap)
  Automatyczne nagrywanie bez analizy nie jest w stanie samodzielnie zidentyfikować scenariuszy brzegowych (edge cases), warunków wyścigów ani złożonej, nieliniowej logiki biznesowej. W efekcie, zespoły mają fałszywe poczucie bezpieczeństwa, a testy zawodzą w kluczowych momentach na produkcji.
• Wymóg ręcznej interwencji inżynierskiej
  Wygenerowany kod często wymaga ręcznej optymalizacji, dodawania zaawansowanej logiki oczekiwania, precyzyjnych asercji i strukturyzacji zgodnej z Page Object Models (POMs). To obciąża Senior Testerów i Architektów Testów dodatkową, powtarzalną pracą.

Koncepcja Beyond Codegen 2.0 jest bezpośrednią odpowiedzią na te problemy. Stanowi nowy model, w którym rola Senior Testera i Architekta ewoluuje z pisarza kodu na Mentora AI i Strategię.

AI Architekt Testów: Strategiczne Użycie LLM

Kluczową rolą staje się wykorzystanie Dużych Modeli Językowych (LLM) jako AI Architekta Testów. LLM dostarcza inteligencji scenariuszowej, wykraczając poza proste nagrywanie i wchodząc w domenę projektowania testów.

Artykuł prezentuje Architekturę dwuetapową:

1. Etap 1: LLM jako Analityk Zachowania (Test Planner)
   Generuje wyczerpujące scenariusze testowe w formacie BDD (GIVEN/WHEN/THEN), z obowiązkowym uwzględnieniem scenariuszy brzegowych i modelowania stanów aplikacji.
2. Etap 2: LLM jako Coder Playwrighta (Inteligentny Translator)
   Konwertuje scenariusze BDD na gotowy, odporny kod Playwright. Priorytetyzuje odporne lokatory oraz wykorzystuje abstrakcje Page Object Models (POMs).

To połączenie strategicznego myślenia LLM z niezrównaną stabilnością Playwrighta pozwala na osiągnięcie niespotykanej dotąd kompletności pokrycia testami. Jest to przyszłość testowania.

Przekraczanie Granic Codegen: Od Rejestracji do Architektury

Playwright Codegen jest niezrównany w szybkim tworzeniu bazowego kodu testu i generowaniu odpornych lokatorów (priorytetem jest rola, tekst i test-id zamiast kruchych selektorów CSS). Mimo to, ma on naturalne ograniczenia:

• Brak inteligencji scenariuszowej
  Codegen rejestruje, ale nie analizuje. Nie jest w stanie samodzielnie zidentyfikować scenariuszy brzegowych (edge cases), warunków wyścigów, czy złożonych, wieloetapowych przepływów, które wymagają nieliniowej logiki lub nietypowych danych wejściowych.
• Wymaga interwencji inżynierskiej
  Wygenerowany kod często wymaga ręcznej optymalizacji, dodawania zaawansowanej logiki oczekiwania (poza automatycznym auto-wait Playwrighta), asercji i strukturyzacji zgodnej z projektem.

W obliczu złożoności nowoczesnych aplikacji webowych, prawdziwą wartość dodaną przynosi strategiczne wykorzystanie dużych modeli językowych, które wykracza poza proste nagrywanie i wchodzi w domenę architektury testów. Rolą AI Architekta Testów jest wyeliminowanie tej luki.

Od Kruchości do Odporności

Kluczową różnicą jest to, że LLM, w przeciwieństwie do tradycyjnego nagrywania, projektuje kod, który jest z natury bardziej odporny, koncentrując się na semantyce i funkcjonalnej roli elementu.

await page.locator('.sidebar > .menu > a:nth-child(2)').click();

await page.getByRole('link', { name: 'Moje Zamówienia' }).click();

LLM nie tylko generuje kod, ale stosuje strategię odporności, używając odpowiednich abstrakcji (POMs) i najlepszych praktyk związanych z lokatorami, co jest niemożliwe do osiągnięcia dla narzędzia rejestrującego jedynie interakcje.

LLM jako Analityk Zachowania Aplikacji

LLM, takie jak GPT-4 czy Gemini Pro, zasilają nową erę w projektowaniu testów. Zamiast ręcznego pisania specyfikacji, LLM może pełnić funkcję wirtualnego analityka QA na najwyższym poziomie. Jego prawdziwa wartość leży w zdolności do wnikliwego wnioskowania na temat potencjalnych słabych punktów i niestabilnych scenariuszy, które tradycyjny, manualny tester mógłby przeoczyć.

Generowanie Scenariuszy Brzegowych (Edge Case Mining)

Dzięki dostępowi do dokumentacji API, historycznych user stories oraz nawet logów błędów, LLM potrafi zidentyfikować nie tylko ścieżkę pozytywną, ale także scenariusze negatywne i brzegowe.
Ta zdolność opiera się na analizie:

• Kontekstu historycznego i wymagań
  Obejmuje to tradycyjną dokumentację (API, historyczne user stories), a także szczegóły defektów z Jiry oraz strategie wdrożeniowe (np. aktywne feature flags), co pozwala na modelowanie ryzyka.
• Danych operacyjnych i behawioralnych
  Analiza logów błędów oraz statusów HTTP (np. 4xx/5xx z produkcji i stagingu) z faktycznego użycia aplikacji pozwala LLM na identyfikację rzeczywistych, niestabilnych punktów i najbardziej krytycznych warunków wyścigów.

Kluczem do wykorzystania tej zdolności jest odpowiednie promptowanie. Architekt Testów musi dostarczyć LLM kontekst i zmusić go do myślenia z perspektywy projektowania odpornego na błędy.

Metryki Efektywności LLM (Pomiar Wartości Dodanej)

Wdrożenie LLM jako analityka wymaga mierzenia jego wpływu na jakość kodu i pracę zespołu QA. Kluczowe metryki do śledzenia to:

• Liczba nowo dodanych scenariuszy brzegowych (added cases)
  Mierzenie liczby unikalnych scenariuszy BDD (GIVEN/WHEN/THEN) wygenerowanych przez LLM, które nie zostały pierwotnie uwzględnione przez zespół.
• Procent nowo wykrytych defektów w sprincie (% new defects found)
  Śledzenie odsetka defektów wykrytych w trakcie sprintu, które zostały ujawnione przez testy automatyczne wygenerowane na podstawie scenariuszy LLM, a nie przez manualne testowanie czy Code Review. Jest to bezpośredni wskaźnik luki w pokryciu (Coverage Gap), którą LLM jest w stanie wypełnić.
• Odsetek zaakceptowanych rekomendacji (% Scenarios Acceptance Rate)
  Jest to miara jakości i trafności wygenerowanych scenariuszy. Liczy się stosunek liczby scenariuszy zaproponowanych przez LLM, które zostały zaakceptowane przez zespół QA/Developerów podczas przeglądu (Human-in-the-Loop), do całkowitej liczby wygenerowanych scenariuszy. Wysoki wskaźnik akceptacji potwierdza, że LLM rozumie domenę i generuje wartościowy, nieobciążający scenariuszowo kod.
• Wpływ na całkowity koszt posiadania testów (TCO/Productivity Uplift)
  Kluczowa metryka biznesowa. Mierzy zmianę średniego czasu (np. w godzinach/story pointach) potrzebnego na tworzenie, przeglądanie i utrzymanie (maintenance) scenariuszy testowych E2E/API po wdrożeniu LLM.
  • Przed LLM (Baseline): Średni czas X.
  • Po LLM (Production): Średni czas Y.
  • Oczekiwany rezultat: Zmniejszenie czasu (X > Y), co jest bezpośrednią redukcją kosztów operacyjnych dla interesariuszy. Ta metryka uzasadnia inwestycję w architekturę AI.

Walidacja Scenariuszy i Pętla Feedbacku (Feedback Loop)

Aby zapewnić, że scenariusze generowane przez LLM są wartościowe, a nie stanowią obciążenia, niezbędny jest stały proces walidacji w ramach cyklu rozwoju. Na spotkaniach Sprint Review (przegląd sprintu) zespół (QA i Developerzy) weryfikuje jakość i trafność wygenerowanych scenariuszy:

• Liczba błędów wprowadzonych (bugs introduced)
  Mierzenie, jak często kod wygenerowany przez LLM (Etap 2) zawiera błędy logiczne lub błędy, które mogłyby zawieść w CI/CD.
• Współczynnik fałszywych alarmów (false positives rate)
  Kluczowy wskaźnik to liczenie, ile razy scenariusze LLM, a następnie generowane testy, kończą się niepowodzeniem z powodu niestabilności testu (flakiness) lub niepoprawnej logiki, a nie z powodu błędu w aplikacji. Niska stopa fałszywych alarmów potwierdza, że LLM nie tylko generuje scenariusze, ale także stosuje odporne praktyki (np. lepsze lokatory, zaawansowane asercje).

Analiza Wymagań i Prompty Architektoniczne

Kluczem do wykorzystania tej zdolności jest odpowiednie promptowanie. Architekt Testów musi dostarczyć LLM kontekst i zmusić go do myślenia z perspektywy projektowania odpornego na błędy.

Zarządzanie Promptami i Nadzór (Governance)

W miarę jak prompt staje się strategicznym zasobem projektowym (podobnie jak pliki .md stanowiące manifesty), jego zarządzanie musi stać się częścią cyklu DevOps/MLOps. Kluczowe elementy nadzoru to:

• Kontrola wersji promptów
  Prompt musi być traktowany jako kod architektoniczny – przechowywany w kontroli wersji (np. Git) w celu śledzenia ewolucji strategii i odtwarzalności wyników generowania scenariuszy.
• Zatwierdzanie zmian (Human-in-the-Loop)
  Wprowadzanie krytycznych modyfikacji do promptu musi wymagać formalnego zatwierdzenia przez Senior QA lub Architekta. Zapewnia to, że ludzka inteligencja domenowa (Human-in-the-Loop) sprawuje stały nadzór nad strategią generowanych testów.
• Polityka danych (PII/Sekrety)
  Należy ściśle określić politykę dotyczącą danych wejściowych dla LLM. Promptowanie nigdy nie powinno zawierać danych osobowych (PII) ani sekretów (kluczy API, haseł) ze względu na ryzyko ich niekontrolowanego przetwarzania. Architekt musi dbać o to, by dostarczany kontekst był zanonimizowany i zgeneralizowany.

Przykład Promptu dla LLM

• Prompt systemowy (Rola)
  Jesteś doświadczonym Al Architektem Testów Playwright, ekspertem w testowaniu front-end oraz API. Twoim zadaniem jest projektowanie scenariuszy brzegowych i warunków wyścigów, aby maksymalizować % krytycznych user journeys z asercjami domenowymi. W swoich odpowiedziach musisz stosować nomenklaturę BDD (GIVEN/WHEN/THEN).
• User story
  Jako użytkownik, chcę mieć możliwość resetowania hasła na stronie logowania, aby móc odzyskać dostęp do konta.
• Zadanie

  Wygeneruj kompletną listę scenariuszy testowych (minimum 3 pozytywne, 5 negatywnych/brzegowych) dla powyższej user story. Koncentruj się na:

  • limitach danych/częstotliwości,
  • stanach (np. konto zablokowane),
  • scenariuszach multi-context (równoczesne próby z różnych sesji).

I w wersji bardziej przystępnej dla LLM (format markdown):

# Prompt systemowy (Rola)
Jesteś doświadczonym Al Architektem Testów Playwright, ekspertem w testowaniu front-end oraz API. Twoim zadaniem jest projektowanie scenariuszy brzegowych i warunków wyścigów, aby maksymalizować % krytycznych user journeys z asercjami domenowymi. W swoich odpowiedziach musisz stosować nomenklaturę BDD (GIVEN/WHEN/THEN).

# User story
Jako użytkownik, chcę mieć możliwość resetowania hasła na stronie logowania, aby móc odzyskać dostęp do konta.

# Zadanie
Wygeneruj kompletną listę scenariuszy testowych (minimum 3 pozytywne, 5 negatywnych/brzegowych) dla powyższej user story. Koncentruj się na: 
- limitach danych/częstotliwości, 
- stanach (np. konto zablokowane), 
- scenariuszach multi-context (równoczesne próby z różnych sesji).

Modelowanie Stanów Aplikacji (State Modeling)

Najważniejsza rola LLM jako AI Architekta Testów polega na wykraczaniu poza proste klikanie elementów. LLM jest w stanie pomóc w mapowaniu złożonych przejść między stanami w aplikacji (np. statusy zamówienia: w trakcie realizacji → w transporcie → dostarczone → anulowane).
W tym procesie, kluczowe jest myślenie w kategoriach abstrakcyjnych kroków testowych:

1. Analiza logiki biznesowej
   LLM analizuje user story i (jeśli dostarczono) dokumentację, aby zidentyfikować kluczowe stany i logiczne przejścia między nimi.
2. Projektowanie walidacji stanu
   LLM weryfikuje nie tylko to, że akcja jest możliwa (happy path), ale przede wszystkim, że nieprawidłowe akcje są blokowane w danym stanie (tzw. testy negatywne/brzegowe).

Strategia Testowania na Różnych Poziomach

Myślenie o stanach aplikacji w sposób architektoniczny naturalnie prowadzi do delegowania walidacji na najbardziej efektywny poziom. Chociaż Playwright jest znany z testów E2E/UI, LLM Architekt Testów powinien projektować testy, które:

• Potwierdzają testy jednostkowe/integracyjne
  LLM, analizując przejścia stanów, może wskazać scenariusze, które są najlepiej weryfikowane na niższych poziomach (np. walidacja danych wejściowych, proste zmiany statusu w warstwie usługowej).
• Wykorzystują asercje API (Playwright Request)
  W celu weryfikacji zmian stanu, LLM może projektować testy, które po akcji UI weryfikują status i ciało odpowiedzi sieciowej (tzw. end-to-end testing, często z asercjami API). Dzięki temu, walidacja stanu (np. Order Status: ‘Opłacone’) nie jest uzależniona wyłącznie od elementu UI, ale od pewnej odpowiedzi back-endu. Takie podejście zwiększa stabilność i szybkość, gdyż unika obciążania UI prostymi weryfikacjami statusu.

To strategiczne myślenie pozwala uniknąć nadmiernego polegania na wolnych i kruchych testach E2E, a zamiast tego wykorzystuje pełen potencjał Playwrighta – zarówno do interakcji z UI, jak i zapytań API.

Abstrakcja a Architektura Testów

Inteligencja LLM pozwala mu projektować testy na poziomie architektury kodu (wywołania metod z POMs), a nie tylko na poziomie interakcji użytkownika.
Poniższa tabela ilustruje, jak LLM konwertuje wymaganie testowe (Analiza Stanu) na abstrakcyjne wywołanie metody z Page Object Model (POM):

zamowienie.jestAktywne(anuluj)

zamowienie.probojAnulowac().spodziewajSieBlednejWalidacji('Za późno')

playwright.request.newContext())

Dzięki tej zdolności, LLM projektuje testy, które weryfikują prawidłowe przejścia i blokowanie nieprawidłowych akcji w danym stanie. Ten poziom abstrakcji i strategicznego myślenia o stanach aplikacji jest kluczowy dla zwiększenia kompletności pokrycia testami i minimalizacji krytycznych luk w walidacji domenowej.

Uzasadnienie Biznesowe: Modelowanie Stanów i Mierzenie Wartości (ROI)

Wdrożenie AI Architekta Testów to inwestycja, która uzasadnia się realnymi wskaźnikami zwrotu z inwestycji (ROI).

Modelowanie Stanów Aplikacji

LLM wykracza poza proste kliknięcia, pomagając w mapowaniu złożonych przejść między stanami (np. statusy zamówienia).

• Minimalizacja luk w walidacji domenowej
  LLM weryfikuje nie tylko to, że akcja jest możliwa (happy path), ale przede wszystkim, że nieprawidłowe akcje są blokowane w danym stanie (tzw. testy negatywne/brzegowe).
• Wzrost abstrakcji
  LLM potrafi projektować testy na poziomie architektonicznym (wywołania metod z POMs), co jest kluczowe dla znaczącego podniesienia kompletności pokrycia testami.

Kluczowe Metryki Wartości Dodanej (ROI)

Wpływ LLM na jakość i koszty można mierzyć za pomocą kluczowych wskaźników:

LLM pomaga zespołom mierzyć i osiągać to, co najważniejsze: wydajność, odporność i strategiczne pokrycie ryzyk.

Podsumowanie: Przyszłość Testowania jest Strategiczna

Integracja Dużych Modeli Językowych z frameworkami takimi jak Playwright przesuwa rolę senior testera. Przestajemy być osobami mechanicznie piszącymi kod, a stajemy się architektami i mentorami AI. Playwright dostarcza niezrównaną stabilność wykonania i wydajność, a LLM dodaje głębię intelektualną w projektowaniu scenariuszy i modelowaniu ryzyk biznesowych.
Ta synergia prowadzi do minimalizacji krytycznych luk w walidacji domenowej i do niespotykanej dotąd kompletności pokrycia testami. Przyszłość testowania jest strategiczna.

Zapowiedź: Beyond Codegen 2.0 — część praktyczna

W kolejnej części, Beyond Codegen 2.0: Dwustopniowa Architektura LLM i Playwrighta w Praktyce, przyjrzymy się architekturze dwuetapowej, praktycznym przykładom promptów i nauczymy się, jak wdrożyć Model Context Protocol (MCP), by zamienić tę wizję w gotowy do uruchomienia kod.

Link do zasobów zewnętrznych

• Playwright z AI – kurs o Playwright MCP
• Playwright – Praktyczne wprowadzenie do testów automatycznych
• Zbiór promptów, instrukcji i agentów – github.com/jaktestowac/awesome-copilot-for-testers

Emilia Krzemińska-Komenda QA Engineer, Ambasadorka jaktestowac.pl, profil na LinkedIn 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.