Setki testów, zero sensu - pułapka AI w Playwrightcie

Mam wrażenie, że połowa osób, które mówią o AI w Playwrighcie, nigdy nie musiała potem takiego testu utrzymać przez pół roku. Bo wygenerować test - to jest łatwe, AI ogarnie to w dziesięć sekund i doda nawet ładne asercje. Pytanie, które rzadko pada w tych entuzjastycznych postach, brzmi inaczej: co te testy w ogóle sprawdzają i czy ktokolwiek to zweryfikował, zanim pipeline zaświecił się na zielono.

Widziałem to w kilku projektach z rzędu. Ktoś podłącza AI do generowania testów pod Playwrighta, dashboard pokrywa się zielonymi checkami, liczba testów rośnie z tygodnia na tydzień. Wygląda to świetnie na retrospektywie. Kilka tygodni później okazuje się, że regresja i tak przeszła bokiem, bo krytyczna ścieżka płatności nigdy nie trafiła do zestawu testów - AI napisało to, co było oczywiste, nie to, co było ryzykowne.

Łatwo mieć setki testów, które nic nie znaczą

AI wygeneruje Ci dużo testów i zrobi to szybko - to nie jest przesada, tylko codzienność w projektach, które już z tego korzystają. Problem pojawia się wtedy, gdy nie powiesz mu, co jest ryzykowne w Twoim konkretnym produkcie. Bez tej informacji dostajesz pokrycie na papierze: happy path (czyli scenariusz, w którym wszystko idzie zgodnie z planem, bez błędów i wyjątków) zaliczony, formularz wypełniony poprawnymi danymi przetestowany, a edge case'y - czyli przypadki brzegowe, sytuacje na granicy działania systemu - zostają pominięte.

Liczba testów w repozytorium to metryka, która świetnie wygląda w raporcie dla managera i kompletnie nic nie mówi o jakości produktu. Widziałem projekty ze trzystoma testami e2e, gdzie żaden nie sprawdzał, co się dzieje, gdy API zwróci błąd 500 w trakcie procesu checkout. AI nie zapytało o to samo z siebie, bo nie miało powodu - nikt mu nie powiedział, że akurat ten endpoint bywa niestabilny pod obciążeniem.

Efekt jest taki, że pipeline świeci się na zielono, a produkcja i tak dostaje zgłoszenia od użytkowników na te same błędy co przed wdrożeniem automatyzacji. Zespół ma wtedy fałszywe poczucie bezpieczeństwa, które jest gorsze niż brak testów w ogóle - bo brak testów przynajmniej nikogo nie usypia.

AI nie czuje ryzyka

AI nie wie, że ten jeden endpoint nie do końca działa tak, jak w dokumentacji, bo nikt nie zaktualizował dokumentacji od dwóch sprintów. Nie wie, że ta konkretna ścieżka pada co drugi release, bo to wiedza, która siedzi w głowach ludzi z zespołu, nie w kodzie ani w opisie zadania w Jirze. AI działa na tym, co mu podasz - a jeśli podasz mu tylko nazwę funkcjonalności, dostaniesz test sprawdzający to, co oczywiste.

To Ty musisz wiedzieć, które ścieżki są krytyczne biznesowo, i to napisać - albo powiedzieć, jeśli wolisz dyktować prompty zamiast je pisać. Ryzyko nie bierze się z powietrza. Bierze się z wiedzy domenowej: z tego, że wiesz, iż płatności kartą mają wyższy priorytet niż zmiana avatara w profilu, albo że integracja z zewnętrznym dostawcą logistycznym pada zawsze wtedy, gdy ktoś zmieni coś w ich API bez uprzedzenia.

W praktyce oznacza to, że przed napisaniem promptu warto usiąść i wypisać sobie, co faktycznie boli ten produkt. Jakie bug wracają najczęściej, które moduły mają najwyższy koszt awarii, gdzie w ostatnich trzech miesiącach był hotfix na produkcji. Dopiero z tą listą w ręku prompt do AI ma sens, bo mówisz mu nie "napisz test logowania", tylko "napisz test logowania z uwzględnieniem sytuacji, gdy token sesji wygasa w trakcie wypełniania formularza" - bo wiesz, że to się już zdarzyło.

Wynik AI jest tak dobry, jak prompt

Dobry test z AI zaczyna się od tego, że rozumiesz, co chcesz sprawdzić - nie od frameworka, nie od modelu, którego akurat używasz. Zaczyna się od myślenia o konkretnych przypadkach testowych, zanim jeszcze otworzysz okno czatu. To dokładnie ta sama kompetencja, która była potrzebna do pisania dobrych testów manualnie, tylko teraz przekłada się na jakość promptu zamiast na jakość ręcznie klikanego scenariusza.

Widziałem to zestawienie wielokrotnie: dwie osoby z tym samym dostępem do tego samego modelu AI, ten sam framework, ten sam produkt - i kompletnie różna jakość wygenerowanych testów. Różnica nie leżała w narzędziu. Leżała w tym, że jedna osoba wiedziała, jakie pytania zadać, a druga wkleiła nazwę funkcjonalności i czekała na cud.

Prompt "napisz testy dla formularza rejestracji" da Ci baseline, czyli podstawowy zestaw sprawdzający pola i przycisk submit. Prompt, który zawiera informację o tym, że walidacja emaila była trzy razy zgłaszana jako bug, że hasło ma limit znaków, którego frontend nie waliduje tak samo jak backend, i że rejestracja przez social login ma osobną, mniej stabilną ścieżkę - da Ci zestaw testów, który faktycznie coś chroni. To ta sama praca myślowa co dawniej, tylko przeniesiona na wcześniejszy etap.

Playwright + AI jako mnożnik, nie zamiennik

Dążę do jednego przekonania w tym temacie: Playwright + AI to mnożnik umiejętności, nie ich zamiennik. Osoba, która rozumie ryzyko, architekturę testów i specyfikę swojego produktu, dostanie od AI dziesięciokrotne przyspieszenie pracy. Osoba, która tej wiedzy nie ma, dostanie dziesięciokrotnie szybszą produkcję testów, które nic nie chronią - co jest gorsze niż wolniejsza produkcja testów wartościowych.

To rozróżnienie ma znaczenie praktyczne, nie tylko filozoficzne. Jeśli planujesz wdrożyć AI do generowania testów w swoim zespole, pierwszym krokiem nie jest wybór modelu ani konfiguracja promptów. Pierwszym krokiem jest rozmowa o tym, co w produkcie jest ryzykowne i spisanie tej wiedzy w miejscu, do którego AI - i nowi ludzie w zespole - będą mieli dostęp. Dopiero na tym fundamencie prompt zaczyna działać tak, jak obiecują posty o "AI w automatyzacji" na LinkedInie.

Polecane wpisy:

Sprawdź też moje social media:

Kontakt

kontakt@rwasik.pl

Znajdziesz mnie też tu

Newsletter