Jeszcze kilka lat temu wykorzystanie sztucznej inteligencji w testowaniu oprogramowania kojarzyło się głównie z prezentacjami na konferencjach. Dużo mówiło się o przyszłości, autonomicznych testach i systemach, które same wykrywają błędy, ale w codziennej pracy testera niewiele z tego wynikało.

Dzisiaj sytuacja wygląda zupełnie inaczej.

AI może pomóc przeanalizować wymagania, przygotować przypadki testowe, wygenerować dane, napisać zapytanie SQL, stworzyć test automatyczny albo znaleźć przyczynę błędu w logach. Pojawiły się też narzędzia, które potrafią wykonywać polecenia w repozytorium, zmieniać kod, uruchamiać testy i przygotowywać poprawki.

Nie oznacza to jednak, że każde narzędzie z dopiskiem „AI” jest warte naszego czasu.

Na rynku pojawiło się mnóstwo rozwiązań, które świetnie wyglądają na stronie producenta, ale w rzeczywistym projekcie niekoniecznie rozwiązują jakikolwiek problem. Dlatego nie chcę tworzyć kolejnej listy przypadkowych chatbotów. Wybrałem narzędzia, które tester może wykorzystać w konkretnych sytuacjach.

Część z nich jest przeznaczona bezpośrednio do testowania. Inne powstały głównie z myślą o programistach, ale w rękach testera automatyzującego mogą być równie przydatne.

Nie traktowałbym też tej listy jako rankingu. ChatGPT i Applitools rozwiązują zupełnie inne problemy, więc porównywanie ich na zasadzie „które jest lepsze” nie miałoby większego sensu.

1. ChatGPT

Zacznę od najbardziej oczywistego narzędzia, czyli ChatGPT.

Można powiedzieć, że wszyscy już go znają, ale nie wszyscy potrafią dobrze wykorzystać go w testowaniu. Wiele osób wpisuje jedno zdanie w stylu:

Przygotuj przypadki testowe dla logowania.

Później otrzymują kilka bardzo ogólnych scenariuszy i dochodzą do wniosku, że AI nie jest aż tak przydatne.

Problem najczęściej nie leży po stronie narzędzia, tylko w ilości przekazanego kontekstu.

Jeżeli opiszę mechanizm logowania, dostępne role użytkowników, sposób blokowania konta, wymagania dotyczące hasła i kryteria akceptacji, otrzymam znacznie lepszy rezultat. ChatGPT może wtedy wskazać nie tylko podstawowe przypadki pozytywne i negatywne, ale również brakujące wymagania albo sytuacje, o których wcześniej nie pomyśleliśmy.

W pracy testera można wykorzystać go między innymi do:

• analizowania wymagań,
• przygotowywania przypadków testowych,
• znajdowania przypadków brzegowych,
• generowania danych testowych,
• tworzenia checklist,
• przygotowywania zapytań SQL,
• wyjaśniania fragmentów kodu,
• analizowania logów,
• tworzenia skryptów w Postmanie,
• pisania testów automatycznych,
• przygotowywania raportów i podsumowań.

Przykładowy prompt może wyglądać tak:

Przeanalizuj poniższe wymagania dotyczące formularza rejestracji. Wskaż informacje, których brakuje lub które są niejednoznaczne. Następnie przygotuj przypadki pozytywne, negatywne i brzegowe. Dla każdego przypadku podaj dane, kroki oraz oczekiwany rezultat.

To jest znacznie lepszy punkt wyjścia niż prośba o wygenerowanie „10 test case’ów”.

ChatGPT przydaje się także podczas pracy z plikami. Można przesłać raport, dane zapisane w CSV albo dokumentację i poprosić o znalezienie określonych zależności. Oczywiście wcześniej trzeba upewnić się, że nie przekazujemy poufnych danych projektowych do narzędzia, którego firma nie zaakceptowała.

Czy ChatGPT zastąpi testera? Nie.

Może wygenerować bardzo przekonująco wyglądający przypadek testowy, który nie ma żadnej wartości biznesowej. Może również zaproponować nieistniejącą funkcję albo pomylić składnię biblioteki. Jego odpowiedzi trzeba traktować jako propozycje, a nie gotową prawdę.

Dla kogo? Dla praktycznie każdego testera, niezależnie od tego, czy zajmuje się testami manualnymi, automatyzacją, API czy analizą wymagań.

