Testowanie oprogramowania z AI polega na wykorzystaniu modeli językowych i agentów do pisania, uruchamiania i analizowania testów – od testów jednostkowych, przez scenariusze E2E w Playwright, po automatyczny przegląd kodu – a także na testowaniu samych funkcji AI w aplikacji za pomocą ewaluacji i testów bezpieczeństwa. AI wyraźnie przyspiesza automatyzację testów, ale nie zwalnia zespołu z decyzji, co i dlaczego testować. Źle użyta potrafi wyprodukować setki testów, które przechodzą, a niczego istotnego nie sprawdzają.
W tym artykule omawiamy, jak AI pomaga w poszczególnych rodzajach testów, jak testować aplikacje, które same korzystają z modeli językowych, i których elementów procesu testowania nie warto oddawać maszynie.
Testowanie oprogramowania a AI – dwa różne tematy
Pod hasłem „testowanie z AI” kryją się dwie sprawy, które warto rozdzielić:
- AI jako narzędzie testera i programisty – generowanie testów jednostkowych i E2E, analiza błędów, przegląd kodu, przygotowanie danych testowych. Dotyczy każdej aplikacji, także takiej, która nie ma żadnych funkcji AI.
- Testowanie funkcji AI w aplikacji – sprawdzanie, czy czatbot, asystent czy agent odpowiada poprawnie, nie zmyśla, nie ujawnia danych i nie daje się zmanipulować. Wymaga innych metod niż klasyczne testy, bo wynik modelu nie jest w pełni deterministyczny.
Najpierw zajmiemy się pierwszym obszarem, potem drugim.
Testy jednostkowe generowane przez AI
Testy jednostkowe to obszar, w którym AI daje najszybszy efekt. Agent, np. Claude Code, potrafi przeczytać funkcję lub klasę, zrozumieć jej działanie, wygenerować zestaw testów, uruchomić je i poprawić te, które nie przechodzą z powodów technicznych. Szczególnie przydaje się to w starszym kodzie, który nie ma testów, a trzeba go zmienić.
Na co uważać
- Testy utrwalające błędy. AI pisze testy na podstawie tego, jak kod działa, a nie jak powinien działać. Jeśli funkcja liczy rabat źle, test często „potwierdzi” zły wynik. Dlatego warto podawać agentowi wymagania lub przykłady oczekiwanych wyników, a nie tylko kod.
- Testy tautologiczne. Test, który sprawdza, czy zamockowana funkcja zwraca to, co zwraca mock, zwiększa pokrycie kodu, ale nie zwiększa bezpieczeństwa.
- Nadmiar mocków. Zastąpienie wszystkich zależności atrapami sprawia, że test przestaje sprawdzać realne zachowanie.
- Pokrycie jako cel. Wysoki procent pokrycia wygenerowany przez AI łatwo osiągnąć i łatwo przecenić. Lepszą miarą jest to, czy testy wykrywają celowo wprowadzone błędy – tę technikę nazywa się testowaniem mutacyjnym.
Dobra praktyka: najpierw człowiek opisuje przypadki do sprawdzenia (w tym brzegowe i błędne dane), potem AI pisze testy, a na końcu programista przegląda je tak samo uważnie jak kod produkcyjny.
Testy E2E w Playwright z pomocą AI
Playwright to otwartoźródłowy framework do automatyzacji testów end-to-end aplikacji webowych, rozwijany przez Microsoft. Pozwala sterować przeglądarkami opartymi na silnikach Chromium, Firefox i WebKit, uruchamiać testy równolegle i w CI, a w razie błędu analizować przebieg testu w narzędziu Trace Viewer (zrzuty ekranu, zapytania sieciowe, kolejne kroki). Ma wbudowane automatyczne oczekiwanie na elementy, co ogranicza problem niestabilnych testów, oraz generator testów nagrywający akcje użytkownika.
Jak AI pomaga w Playwright
- Scenariusze z opisu. Opisujesz ścieżkę użytkownika („zarejestruj konto, potwierdź e-mail, dodaj produkt do koszyka, zapłać testową kartą”), a agent pisze test w Playwright, uruchamia go i poprawia.
- Agent w prawdziwej przeglądarce. Dzięki serwerowi Playwright MCP agent AI może sam otworzyć aplikację, klikać, wypełniać formularze i sprawdzać efekt – a potem zapisać przebieg jako stały test. O protokole piszemy w artykule MCP – Model Context Protocol.
- Analiza błędów. Agent czyta raport i ślad testu, ustala, czy zawiódł test, czy aplikacja, i proponuje poprawkę.
- Utrzymanie testów. Po zmianie interfejsu AI aktualizuje selektory i kroki w wielu testach naraz.
- Lepsze lokatory. Agent może przepisać kruche selektory CSS na lokatory oparte na rolach i etykietach (np. przycisk o danej nazwie), które są odporniejsze na zmiany wyglądu i przy okazji sprzyjają dostępności.
Pułapki testów E2E pisanych przez AI
Agent, który ma „sprawić, żeby test przechodził”, potrafi osłabić asercję, dodać sztywne oczekiwanie albo pominąć krok, który zawodzi. Każda zmiana w testach powinna więc przechodzić przegląd z pytaniem: czy test nadal sprawdza to, co miał sprawdzać? Testy E2E są też droższe w utrzymaniu niż jednostkowe – warto ograniczyć je do kluczowych ścieżek biznesowych, a resztę pokryć testami niższego poziomu.
AI code review – automatyczny przegląd kodu
Narzędzia do AI code review analizują zmiany w pull requeście i zostawiają komentarze: potencjalne błędy, brakującą obsługę wyjątków, niespójności, problemy z czytelnością, a czasem luki bezpieczeństwa. Taką funkcję oferują m.in. GitHub Copilot, a agentów takich jak Claude Code czy Codex można uruchamiać w procesie CI, by przeglądali zmiany według ustalonych zasad.
Gdzie AI code review sprawdza się dobrze:
- szybka pierwsza runda uwag, zanim zmiana trafi do człowieka,
- wychwytywanie typowych błędów i przeoczeń (null, brak walidacji, literówki w nazwach),
- pilnowanie konwencji zespołu opisanych w instrukcjach,
- streszczenie dużego pull requesta dla recenzenta.
Gdzie zawodzi:
- ocena, czy zmiana jest zgodna z wymaganiami biznesowymi,
- decyzje architektoniczne i ich długofalowe skutki,
- błędy wynikające z kontekstu spoza zmienianych plików,
- nadmiar komentarzy – zbyt wiele drobnych uwag usypia czujność recenzentów.
AI code review to dodatek, nie zamiennik. W 4B Systems każdą zmianę – również tę przygotowaną przez agenta AI – przegląda programista.
Automatyzacja testów z AI – gdzie jeszcze pomaga
| Obszar | Co AI robi dobrze | Na co uważać |
|---|---|---|
| Testy jednostkowe | Szybkie generowanie, testy do starego kodu | Utrwalanie błędów, testy tautologiczne |
| Testy integracyjne | Scenariusze dla API, przypadki błędów | Testy zależne od kolejności i stanu bazy |
| E2E (Playwright) | Scenariusze z opisu, aktualizacja selektorów, analiza śladów | Osłabianie asercji, niestabilność, koszt utrzymania |
| Dane testowe | Realistyczne, różnorodne dane syntetyczne | Nie używać prawdziwych danych osobowych |
| Analiza błędów | Czytanie logów, stack trace, odtwarzanie problemu | Pewne siebie, ale błędne diagnozy |
| Code review | Pierwsza runda uwag, konwencje, streszczenia | Brak kontekstu biznesowego, nadmiar komentarzy |
| Dokumentacja testów | Opisy scenariuszy, plany testów z wymagań | Weryfikacja kompletności przez człowieka |
Testowanie aplikacji z funkcjami AI
Gdy aplikacja sama korzysta z modelu językowego – jako czatbot, asystent, wyszukiwarka wiedzy czy agent – klasyczne testy nie wystarczą. Ten sam prompt może dać różne odpowiedzi, a „poprawna” odpowiedź często nie jest jednym konkretnym tekstem. Potrzebne są trzy dodatkowe rodzaje testów.
Ewaluacje (evals)
Ewaluacja to zestaw przypadków testowych – pytań, dokumentów, zadań – wraz z kryteriami oceny odpowiedzi. Kryteria mogą być proste (czy odpowiedź zawiera właściwą kwotę, czy ma wymagany format JSON) albo opisowe (czy odpowiedź jest zgodna z polityką zwrotów, czy ton jest właściwy). Część ocen wykonuje kod, część inny model oceniający według ustalonych zasad (tzw. LLM-as-a-judge), a część – na próbce – człowiek. Ewaluacje uruchamia się przy każdej zmianie promptu, modelu, danych lub konfiguracji RAG, żeby wychwycić regresję jakości. Zestaw warto stale uzupełniać o przypadki, w których aplikacja zawiodła u prawdziwych użytkowników.
Halucynacje
Halucynacja to odpowiedź, która brzmi wiarygodnie, ale jest nieprawdziwa lub nie wynika ze źródeł. W aplikacjach z RAG testuje się m.in.:
- czy odpowiedź opiera się wyłącznie na dostarczonych dokumentach,
- czy wskazane źródła rzeczywiście zawierają podaną informację,
- czy model przyznaje, że nie wie, gdy w dokumentach nie ma odpowiedzi,
- jak zachowuje się przy pytaniach podchwytliwych i spoza zakresu.
Prompt injection i bezpieczeństwo
Prompt injection to próba zmuszenia modelu do zignorowania instrukcji – bezpośrednio („zapomnij poprzednie polecenia i…”) albo pośrednio, przez treści, które model czyta: dokument, e-mail, stronę internetową z ukrytymi instrukcjami. To jedno z głównych zagrożeń wymienianych w zestawieniu OWASP Top 10 dla aplikacji LLM. Testy powinny sprawdzać m.in., czy aplikacja:
- nie ujawnia instrukcji systemowych ani danych innych użytkowników,
- respektuje uprawnienia użytkownika również wtedy, gdy model zostanie zmanipulowany,
- nie wykonuje działań (np. wysłania e-maila, zmiany danych) bez potwierdzenia, gdy wymaga tego proces,
- bezpiecznie obsługuje treści generowane przez model, np. nie wstawia ich do strony bez escapowania.
Najważniejsza zasada: zabezpieczenia nie mogą opierać się wyłącznie na instrukcji dla modelu. Uprawnienia, walidacja i potwierdzenia muszą działać w kodzie aplikacji. Szerzej o projektowaniu takich aplikacji piszemy w artykule jak stworzyć aplikację AI.
Czego nie oddawać AI w testowaniu
AI może wykonać dużą część pracy przy automatyzacji testów, ale kilka elementów powinno zostać po stronie ludzi:
- Decyzja, co testować. Wybór krytycznych ścieżek, ryzyk biznesowych i priorytetów wymaga znajomości produktu i klientów.
- Kryteria akceptacji. To człowiek określa, jak system ma się zachowywać. AI może pomóc je spisać, ale nie powinno ich wymyślać.
- Przegląd testów. Testy napisane przez AI czyta się tak samo uważnie jak kod produkcyjny – zwłaszcza zmiany, które „naprawiają” nieprzechodzący test.
- Testy bezpieczeństwa. AI wspiera wyszukiwanie podatności, ale ostateczna ocena i testy penetracyjne wymagają specjalistów.
- Testy eksploracyjne i UX. Wyczucie, że coś jest mylące lub irytujące dla użytkownika, to wciąż domena ludzi.
- Dane produkcyjne. Agent nie powinien mieć dostępu do produkcji ani prawdziwych danych osobowych – testy działają na środowiskach testowych i danych syntetycznych.
- Decyzja o wydaniu. Zielony pipeline to warunek konieczny, ale decyzję o wdrożeniu podejmuje zespół.
Jak testujemy aplikacje w 4B Systems
W projektach aplikacji webowych i mobilnych łączymy klasyczne praktyki z narzędziami AI: agenci pomagają pisać testy jednostkowe i scenariusze E2E w Playwright, analizują błędy i przygotowują pierwszą rundę uwag w code review, a programiści decydują o zakresie testów i przeglądają każdą zmianę. W aplikacjach z funkcjami AI budujemy zestawy ewaluacyjne i testy odporności na prompt injection jeszcze przed wdrożeniem. Więcej o naszym podejściu przeczytasz na stronie aplikacje AI i programowanie z AI.
Podsumowanie
AI realnie przyspiesza testowanie oprogramowania: generuje testy jednostkowe, pisze i utrzymuje scenariusze E2E w Playwright, analizuje błędy i wspiera code review. Wymaga jednak kontroli – testy pisane przez AI potrafią utrwalać błędy lub niczego nie sprawdzać. Aplikacje z funkcjami AI trzeba dodatkowo testować ewaluacjami, pod kątem halucynacji i prompt injection. Decyzje o tym, co testować, kryteria akceptacji, bezpieczeństwo i wydanie wersji pozostają po stronie ludzi.
Potrzebujesz aplikacji, która jest nie tylko szybko zbudowana, ale też porządnie przetestowana? 4B Systems tworzy aplikacje z udziałem AI, z testami automatycznymi w Playwright, ewaluacjami funkcji AI i przeglądem każdej zmiany przez programistę. Sprawdź naszą ofertę programowania z AI i testów automatycznych i opisz projekt – wycenę przygotujemy w 48 godzin.
Najczęściej zadawane pytania
Czy AI może napisać testy automatyczne za programistę?
AI może napisać dużą część testów, zwłaszcza jednostkowych i scenariuszy E2E, oraz je uruchomić i poprawić. Programista powinien jednak określić, co testować, i przejrzeć wygenerowane testy, bo AI potrafi utrwalić błędne zachowanie kodu lub pisać testy, które niczego istotnego nie sprawdzają.
Co to jest Playwright?
Playwright to otwartoźródłowy framework do testów end-to-end aplikacji webowych, rozwijany przez Microsoft. Steruje przeglądarkami opartymi na Chromium, Firefox i WebKit, automatycznie czeka na elementy strony i pozwala analizować przebieg testów w Trace Viewer.
Czy AI code review zastępuje przegląd kodu przez człowieka?
Nie. AI dobrze sprawdza się jako pierwsza runda uwag i w wychwytywaniu typowych błędów, ale nie ocenia zgodności z wymaganiami biznesowymi ani decyzji architektonicznych. Zmianę powinien zatwierdzić programista.
Jak testować czatbota lub asystenta AI?
Poza klasycznymi testami potrzebne są ewaluacje, czyli zestaw pytań z kryteriami oceny odpowiedzi, uruchamiany przy każdej zmianie promptu, modelu lub danych. Do tego dochodzą testy halucynacji, zachowania przy pytaniach spoza zakresu oraz odporności na prompt injection.
Co to jest prompt injection?
To próba zmuszenia modelu do zignorowania instrukcji, bezpośrednio w wiadomości użytkownika albo pośrednio przez treść dokumentu, e-maila lub strony, którą model czyta. Ochrona wymaga zabezpieczeń w kodzie aplikacji – uprawnień, walidacji i potwierdzeń – a nie tylko instrukcji dla modelu.
Czy przy testach z AI można używać danych produkcyjnych?
Nie powinno się tego robić. Testy powinny działać na środowiskach testowych i danych syntetycznych, a agenci AI nie powinni mieć dostępu do produkcji ani prawdziwych danych osobowych, także ze względu na RODO.