Czy agent AI może sam testować kod? Co automatyzujemy w testach, a co zostaje dla testera

About
Latest Posts

Chief Executive Officer at eVolpe Consulting Group

Od 2009 roku prowadzę eVolpe Consulting Group, firmę wdrażającą systemy CRM/CX i HCM w średnich i dużych organizacjach. Od trzech lat przestawiam ją na sztuczną inteligencję i publicznie pokazuję, jak to wygląda w praktyce: z liczbami, nieudanymi podejściami i wnioskami, które kosztowały nas realne pieniądze. Odpowiadam za strategię, kontrakty i rozwój produktów: MintHCM oraz eVolpe AI Context Platform. Piszę o agentic AI w realnej firmie wdrożeniowej, o kontraktach IT okiem Wykonawcy i o open source jako modelu biznesowym. Jeśli zastanawiasz się, ile w AI jest realnej dźwigni, a ile teatru, znajdziesz mnie na LinkedIn i w newsletterze eVolpe.

Latest posts by Marcin Różański (see all)

Czy agent AI może sam testować kod? Co automatyzujemy w testach, a co zostaje dla testera - 19 października 2026
Gdzie człowiek musi zatwierdzać decyzje agenta AI? Bramki akceptacji w agentic engineering - 16 października 2026
Deterministic guardrails w agentic CRM – jak nie stracić kontroli nad autonomicznym agentem - 8 września 2026

Agent AI może sam testować kod. Potrafi wygenerować scenariusze testowe z user story, napisać testy jednostkowe i przeglądarkowe, uruchomić je i poprawiać kod, dopóki testy nie przejdą. Nie potrafi natomiast sam ocenić, czy scenariusze są kompletne, ani odebrać zmiany. Poniżej pokazujemy, jak wygląda proces wytwarzania oprogramowania w eVolpe: agent AI testuje własną pracę, a człowiek zatwierdza kluczowe decyzje w tzw. bramkach.

Dlaczego deklaracja agenta AI, że „kod działa”, nie wystarcza?

Deklaracja agenta AI nie jest dowodem. Model językowy potrafi wygenerować kod, który wygląda poprawnie, a mimo to nie spełnia wymagań. W naszym zespole jeszcze w połowie 2026 roku praca wyglądała tak: agent kończył implementację i zapewniał, że wszystko zadziała. Potem deweloper otwierał przeglądarkę, sprawdzał funkcję i opisywał agentowi, co widzi na ekranie. Każde przejście między implementacją, code review i testami uruchamiał ręcznie człowiek, a testy w całości wykonywał tester.

Ten problem nie dotyczy tylko naszego zespołu. W Stack Overflow Developer Survey 2025 66% programistów wskazało jako główną frustrację rozwiązania AI, które są „prawie dobre, ale nie do końca”, a 46% zadeklarowało brak zaufania do dokładności narzędzi AI (Stack Overflow, 2025). Raport DORA pokazuje podobny obraz: z AI w pracy korzysta 90% badanych, ale 30% ma niewielkie zaufanie do generowanego przez nią kodu albo nie ma go wcale (Google DORA, 2025).

Jak działa proces, w którym agent AI sam testuje swój kod?

Agent AI testuje swój kod w procesie prowadzonym przez orkiestratora. To skill, który sam nie wykonuje wszystkich kroków, tylko pilnuje ich kolejności i udziału człowieka. Deweloper uruchamia orkiestratora, podając numer zgłoszenia z Redmine. Agent zmienia status zgłoszenia na „w toku”, żeby nikt inny nie zaczął pracy równolegle. Następnie analizuje user story i kod źródłowy, przygotowuje plan implementacji z pytaniami do dewelopera, a po akceptacji dopisuje do user story podjęte decyzje.

Dalsze kroki toczą się częściowo równolegle. Na podstawie user story agent generuje plan testów i implementuje zmianę. Po implementacji niezależny subagent wykonuje self code review według standardów zespołu, na przykład sprawdza, czy nowe pole objęto audytem. Powstają też testy jednostkowe oraz testy przeglądarkowe oparte na wcześniejszych scenariuszach. Jeśli test nie przechodzi, agent poprawia kod i powtarza cykl, najwyżej trzy razy. Po trzeciej nieudanej próbie zatrzymuje się i raportuje człowiekowi, w którym miejscu utknął.