2. GitHub Copilot

GitHub Copilot kojarzy się przede wszystkim z programistami, ale tester automatyzujący również może wyciągnąć z niego bardzo dużo.

Najbardziej podstawowa funkcja to podpowiadanie kolejnych fragmentów kodu. Zaczynam pisać test albo komentarz opisujący, co chcę sprawdzić, a Copilot proponuje dalszą implementację.

Przykładowo:

// Sprawdź, czy po trzech nieudanych próbach logowania
// konto użytkownika zostaje tymczasowo zablokowane.

Na podstawie takiego komentarza, istniejącego kodu i struktury projektu Copilot może zaproponować szkielet testu.

Nie chodzi jednak wyłącznie o szybsze wpisywanie kolejnych linii. Copilot może pomagać w:

• tworzeniu testów Playwright, Cypress czy WebdriverIO,
• generowaniu asercji,
• przygotowywaniu obiektów Page Object,
• refaktoryzacji powtarzającego się kodu,
• wyjaśnianiu istniejących testów,
• wyszukiwaniu potencjalnych błędów,
• przygotowywaniu danych testowych,
• tworzeniu konfiguracji projektu,
• przeglądaniu zmian w kodzie.

Przegląd kodu jest szczególnie ciekawy z punktu widzenia QA. Copilot może przeanalizować zmiany i zwrócić uwagę na miejsca, które warto jeszcze sprawdzić. Nie zastępuje to code review wykonanego przez człowieka, ale może być dodatkowym filtrem.

Samą propozycję kodu zawsze trzeba przejrzeć. Copilot bardzo często dopasowuje się do tego, co już znajduje się w projekcie. Jeżeli mamy dobrze zorganizowane repozytorium, może zachować stosowane konwencje. Jeżeli w projekcie panuje chaos, AI może ten chaos po prostu kontynuować.

Trzeba również pamiętać, że poprawny technicznie test nie zawsze jest dobrym testem. Kod może się uruchamiać, wszystkie asercje mogą przechodzić, a mimo to scenariusz nie będzie sprawdzał najważniejszej reguły biznesowej.

Dla kogo? Przede wszystkim dla testerów automatyzujących, którzy regularnie pracują z kodem i GitHubem.

3. Claude Code

Claude Code idzie o krok dalej niż klasyczny chatbot pomagający napisać pojedynczą funkcję.

To agent, który może przeanalizować repozytorium, czytać pliki, wprowadzać zmiany i uruchamiać polecenia. Zamiast kopiować jeden test do okna czatu, możemy poprosić go o wykonanie większego zadania obejmującego kilka lub kilkanaście plików.

Przykładowe polecenie:

Przeanalizuj testy procesu zakupowego. Sprawdź, jakie scenariusze są już pokryte, wskaż brakujące przypadki i przygotuj test płatności zakończonej niepowodzeniem. Zachowaj istniejącą strukturę projektu i nie wprowadzaj zmian przed przedstawieniem planu.

Claude Code może znaleźć odpowiednie pliki, przeczytać istniejące testy, przeanalizować stosowane fixture’y i przygotować rozwiązanie dopasowane do projektu.

Może być przydatny podczas:

• rozbudowy frameworka testowego,
• analizowania dużego repozytorium,
• wyszukiwania brakujących testów,
• naprawiania niedziałających scenariuszy,
• refaktoryzacji kodu,
• migracji pomiędzy bibliotekami,
• przygotowywania konfiguracji,
• uruchamiania testów i analizowania ich wyników.

To bardzo wygodne, ale jednocześnie wymaga większej ostrożności. Jeżeli dajemy agentowi możliwość zmiany wielu plików, powinniśmy dokładnie sprawdzić, co rzeczywiście zrobił.

Najlepiej najpierw poprosić o analizę i plan, a dopiero później pozwolić na implementację. Po zakończeniu pracy trzeba przejrzeć różnice w kodzie i samodzielnie uruchomić testy.

Nie polecałbym przekazywania agentowi bardzo ogólnego polecenia:

Popraw moje testy.

Lepiej dokładnie określić cel, zakres zmian i warunki, po których poznamy, że zadanie zostało wykonane prawidłowo.

Dla kogo? Dla testerów automatyzujących, którzy pracują z większymi repozytoriami i potrafią samodzielnie ocenić wygenerowane zmiany.

