AI przejmuje kolejne czynności testera: generuje przypadki testowe, pisze kod automatyzacji, klika regresję szybciej niż człowiek. Odpowiedzialność za jakość zostaje przy tym bez właściciela, bo model nie stanie przed zarządem po awarii na produkcji i nie wytłumaczy klientom, czemu przelewy nie wyszły. Przez 20 lat w IT widziałem dwie zapowiedzi «końca testera» i obie skończyły się podobnie: czynności znikały, odpowiedzialność wracała w nowej formie. Tym razem przybiera postać architekta zabezpieczeń, człowieka od bramek jakościowych, evali i obserwowalności.
Które zadania testera AI już wykonuje?
Cztery widzę u klientów regularnie: generowanie przypadków testowych z wymagań, boilerplate automatyzacji, regresyjne klikanie i pierwszą analizę logów. Model dostaje user story i po minucie oddaje trzydzieści przypadków, w tym scenariusze brzegowe, o których zmęczony człowiek pod koniec sprintu by nie pomyślał. Połowa z nich nadaje się do kosza, bo dubluje inne albo sprawdza rzeczy bez znaczenia, ale selekcja zajmuje mniej czasu niż pisanie od zera. Szkielet testu Playwright z asercjami powstaje w czasie, w którym kiedyś otwierałem IDE.
Regresję opartą na klikaniu według skryptu też oddaję maszynie bez żalu. Narzędzia z samonaprawiającymi się selektorami przechodzą znane ścieżki i zgłaszają różnice, a po nocnym buildzie asystent grupuje błędy z logów i wskazuje podejrzany commit. Te cztery zadania wypełniały większość dnia testera jeszcze pięć lat temu, więc tester, który zarabia tylko na nich, ma powód do niepokoju.
Czego AI w QA nie robi?
Nie bierze odpowiedzialności za ryzyko wdrożenia. Gdy w piątek po południu ktoś musi zdecydować, czy wydanie wychodzi mimo dwóch otwartych błędów, model podsumuje dane, ale decyzji nie podpisze i konsekwencji nie poniesie. Firmy płacą inżynierowi jakości za tę decyzję, a nie za liczbę wykonanych przypadków.
Trzy kolejne braki powtarzają się we wdrożeniach, które oglądam. Model nie zaprojektuje strategii testów pod konkretny biznes, bo nie wie, że w tej firmie awaria płatności kosztuje więcej niż tydzień poślizgu wydania. Nie zauważy, że wymaganie jest bez sensu: do sprzecznej specyfikacji wygeneruje komplet eleganckich testów równie chętnie, jak do dobrej. Na koniec sama wymaga testowania, bo funkcje oparte na LLM odpowiadają niedeterministycznie i trzeba je mierzyć evalami, proces opisałem w tekście o tym, jak testować funkcje AI i LLM.
Czy to pierwsza taka «śmierć testera»?
Trzecia, licząc od czasów, gdy zaczynałem pracę. Pierwszą ogłosiły nagrywarki testów: sprzedawcy narzędzi klasy WinRunner i QTP obiecywali, że analityk nagra ścieżkę i testerzy przestaną być potrzebni. Skończyło się armią ludzi utrzymujących kruche skrypty, które sypały się po drobnych zmianach interfejsu. Budżet, który miał zniknąć razem z etatami, przeszedł na utrzymanie nagrań.
Drugą falę pamiętam z okolic 2015 roku, gdy branża powtarzała, że automatyzacja zastąpi testerów manualnych. Manualni nie zniknęli; część przeszła do automatyzacji, część do analizy wymagań, a zapotrzebowanie na ludzi rozumiejących ryzyko urosło. Prowadziłem też zmiany samych narzędzi automatyzacji (najświeższa: migracja z Selenium do Playwrighta) i schemat w obu falach wyglądał identycznie: narzędzie przejmowało czynność, a rola przesuwała się o poziom wyżej.
Jak zmienia się rola QA teraz?
Środek ciężkości przesuwa się z wykonywania testów na projektowanie zabezpieczeń wokół tego, co generują maszyny. Pierwszy front to walidacja kodu z asystentów: w analizie 470 pull requestów z grudnia 2025 kod współtworzony z AI miał około 1,7 raza więcej poważnych problemów niż kod pisany bez asystenta. Dane i guardraile rozpisałem w tekście o tym, czy kod z AI jest bezpieczny; tu wystarczy wniosek, że zespoły generują kod szybciej, niż potrafią go weryfikować.
Drugi front to funkcje oparte na LLM, które potrzebują evali i obserwowalności, bo klasyczna asercja «wynik równy oczekiwanemu» nie działa na niedeterministycznych odpowiedziach. Trzeci to bramki jakościowe w CI, które decydują, czy wygenerowany kod w ogóle trafia do gałęzi głównej. Inżynier jakości projektujący te mechanizmy siedzi po rosnącej stronie rynku, bo zapotrzebowanie na weryfikację rośnie razem z tempem generowania.
Co robić, jeśli pracujesz w QA?
Przenosić czas nauki tam, gdzie przybywa pracy: do weryfikacji tego, co produkują modele. Cztery kierunki mają dziś pokrycie w ogłoszeniach i stawkach, sam rozwijam wszystkie.
- Praca z asystentami kodu. Review diffów z Copilota czy Cursora to codzienność zespołów; tester, który ocenia wygenerowany test i wskazuje brakujące asercje, przydaje się od pierwszego dnia.
- Evale i obserwowalność LLM. Zbiory testowe dla promptów, mierzenie regresji jakości odpowiedzi, narzędzia typu Langfuse czy promptfoo. Specjalistów jest garstka, a funkcji AI w produktach przybywa co kwartał.
- CI/CD i bramki jakościowe. Pipeline blokujący merge przy regresji wykonuje pracę, którą dawniej robił etat testera regresyjnego; lepiej projektować tę bramkę, niż z nią konkurować.
- Metryki jakości. Defect rate sugestii asystenta, koszt incydentu, pokrycie krytycznych ścieżek. Rozmowa z biznesem na liczbach odróżnia architekta zabezpieczeń od wykonawcy przypadków.
Na pytanie z tytułu odpowiadam więc rozdzielnie. Czynności testera AI zastępuje już teraz i to tempo utrzyma. Zawód zostaje, bo za ryzyko wdrożenia dalej musi odpowiadać człowiek z nazwiskiem, a lista rzeczy do przetestowania urosła o same funkcje AI.
Jak pomagam w QA Sensei
Prowadzę QA Sensei i ustawiam z zespołami zabezpieczenia opisane wyżej: bramki jakościowe, evale, proces weryfikacji kodu z asystentów. Punktem startu jest Bilans Jakości, czyli przegląd projektu z planem wdrożenia; pracuję zdalnie w całej Polsce, w okolicach Wrocławia także u klienta.