Agentem kodującym jest u nas Claude Code, rozszerzony o skille, czyli zestawy instrukcji opisujące pracę z konkretnym systemem. W Stack Overflow Developer Survey 2026 Claude Code wskazało 66% użytkowników agentów kodujących, a GitHub Copilot 59% (Stack Overflow, 2026). Proces działa obecnie na SuiteCRM, a MintHCM przechodzi ostatnią weryfikację. Kolejne w planach są Creatio i SpiceCRM.

Jakie testy agent AI generuje i uruchamia samodzielnie?

Agent AI generuje i uruchamia dwa rodzaje testów: jednostkowe i przeglądarkowe (end-to-end). Testy jednostkowe sprawdzają logikę na poziomie kodu, na przykład czy algorytm sumy kontrolnej NIP zwraca poprawny wynik dla zestawu prawidłowych i błędnych numerów. Testy przeglądarkowe to skrypty, które otwierają system, klikają kolejne elementy, wpisują wartości w pola i sprawdzają, czy na ekranie pojawia się oczekiwany wynik. To one zastąpiły ręczne przeklikiwanie systemu przez dewelopera po każdej implementacji.

Każdy test wygenerowany albo zmieniony w ramach danego user story dostaje tag z identyfikatorem zgłoszenia. Dzięki temu przy każdej poprawce agent uruchamia wszystkie testy powiązane ze zgłoszeniem, także te dotyczące fragmentów, których poprawka nie zmieniała. W ten sposób wychwytuje sytuacje, w których naprawa jednego miejsca psuje inne. Uruchamianie całego zestawu testów systemu przy każdej zmianie nie ma sensu, bo w dużych projektach trwa to nawet godzinami.

W których momentach człowiek musi zatwierdzić decyzję agenta AI?

Człowiek zatwierdza decyzje agenta AI w czterech bramkach: przy akceptacji planu, przed zatwierdzeniem kodu (commit), przy weryfikacji raportu z code review i przy odbiorze testów. Bramka to moment, w którym można jeszcze zmienić kierunek. Można poprawić błędne założenie, dodać wiedzę, której brakuje w user story, albo potwierdzić, że rozwiązanie agenta jest lepsze od pierwotnego pomysłu. Poza bramkami agent może zadać pytanie w dowolnym momencie, jeśli natrafi na coś, czego plan nie przewidział.

Bramki nie są formalnością. Analiza artefaktów z naszych projektów pokazała, że znacząca część decyzji agenta wymaga korekty, najczęściej na etapie planowania. Przykład: agent, który miał przeanalizować dane w instancji wdrożeniowej, zaczął łączyć się z innym środowiskiem, do którego akurat miał skonfigurowany dostęp. Deweloper zatrzymał go, zanim agent podjął działania na niewłaściwych danych. To mocny argument za tym, żeby uprawnienia i połączenia agenta definiować możliwie wąsko.

W części projektów code review działa już automatycznie. Po zamknięciu implementacji skill uruchamia się w tle na osobnych serwerach, a zespół dostaje powiadomienie, że raport czeka. Recenzent ocenia raport: sprawdza, czy agent nie był zbyt skrupulatny i czy czegoś nie przeoczył, a potem porównuje go z kodem. Potwierdzone błędy trafiają do Redmine. Implementator decyduje, które z nich naprawić, a agent poprawia je w pętli z testami i pokazuje człowiekowi wynik do akceptacji.

Co zostaje dla testera, gdy agent AI pisze testy?

Testerowi zostaje ocena kompletności, regresja powiązanych procesów i ostateczny odbiór. Tester przegląda plan testów wygenerowany przez agenta i dopisuje przypadki, o których agent nie pomyślał. Następnie sprawdza w raporcie, czy każdy scenariusz z planu ma odpowiednik w postaci testu w kodzie. Scenariusze bez testu automatycznego wykonuje ręcznie albo zleca ich wygenerowanie. Błędy zgłasza do Redmine, skąd po potwierdzeniu przez implementatora wracają do agenta.

Najtrudniejsza do zautomatyzowania pozostaje wiedza o historii systemu. Tester, który wie, że modyfikowany proces łączy się z mechanizmem wdrożonym dwa lata wcześniej i nieopisanym w przypadkach testowych, sprawdzi ten mechanizm ręcznie. Agent AI takiej wiedzy nie ma, jeśli nikt nie zapisał jej w dokumentacji. Na końcu to tester podpisuje się pod tym, że zmiana działa, i ta odpowiedzialność nie przechodzi na agenta.