4. Gemini Code Assist i Gemini CLI

Gemini Code Assist może pomagać bezpośrednio w edytorze kodu, natomiast Gemini CLI pozwala pracować z agentem z poziomu terminala.

W praktyce możemy wykorzystać te narzędzia podobnie jak Copilota albo Claude Code: do generowania kodu, analizowania projektu, naprawiania błędów i wykonywania bardziej złożonych zadań.

Tester może poprosić Gemini na przykład o:

Przeanalizuj projekt Cypress. Znajdź powtarzające się fragmenty kodu i zaproponuj sposób przeniesienia ich do wspólnych komend. Najpierw przedstaw plan i listę plików, które chcesz zmienić.

Gemini może pomóc również w:

• tworzeniu testów automatycznych,
• generowaniu skryptów Bash,
• przygotowywaniu konfiguracji GitHub Actions,
• analizowaniu błędów kompilacji,
• zwiększaniu pokrycia testowego,
• pisaniu zapytań SQL,
• generowaniu danych testowych,
• wyjaśnianiu kodu,
• pracy z narzędziami wykorzystującymi MCP.

Gemini CLI jest szczególnie interesujące dla osób, które często pracują z terminalem. Zamiast przełączać się pomiędzy przeglądarką, edytorem i konsolą, można zlecić część pracy bezpośrednio z wiersza poleceń.

Czy jest to narzędzie wyłącznie dla testerów? Nie. Podobnie jak Copilot czy Claude Code zostało stworzone głównie do pracy z oprogramowaniem. Tester automatyzujący wykonuje jednak wiele podobnych czynności jak programista, więc podział na „narzędzia dla developerów” i „narzędzia dla testerów” coraz częściej traci sens.

Dla kogo? Dla testerów automatyzujących, którzy pracują w IDE, terminalu albo środowisku Google Cloud.

5. Cursor

Cursor to edytor kodu zbudowany wokół funkcji AI.

Na pierwszy rzut oka przypomina klasyczne środowisko programistyczne, ale jego najważniejszym elementem jest agent, który potrafi analizować repozytorium, planować zmiany i modyfikować wiele plików.

Tester może wykorzystać Cursor do przygotowania nowego scenariusza zgodnego ze strukturą istniejącego frameworka.

Przykładowo:

Na podstawie obecnych testów logowania przygotuj testy resetowania hasła. Wykorzystaj istniejący Page Object Model, fixture’y i sposób nazywania testów. Nie twórz nowych rozwiązań, jeżeli odpowiedni mechanizm już znajduje się w projekcie.

To ostatnie zdanie jest bardzo ważne. Agenci AI mają czasami tendencję do tworzenia kolejnych funkcji pomocniczych, klas i plików, mimo że podobne rozwiązanie już istnieje.

Cursor może pomóc w:

• analizie całego frameworka,
• tworzeniu nowych testów,
• refaktoryzacji Page Object Model,
• przygotowywaniu fixture’ów,
• wyszukiwaniu nieużywanego kodu,
• aktualizowaniu selektorów,
• tworzeniu dokumentacji,
• wdrażaniu nowych bibliotek,
• naprawianiu błędów.

Największą zaletą jest praca bezpośrednio na repozytorium. Nie musimy kopiować każdego fragmentu kodu do osobnego czatu i ręcznie tłumaczyć całej struktury projektu.

Największe ryzyko również wynika z pracy na repozytorium. Im więcej zmian może wykonać agent, tym dokładniej trzeba je później sprawdzić.

Dla kogo? Dla testerów automatyzujących, którzy chcą korzystać z AI podczas codziennej pracy w edytorze kodu.

6. Postman Agent Mode

Postmana raczej nie trzeba przedstawiać osobom zajmującym się testowaniem API. Agent Mode dodaje do niego możliwość wykonywania zadań na podstawie poleceń napisanych normalnym językiem.

Możemy poprosić narzędzie na przykład o:

Dodaj testy sprawdzające, czy odpowiedź ma kod 200, czas odpowiedzi jest krótszy niż 500 milisekund, a każde pole email zawiera poprawny adres.

Agent może przygotować odpowiedni skrypt i dodać go do zapytania.

Możemy również poprosić o:

