Czy AI zastąpi testerów?
Prawdziwe pytanie brzmi inaczej, niż myślisz - i odpowiedź nie jest uspokajająca.
Trafiłem ostatnio na artykuł, który zadaje pytanie znane chyba każdemu w naszej branży: czy AI zastąpi testerów? Spodziewałem się kolejnego tekstu uspokajającego - "spokojnie, ludzie są bezpieczni, AI to tylko narzędzie". Teza poszła jednak zupełnie w inną stronę i właśnie dlatego chcę się nią z Tobą podzielić.
Autor nie twierdzi, że testerzy są bezpieczni. Twierdzi coś ostrzejszego: AI nie wprowadza nowych problemów do procesów testowych, tylko usuwa warstwę ludzką, która po cichu te problemy maskowała. Przez lata wiele zespołów żyło w przekonaniu, że ma stabilne procesy. W rzeczywistości te procesy były stabilne tylko dlatego, że tester robił to, czego proces nie przewidział - dopytywał o wymagania bez acceptance criteria, rerunował flaky testy z wyczuciem, pamiętał incydent sprzed dwóch lat i projektował pod niego scenariusz, którego nikt nigdzie nie zapisał. AI tego nie zrobi, bo nie ma do czego sięgnąć 😅
Dwa rodzaje niewidocznej pracy
Artykuł wprowadza podział, który uważam za naprawdę użyteczny do zrozumienia, co właściwie dzieje się w zespołach testerskich. Pierwszy rodzaj to realna ekspertyza: priorytyzacja ryzyka, rozumowanie przyczynowe, wiedza domenowa i pamięć incydentów produkcyjnych. Tester czyta wymaganie i pyta nie tylko "co tu jest", ale dlaczego to w ogóle istnieje, kto na tym polega i co się stanie, jak to padnie. Tej wiedzy nie znajdziesz w żadnej dokumentacji, bo powstaje latami pracy w konkretnym kontekście projektowym.
Drugi rodzaj to dług organizacyjny, który ludzie noszą po cichu: rerunowanie niestabilnych testów, ręczne przesiewanie failów w CI, domyślanie się acceptance criteria, które powinny były powstać jeszcze przed developmentem. To też jest niewidoczna praca, tylko że to nie jest ekspertyza - to koszt systemowych zaniedbań, które ktoś musiał gdzieś po drodze wchłonąć. Problem w tym, że AI odsłania oba rodzaje pracy jednocześnie, a organizacje zwykle reagują tylko na jeden z nich, ignorując drugi.
Warto się na chwilę zatrzymać przy tym rozróżnieniu, bo z mojego doświadczenia właśnie tutaj rodzi się największe nieporozumienie wokół AI w testowaniu. Zespół widzi, że narzędzie przyspiesza generowanie przypadków testowych, i zakłada, że problem "wolnego QA" został rozwiązany. Tymczasem przyspieszył się tylko dług organizacyjny - te wszystkie domyślania i łatanie procesu - a prawdziwa ekspertyza wciąż siedzi w głowie jednej osoby, której nikt nie zapytał, czy w ogóle chce, żeby tak zostało.
Czego AI nie może zrobić - i dlaczego to nie kwestia doszkolenia modelu
W artykule pada przykład, który dobrze pokazuje istotę problemu. Zespół wdraża narzędzie do generowania testów i w kilkadziesiąt sekund powstaje ponad sto przypadków testowych, a metryki pokrycia wyglądają obiecująco na pierwszy rzut oka. Potem senior tester patrzy na wygenerowany output i zauważa, że ani jeden test nie zakłada problemów z bramką płatności - timeoutu, częściowej odpowiedzi, błędu przy retry. Wie o tym nie z dokumentacji, bo dokumentacja o tym milczy, tylko dlatego, że pamięta incydent sprzed dwóch lat, kiedy cichy błąd bramki wywołał problem z zamówieniami trwający trzy dni.
AI nie ma dostępu do tej pamięci. Generuje testy z tego, co realnie ma pod ręką - z wymagań, kodu i historii wcześniejszych testów - a luka nie leżała w samym narzędziu, tylko w tym, czego to narzędzie z definicji nie mogło zobaczyć. Modele językowe optymalizują pod prawdopodobieństwo sensownej sekwencji tokenów (czyli fragmentów tekstu, na których model przewiduje kolejne słowo), a tester optymalizuje pod ryzyko. To są dwa fundamentalnie różne rodzaje rozumowania i większa ilość danych treningowych tej różnicy nie zniweluje.
Playwright Starter Pack - zacznij od gotowych fundamentów 🎯
Największy czas w automatyzacji nie ginie na pisanie testów, tylko na research - jaką strukturę projektu wybrać, jak ułożyć Page Object Model, żeby nie rozjechał się po trzech sprintach, i jak w ogóle zabrać się za Playwrighta z głową.
Playwright Starter Pack to konkretny punkt wyjścia: sprawdzona struktura projektu, przykładowe testy i checklista dobrych praktyk, które normalnie zbiera się metodą prób i błędów przez pierwsze miesiące pracy z narzędziem.
Ekspertyza w głowie testera to nie atut - to ryzyko organizacyjne
To chyba najtrudniejszy punkt artykułu do przyjęcia, bo uderza w coś, co przez lata było źródłem prestiżu w zespole. Bycie "osobą, która wie" dawało realną wartość i realną pozycję - i to jest w pełni uzasadnione, bo ta wiedza jest prawdziwa i ciężko zarobiona latami pracy przy konkretnym produkcie. Tylko że jeśli modele ryzyka istnieją wyłącznie w głowie jednej osoby, jeśli wiedza o incydentach nie jest zapisana nigdzie poza jej pamięcią, a strategia testów opisuje "co" testować bez "dlaczego" - to AI tej ekspertyzy nie wzmacnia. Ono odsłania jej brak w systemie.
Autor stawia to bardzo wprost: tester, który pochłania niejednoznaczność, podtrzymuje system w obecnym kształcie. Tester, który tę niejednoznaczność eliminuje - dokumentując modele ryzyka, kryteria akceptacji i wzorce dotychczasowych incydentów - faktycznie naprawia system. To subtelna, ale ważna różnica, bo pierwsza postawa czuje się jak bycie niezastąpionym, a druga jak oddawanie władzy. W praktyce to jednak ta druga postawa buduje odporny zespół, który nie sypie się w momencie, gdy jedna osoba idzie na urlop albo zmienia pracę.
Co to znaczy w praktyce
Niekoniecznie chodzi tu o uruchamianie wielkich projektów dokumentacyjnych, bo takie inicjatywy zwykle umierają po dwóch tygodniach entuzjazmu. Chodzi raczej o konkretne pytania, które warto sobie zadawać przy codziennej pracy. Dlaczego testuję akurat to - czy powód jest gdzieś zapisany, czy istnieje tylko w mojej głowie? Co wiem o tym systemie, czego nie ma w żadnym wymaganiu ani w żadnym tickecie? Gdzie w ostatnim tygodniu musiałem(-am) czegoś się domyślić zamiast to po prostu przeczytać?
Każde miejsce, w którym narzędzie AI potknęło się w Twoim codziennym workflow, jest właściwie dokładnym wskaźnikiem tego, gdzie organizacja polegała na wiedzy pojedynczej osoby zamiast zbudować system, który tę wiedzę realnie przechowuje. To dobra wiadomość i zła wiadomość jednocześnie. Zła, bo pokazuje, ile luk faktycznie istnieje pod powierzchnią pozornie stabilnych procesów. Dobra, bo te luki są konkretne i da się je zamykać jedna po drugiej, zamiast czekać na cud w postaci kolejnej wersji modelu.
Wracając więc do pytania z tytułu - AI raczej nie zastąpi testerów, którzy rozumieją ryzyko, pamiętają kontekst i potrafią go przekuć w decyzję. Zastąpi za to tych, którzy przez lata funkcjonowali głównie jako żywa dokumentacja - i szczerze mówiąc, to nigdy nie była rola, w której warto było zostać na dłużej.
Przestań składać wiedzę o Playwright + AI z przypadkowych źródeł 🤖
Można uczyć się metodą "obejrzę dziesięć różnych tutoriali i sam poskładam całość", tylko że w praktyce zajmuje to tygodnie, a i tak zostają dziury - zwłaszcza tam, gdzie AI zaczyna generować kod, którego nie rozumiesz.
Mini-kurs Playwright + AI prowadzi Cię krok po kroku: od fundamentów frameworka, przez świadome korzystanie z AI przy pisaniu testów, po budowę stabilnego, skalowalnego projektu automatyzacji.
Polecane wpisy:
Sprawdź też moje social media:
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
Kontakt
kontakt@rwasik.pl