Dane rynkowe pokazują, że programiści powierzają agentom głównie obszary o niższym ryzyku. Według Stack Overflow Developer Survey 2026 deweloperzy używają AI przede wszystkim do generowania kodu w znanych sobie obszarach (67%) i debugowania (61%), a tylko 20% do wdrażania, utrzymania i diagnozowania systemów produkcyjnych (Stack Overflow, 2026).

Jak agent AI przetestował zmianę na przykładzie pola NIP?

Na przykładowym zgłoszeniu agent AI przeszedł cały proces, od planu do raportu z testów. Zadanie polegało na dodaniu do kontrahentów pola NIP z walidacją formatu i sumy kontrolnej. Przed implementacją agent zapytał między innymi, czy po wykryciu duplikatu dodawać link do istniejącego rekordu. Sam zakładał, że nie, ale deweloper uznał link za przydatny. Deweloper odrzucił też propozycję dodania niestandardowego komponentu frontendowego, bo nie był potrzebny do realizacji story. Po tych korektach zatwierdził plan.

Wygenerowane scenariusze obejmowały między innymi widoczność pola w widoku rekordu i edycji, typ pola, etykiety po polsku i angielsku oraz domyślną widoczność kolumny na liście. Agent pokrył większość scenariuszy testami automatycznymi, a w self code review sam wykrył i poprawił jeden błąd. W raporcie zaznaczył, czego nie sprawdził: importu rekordów oraz polskich etykiet, bo na instancji testowej brakowało polskiej paczki językowej. Z testu importu deweloper świadomie zrezygnował w tym zgłoszeniu.

Udział dewelopera w samym kodzie był znikomy. Sprowadził się do odpowiedzi na pytania agenta, zatwierdzenia planu i sprawdzenia wyniku w przeglądarce. Cały proces trwał jednak dłużej niż praca samego dewelopera, bo obejmuje też code review i testy. Trzeba też uczciwie zaznaczyć, że to prosty przypadek przygotowany na potrzeby prezentacji, a nie średnia z projektów. Przy bardziej złożonych zadaniach rośnie zarówno plan, jak i liczba interakcji, więc oszczędność czasu nie będzie proporcjonalna.

Gdzie agent AI jeszcze nie radzi sobie z testami?

Agent AI nie radzi sobie jeszcze z testami przeglądarkowymi złożonych, wieloetapowych procesów biznesowych. Dobrym przykładem jest system HCM. Żeby przetestować nowy krok w procesie zwolnienia pracownika, trzeba tego pracownika najpierw zatrudnić, a to długa ścieżka przez kilka modułów. Agent nie wie, jak przejść taki proces, dopóki skille i testy bazowe danego systemu go nie opisują. Dlatego na razie skupiamy się na prostszych zmianach: nowych polach, modyfikacjach struktury i nowych modułach.

Drugim ograniczeniem są integracje z systemami zewnętrznymi, w których rośnie liczba decyzji i zależności. Trzecim jest pokrycie systemów: proces wymaga skilli i testów bazowych dla każdej platformy, na przykład dla modułów kontrahentów i kontaktów, więc wdrożenie go na kolejnym systemie to osobna praca. Raport DORA podkreśla przy tym, że przyjmowanie AI nadal wiąże się z niższą stabilnością dostarczania oprogramowania, bo przyspieszenie prac ujawnia słabości na dalszych etapach (Google DORA, 2025).

Jak proces z agentem AI uczy się na własnych błędach?

Proces uczy się na błędach dzięki artefaktom, które orkiestrator zapisuje na każdym etapie. Są to decyzje z planowania, korekty wprowadzone przez ludzi i raporty z code review. Zebraliśmy te artefakty z wielu projektów i przeanalizowaliśmy je pod kątem powtarzających się problemów. Jednym z nich był brak sprawdzania uprawnień: skill implementacyjny dodawał przycisk akcji na formularzu, ale nie weryfikował, czy użytkownik może tę akcję wykonać. Poprawiliśmy skill i planujemy powtarzać taki audyt cyklicznie.

Agent aktualizuje też user story w Redmine o decyzje podjęte podczas planowania. Wcześniej ustalenia z analitykiem zapadały na czacie i nie trafiały do zgłoszenia. Teraz specyfikacja zgadza się z tym, co faktycznie powstało. Ma to znaczenie także dla samego AI, bo w Stack Overflow Developer Survey 2026 programiści wskazali cele projektu i wymagania (85%) oraz kod i dokumentację (73%) jako najbardziej wiarygodne źródła kontekstu dla AI (Stack Overflow, 2026).