• utworzenie zapytania,
• przygotowanie testów,
• naprawienie błędu,
• wyjaśnienie odpowiedzi API,
• pracę z kolekcjami,
• utworzenie mock servera,
• przygotowanie dokumentacji,
• analizę problemów z autoryzacją,
• aktualizację istniejących testów.

To może być bardzo przydatne dla osób, które rozumieją podstawy testowania API, ale nie czują się jeszcze swobodnie w JavaScripcie.

Trzeba tylko uważać, aby nie ograniczyć całego testowania do sprawdzenia kodu odpowiedzi i czasu jej otrzymania. Endpoint może zwrócić status 200, a dane nadal mogą być niepoprawne.

Dobry test API powinien sprawdzać strukturę odpowiedzi, wartości pól, reguły biznesowe, obsługę błędów, autoryzację i wpływ operacji na pozostałe elementy systemu.

AI może pomóc napisać test, ale ktoś nadal musi wiedzieć, co właściwie powinno zostać sprawdzone.

Dla kogo? Dla testerów API oraz osób, które chcą szybciej tworzyć skrypty w Postmanie.

7. Applitools Eyes

Wyobraźmy sobie, że test automatyczny sprawdza, czy przycisk „Kup teraz” istnieje na stronie.

Test przechodzi.

Problem polega na tym, że po ostatniej zmianie przycisk został zasłonięty przez baner i użytkownik nie jest w stanie go kliknąć. Z punktu widzenia klasycznej asercji wszystko może wyglądać poprawnie. Element nadal znajduje się w strukturze strony.

Tutaj przydają się testy wizualne.

Applitools Eyes wykorzystuje AI do wykrywania zmian w wyglądzie interfejsu. Może pomóc zauważyć między innymi:

• przesunięte elementy,
• niepoprawne odstępy,
• zasłonięte przyciski,
• brakujące obrazy,
• różnice pomiędzy przeglądarkami,
• problemy z układem strony,
• nieoczekiwane zmiany w dokumentach i plikach PDF.

Applitools można połączyć z popularnymi frameworkami automatyzacji. Test nadal wykonuje określony scenariusz, ale w wybranym momencie sprawdza również wygląd aplikacji.

To szczególnie przydatne w projektach, w których interfejs często się zmienia albo musi działać na wielu urządzeniach i przeglądarkach.

Nie oznacza to, że można całkowicie zrezygnować z klasycznych asercji. Test wizualny nie zawsze powie nam, czy cena została poprawnie obliczona, czy użytkownik otrzymał odpowiednie uprawnienia albo czy dane prawidłowo zapisały się w bazie.

Najlepsze efekty daje połączenie testów funkcjonalnych i wizualnych.

Dla kogo? Dla zespołów testujących aplikacje webowe, mobilne i interfejsy działające na wielu urządzeniach.

8. mabl

mabl to platforma do automatyzacji testów, która mocno wykorzystuje funkcje AI.

Może pomagać w tworzeniu testów przeglądarkowych, mobilnych i API. Oferuje również mechanizmy zwiększające odporność testów na zmiany w aplikacji.

W klasycznej automatyzacji nawet niewielka zmiana selektora może spowodować awarię wielu testów. Mechanizmy auto-healing próbują rozpoznać, że element nadal istnieje, ale jego sposób identyfikacji uległ zmianie.

Brzmi świetnie, ale warto zachować ostrożność.

Jeżeli test szuka przycisku „Zatwierdź”, a narzędzie po zmianie interfejsu zacznie klikać inny, podobny element, możemy otrzymać przechodzący test wykonujący niewłaściwą operację.

Automatyczne naprawianie testów powinno ograniczać pracę związaną z utrzymaniem, a nie ukrywać rzeczywiste zmiany w produkcie.

mabl może pomóc w:

• generowaniu testów na podstawie opisu,
• przygotowywaniu fragmentów JavaScript,
• analizowaniu przyczyn niepowodzenia,
• tworzeniu testów API,
• wykonywaniu asercji wizualnych,
• dostosowywaniu testów do zmian,
• łączeniu testów z procesem CI/CD.

To ciekawe rozwiązanie dla zespołów, które chcą rozwijać automatyzację bez budowania całego frameworka od zera.

Dla kogo? Dla firm poszukujących platformy low-code do testów webowych, mobilnych i API.

9. testRigor

testRigor pozwala tworzyć automatyczne scenariusze za pomocą poleceń napisanych zwykłym językiem.

Przykładowy test może wyglądać tak:

click "Zaloguj się"
enter "tester@example.com" into "Adres e-mail"
enter stored value "password" into "Hasło"
click "Kontynuuj"
check that page contains "Panel użytkownika"

Taki zapis jest znacznie bardziej zrozumiały dla testera manualnego albo osoby biznesowej niż kod wykorzystujący XPath, CSS i dodatkowe biblioteki.

Narzędzie może być używane do:

• testowania aplikacji webowych,
• automatyzacji aplikacji mobilnych,
• testów regresji,
• testowania API,
• sprawdzania wiadomości e-mail,
• pracy z plikami,
• tworzenia testów end-to-end.

Największą zaletą jest niski próg wejścia. Tester nie musi od razu znać języka programowania i całej architektury frameworka.

Nie oznacza to jednak, że naturalny język rozwiązuje wszystkie problemy. Polecenie może być niejednoznaczne. Jeżeli na ekranie znajdują się dwa podobnie nazwane przyciski, narzędzie nadal musi wiedzieć, o który z nich chodzi.

Ktoś musi również zaprojektować sam scenariusz, określić odpowiednie dane i zdecydować, jakie rezultaty powinny zostać sprawdzone.

Możemy uprościć sposób zapisywania testu, ale nie usuniemy potrzeby myślenia.

Dla kogo? Dla zespołów, które chcą zaangażować testerów manualnych w automatyzację.

10. Momentic

Momentic reprezentuje nowszą kategorię narzędzi, czyli agentów AI przeznaczonych do testowania.

Zamiast dokładnie definiować każdy techniczny krok, możemy opisać cel scenariusza. Narzędzie interpretuje polecenie, porusza się po aplikacji i wykonuje odpowiednie działania.

Może być wykorzystywane do:

• przygotowywania testów end-to-end,
• automatycznego eksplorowania aplikacji,
• rozpoznawania ważnych przepływów użytkownika,
• aktualizowania testów po zmianach,
• wykonywania regresji,
• analizowania wyników,
• uruchamiania testów w CI/CD.

Jest to kierunek, o którym prawdopodobnie będziemy słyszeć coraz częściej. Tester opisuje cel biznesowy, a agent zajmuje się techniczną stroną wykonania scenariusza.

Nie oznacza to jednak pełnej autonomii.

Agent może wiedzieć, jak przejść proces zakupu, ale nie musi wiedzieć, które reguły rabatowe są najważniejsze dla firmy. Może sprawdzić, czy zamówienie zostało złożone, ale niekoniecznie zauważy, że system naliczył niewłaściwy podatek dla konkretnego kraju.

Im więcej odpowiedzialności przekazujemy AI, tym ważniejsze staje się precyzyjne określenie oczekiwanego rezultatu.

Dla kogo? Dla zespołów zainteresowanych agentowym podejściem do automatyzacji testów end-to-end.

Od którego narzędzia zacząć?

Nie ma sensu wdrażać dziesięciu narzędzi jednocześnie.

Tester manualny może zacząć od ChatGPT i wykorzystać go do analizy wymagań, przygotowywania danych oraz szukania przypadków brzegowych.

Osoba zajmująca się testowaniem API może sprawdzić Postman Agent Mode.

Tester automatyzujący powinien przyjrzeć się GitHub Copilot, Cursorowi, Claude Code albo Gemini Code Assist. Nie trzeba jednak płacić za wszystkie te rozwiązania. Najlepiej przetestować dwa lub trzy i sprawdzić, które pasuje do naszego sposobu pracy.

Jeżeli głównym problemem są błędy w wyglądzie aplikacji, warto sprawdzić Applitools Eyes.

Jeżeli zespół chce tworzyć automatyzację bez rozbudowanego frameworka, można przeanalizować mabl, testRigor albo Momentic.

Najpierw trzeba określić problem, a później dobrać narzędzie. Nie odwrotnie.

Kupowanie platformy tylko dlatego, że ma w nazwie AI, nie jest strategią testowania.

Na co uważać podczas korzystania z AI?

Narzędzia AI potrafią znacząco przyspieszyć pracę, ale potrafią też bardzo szybko wygenerować dużą ilość błędnego kodu, słabych przypadków testowych i niepotrzebnych zmian.