Co agent AI automatyzuje w testach, a co zostaje dla człowieka?

Etap	Co robi agent AI	Co robi człowiek
Planowanie	Analizuje user story i kod, przygotowuje plan, zadaje pytania	Odpowiada, koryguje i akceptuje plan (bramka 1)
Plan testów	Generuje scenariusze testowe z user story	Tester uzupełnia brakujące przypadki
Implementacja	Pisze kod, aktualizuje user story w Redmine	Odpowiada na pytania agenta
Self code review	Niezależny subagent sprawdza zgodność ze standardami	—
Testy jednostkowe i E2E	Pisze, uruchamia i poprawia kod w pętli (max 3 próby)	Deweloper weryfikuje wynik w przeglądarce przed commitem (bramka 2)
Code review	Generuje raport w tle	Recenzent ocenia raport i kod (bramka 3)
Poprawki	Naprawia błędy i uruchamia testy powiązane ze zgłoszeniem	Implementator potwierdza, że błąd istnieje
Odbiór	Raportuje, czego nie przetestował	Tester ocenia kompletność, sprawdza regresję starszych procesów i odbiera zmianę (bramka 4)

O co pytać dostawcę, który rozwija system CRM lub HCM z pomocą AI?

Dostawcę warto pytać nie o to, czy używa AI, ale jak weryfikuje jej pracę. Dobre pytania to: gdzie w procesie są bramki, kto je zatwierdza, jakie artefakty powstają przy każdym zgłoszeniu i czy można je przejrzeć. Dowodem jakości nie jest deklaracja agenta ani zapewnienie dostawcy. Jest nim raport z testów, który pokazuje także to, czego nie sprawdzono, i wskazuje osobę odpowiedzialną za odbiór. Jeśli chcesz porozmawiać o tym, jak taki proces mógłby wyglądać w Twoim systemie, umów się na krótką konsultację z naszym zespołem.

Umów bezpłatną konsultację z ekspertem wdrożeniowym eVolpe

Wybierz dogodny dla siebie termin.

Najczęściej zadawane pytania

Czy agent AI może całkowicie zastąpić testera?

Nie. Agent AI generuje i uruchamia testy, ale nie oceni, czy scenariusze są kompletne, i nie zna historii systemu, jeśli nikt jej nie udokumentował. Tester odpowiada za kompletność, regresję powiązanych procesów i ostateczny odbiór zmiany.

Jakie testy agent AI pisze najskuteczniej?

Najlepiej radzi sobie z testami jednostkowymi oraz testami przeglądarkowymi dla prostych zmian, takich jak nowe pola, walidacje czy modyfikacje struktury. Wieloetapowe procesy biznesowe i integracje wciąż wymagają większego udziału człowieka.

Czym jest orkiestrator w procesie z agentem AI?

Orkiestrator to skill, który prowadzi zgłoszenie przez kolejne etapy: planowanie, plan testów, implementację, self code review, testy i code review. Sam nie wykonuje każdego kroku, tylko pilnuje ich kolejności i momentów, w których decyzję musi zatwierdzić człowiek.

Czym są bramki w procesie z agentem AI?

Bramki to punkty, w których człowiek akceptuje albo koryguje pracę agenta: plan, kod przed commitem, raport z code review i wynik testów. Pozwalają zawrócić agenta, zanim błędna decyzja przejdzie do kolejnego etapu.

Co się dzieje, gdy agent AI nie potrafi naprawić błędu?

Agent powtarza cykl testu i poprawki najwyżej trzy razy. Po trzeciej nieudanej próbie zatrzymuje się i raportuje człowiekowi, co próbował zrobić i gdzie utknął. Dzięki temu nie wpada w nieskończoną pętlę.

Czy testy pisane przez agenta AI skracają czas realizacji zgłoszeń?

Przy prostych zmianach znacząco skracają aktywną pracę dewelopera. Przy zadaniach złożonych rośnie liczba decyzji i interakcji z agentem, więc skrócenie czasu nie jest proporcjonalne do złożoności zgłoszenia.

Na jakich systemach eVolpe stosuje proces z agentem testującym kod?

Proces działa na SuiteCRM 8, a MintHCM przechodzi ostatnią weryfikację. W następnej kolejności planujemy rozszerzenie na Creatio i SpiceCRM. Każdy system wymaga własnych skilli i testów bazowych.