Nie wklejaj poufnych danych

Nie powinniśmy przekazywać do zewnętrznego narzędzia danych klientów, haseł, tokenów, kluczy API, poufnej dokumentacji ani kodu, którego przetwarzanie nie zostało zaakceptowane przez firmę.

Przed rozpoczęciem pracy należy sprawdzić politykę organizacji oraz zasady przetwarzania danych przez wybrane narzędzie.

Sprawdzaj wygenerowany kod

To, że kod wygląda profesjonalnie, nie oznacza, że jest poprawny.

AI może użyć nieistniejącej metody, starej składni albo biblioteki, której nie ma w projekcie. Może też napisać test, który zawsze przechodzi, ponieważ asercja w rzeczywistości niczego wartościowego nie sprawdza.

Nie licz przypadków testowych

Wygenerowanie 50 scenariuszy nie oznacza dobrego pokrycia.

AI może stworzyć wiele podobnych przypadków, a jednocześnie pominąć jeden scenariusz, którego awaria będzie kosztowała firmę najwięcej.

W testowaniu nadal liczy się ryzyko, a nie liczba wierszy w tabeli.

Nie ufaj bezgranicznie funkcji self-healing

Automatyczne naprawienie selektora brzmi dobrze, ale warto sprawdzić, czy test nadal wykonuje dokładnie tę samą operację.

Przechodzący test może być bardziej niebezpieczny niż test, który zakończył się błędem, jeżeli w rzeczywistości sprawdza niewłaściwy element.

Nie przestawaj myśleć

Największym zagrożeniem nie jest to, że AI popełni błąd.

Największym zagrożeniem jest sytuacja, w której przestaniemy ten błąd zauważać, ponieważ przyzwyczaimy się do bezrefleksyjnego akceptowania odpowiedzi.

Czy AI zastąpi testerów oprogramowania?

Moim zdaniem AI nie usunie zawodu testera, ale mocno zmieni sposób wykonywania tej pracy.

Część powtarzalnych czynności zostanie zautomatyzowana. Przygotowanie prostych danych, napisanie szablonu testu, wygenerowanie podstawowych asercji czy podsumowanie wyników będzie wymagało coraz mniej czasu.

Jednocześnie wzrośnie znaczenie umiejętności, których nie da się łatwo zastąpić:

• rozumienia produktu,
• oceny ryzyka,
• analizowania wymagań,
• zadawania właściwych pytań,
• znajomości procesów biznesowych,
• rozumienia architektury systemu,
• krytycznej oceny wyników.

AI może przygotować test. Ktoś jednak musi zdecydować, czy sprawdzany scenariusz ma znaczenie.

AI może napisać kod. Ktoś musi zauważyć, że kod jest niestabilny albo nie sprawdza rzeczywistego wymagania.

AI może przeanalizować logi. Ktoś musi połączyć błąd techniczny z tym, co wydarzyło się z perspektywy użytkownika.

Testerzy, którzy nauczą się dobrze korzystać z AI, prawdopodobnie będą wykonywali część zadań szybciej niż osoby całkowicie ignorujące te narzędzia.

Nie chodzi jednak o używanie AI do wszystkiego. Chodzi o świadome wybieranie momentów, w których rzeczywiście oszczędza czas albo pomaga spojrzeć na problem z innej strony.

Podsumowanie

W 2026 roku AI nie jest już tylko dodatkiem do pracy testera. Coraz częściej staje się normalnym elementem codziennego warsztatu.

ChatGPT może pomóc w analizie wymagań i przygotowaniu przypadków testowych. GitHub Copilot, Cursor, Claude Code i Gemini wspierają pracę z kodem. Postman Agent Mode ułatwia testowanie API, a Applitools Eyes pomaga wykrywać problemy wizualne.

mabl, testRigor i Momentic pokazują natomiast, w jakim kierunku rozwija się automatyzacja: mniej ręcznego budowania każdego kroku, a więcej opisywania celu, który narzędzie ma osiągnąć.

Nie oznacza to, że powinniśmy oddać AI cały proces testowania.

Najlepsze rezultaty osiągniemy wtedy, gdy potraktujemy sztuczną inteligencję jako pomocnika. Może wykonać część powtarzalnej pracy, przygotować propozycję i przyspieszyć analizę.

Ostateczna ocena nadal powinna należeć do testera.