AI w testowaniu oprogramowania: szablon promptu, tabela decyzyjna i liczby z badań

AI w testowaniu oprogramowania dzieli dziś pokoje testerskie na dwa obozy: jedni widzą w modelach językowych darmowego pomocnika, drudzy maszynę do produkowania pracy, którą potem trzeba posprzątać. Oba obozy mają rację, bo wynik nie zależy od narzędzia, tylko od jakości polecenia, które mu dajecie. W tym artykule dostajecie rzeczy do użycia od poniedziałku: szablon promptu do generowania przypadków testowych, tabelę decyzyjną z ośmioma zadaniami oraz plan pomiaru pilotażu, który da Wam liczby zamiast opinii. Do tego dane z badań z 2025 roku, które pokazują, ile zespoły naprawdę zyskują i gdzie ta oszczędność znika. Nie znajdziecie tu wróżenia, czy AI zastąpi testerów, bo to pytanie nie pomaga Wam w niczym, co macie zrobić w tym kwartale.

AI w testowaniu oprogramowania: cztery zadania, w których naprawdę pomaga

Definicja mieści się w dwóch zdaniach. AI w testowaniu to model językowy w roli asystenta: czyta wymaganie, kod i logi, a w odpowiedzi proponuje tekst albo kod testu, który Wy oceniacie i poprawiacie. W praktyce ten asystent przydaje się w czterech zadaniach:

• Szkic przypadków testowych z wymagania albo historyjki. Dostajecie listę scenariuszy w kilka minut zamiast w kilka godzin. Sprawdzić musicie, czy przypadki dotyczą funkcji, która faktycznie istnieje w Waszym systemie.
• Dane testowe i warianty graniczne. Dostajecie zestawy wartości poprawnych, granicznych i niepoprawnych dla każdego pola. Sprawdzić musicie, czy granice odpowiadają Waszym realnym limitom, a nie domyślnym wartościom z internetu.
• Opis błędu z logów i kroków odtworzenia. Dostajecie czytelne zgłoszenie z surowego stosu wywołań w minutę. Sprawdzić musicie, czy model nie dopisał kroku, którego w logach nie było.
• Szkic kodu testu i brakujące asercje. Dostajecie szkielet testu i listę warunków, których Wasz test nie sprawdza. Sprawdzić musicie, czy asercje weryfikują wymaganie, a nie bieżące zachowanie kodu wraz z jego błędami.

I tu stoi teza całego tekstu: model nie przegrywa z testerem ani z nim nie wygrywa. Przegrywa albo wygrywa z jakością polecenia, które od Was dostaje. Tam, gdzie wejście jest opisane precyzyjnie, z kontekstem, ograniczeniami i formatem wyjścia, model oszczędza Wam godziny. Tam, gdzie prosicie o „testy do tego kodu”, oddaje materiał, którego sprawdzenie zajmuje więcej czasu niż napisanie testów samemu. Widzimy to w zespołach, które szkolimy na szkoleniu o sztucznej inteligencji w testowaniu i u klientów, u których robimy wdrożenie AI w procesie testów: różnica między dobrym a pustym promptem to często różnica między godziną a dniem pracy.

Skala zjawiska nie jest już niszowa. Według World Quality Report 2025 od Capgemini, Sogeti i OpenText 89 procent organizacji pilotuje albo wdraża procesy inżynierii jakości wsparte generatywną AI. Ten sam World Quality Report 2025 podaje, że 37 procent ma takie rozwiązania w produkcji, a 52 procent siedzi w fazie pilotażu. Co ciekawe, raport odnotowuje też przesunięcie zastosowań: z analizy wyników i raportowania defektów w stronę kształtowania wejścia, bo najszybciej rośnie projektowanie przypadków testowych i porządkowanie wymagań. Osobnym, szybko rosnącym wątkiem są agenty, które same uruchamiają testy, ale zanim o agentach, warto opanować zwykły prompt. Wniosek dla Was: pytanie „czy używać AI w testach” jest już rozstrzygnięte przez rynek, otwarte zostaje „co dokładnie zlecać i jak to sprawdzać”.

Szablon promptu do generowania przypadków testowych, gotowy do skopiowania

Pusta prośba nie działa z prostego powodu: model nie zna Waszych ograniczeń, więc je zmyśla, i robi to z pełnym przekonaniem. Prompt „napisz testy do tego kodu” działa jak zamówienie „poproszę jedzenie”: coś przyniosą, zwykle nie to, na co liczyliście. Poniższy szablon wymusza na Was podanie wszystkiego, czego model sam nie wie, i dlatego działa.

ROLA: Jesteś testerem z dziesięcioletnim doświadczeniem w [domena, np. e-commerce, bankowość, logistyka].
KONTEKST: [3 do 5 zdań: kto jest użytkownikiem, co ma osiągnąć, w jakim systemie, co się dzieje przed i po]
WEJŚCIE: [wymaganie, historyjka użytkownika, fragment kodu albo zrzut odpowiedzi API, wklejony dosłownie]
OGRANICZENIA: [role i uprawnienia, waluty, limity, zależności od innych systemów, czego NIE testujemy]
ZADANIE: Zaproponuj przypadki testowe w tabeli: identyfikator, warunek wstępny, kroki, dane, oczekiwany wynik, priorytet.
POKRYCIE: Dla każdego pola wejściowego daj po jednym przypadku: wartość poprawna, wartość graniczna, wartość niepoprawna, wartość pusta.
CZEGO NIE WIEM: Dopisz na końcu listę założeń, które przyjąłeś, i pytań do analityka.
FORMAT: [tabela w markdown, CSV do importu albo scenariusze w Gherkin]
ZAKAZY: Nie wymyślaj pól, komunikatów ani ekranów, których nie ma w WEJŚCIU. Przy braku informacji zadaj pytanie, nie zgaduj.

Dwa pola robią tu największą robotę. OGRANICZENIA to jedyne pole, które odcina większość bezużytecznych odpowiedzi: model nie wie, że u Was kwota zamówienia nie może przekroczyć limitu kredytowego, a kod rabatowy nie łączy się z promocją, i dopóki tego nie napiszecie, wymyśli własne zasady i zrobi to przekonująco. ZAKAZY zamieniają halucynację w pytanie: model poproszony o zgłaszanie braków zamiast zgadywania oddaje krótszą odpowiedź, w której pierwsze trzy linijki to pytania do analityka. To jest wynik, który oszczędza Wam czas, choć na pierwszy rzut oka wygląda jak porażka promptu. A tak wygląda szablon wypełniony dla sklepu internetowego:

ROLA: Jesteś testerem z dziesięcioletnim doświadczeniem w e-commerce.
KONTEKST: Zalogowany klient sklepu wpisuje kod rabatowy w koszyku przed przejściem do płatności. Koszyk zawiera od 1 do 50 pozycji. Po zatwierdzeniu kodu suma do zapłaty ma się przeliczyć bez przeładowania strony.
WEJŚCIE: Historyjka: "Jako klient chcę wpisać kod rabatowy w koszyku, żeby zapłacić mniej". Kryteria: kod 8 znaków, wielkie litery i cyfry; rabat procentowy albo kwotowy; komunikat o błędzie przy kodzie nieważnym.
OGRANICZENIA: Jeden kod na zamówienie. Kod nie łączy się z promocją "druga sztuka taniej". Rabat kwotowy nie może zejść poniżej 0,01 zł do zapłaty. Kody wygasają o 23:59 czasu lokalnego. Nie testujemy integracji z bramką płatności.
ZADANIE: Zaproponuj przypadki testowe w tabeli: identyfikator, warunek wstępny, kroki, dane, oczekiwany wynik, priorytet.
POKRYCIE: Dla pola kodu daj po jednym przypadku: wartość poprawna, wartość graniczna (8 znaków i 7 znaków), wartość niepoprawna (małe litery, znaki specjalne), wartość pusta.
CZEGO NIE WIEM: Dopisz na końcu listę założeń, które przyjąłeś, i pytań do analityka.
FORMAT: Tabela w markdown.
ZAKAZY: Nie wymyślaj pól, komunikatów ani ekranów, których nie ma w WEJŚCIU. Przy braku informacji zadaj pytanie, nie zgaduj.

Co z wynikiem zrobić dalej? Cztery rzeczy zostają do Waszej decyzji. Priorytety, bo model zwykle daje wszystkiemu wysoki. Realność danych, bo kody rabatowe muszą istnieć w Waszym środowisku testowym. Kolejność wykonania. I wreszcie ocena, czy dany przypadek w ogóle wnosi informację, czy tylko powiększa raport. Model przygotował materiał, decyzję podejmujecie Wy.

Tabela decyzyjna: co zlecić modelowi, a co zostawić testerowi

Szablon załatwia „jak zlecać”, ale wcześniej trzeba rozstrzygnąć „co zlecać”. Poniższa tabela to granica, którą stosujemy w naszych projektach i którą polecamy Wam jako punkt startu: osiem typowych zadań testera i jasna odpowiedź przy każdym.

Wiersz o priorytetach i ryzyku jest nienegocjowalny, bo priorytet to nie cecha testu, tylko decyzja o konsekwencjach. Model wie, jak zwykle wyglądają priorytety w tysiącach projektów, z których się uczył, ale nie wie, że u Was moduł płatności obsługuje klienta, który generuje połowę przychodu, ani że za awarię raportową nikt nie dzwoni w nocy. Jeśli oddacie priorytety modelowi, oddacie mu odpowiedzialność, której on nie poniesie. Podobny mechanizm psuje zresztą wskaźniki zespołowe, o czym pisaliśmy przy okazji metryk DORA w erze AI: gdy generowanie jest tanie, sama liczba rzeczy przestaje cokolwiek dowodzić.

Drugi wiersz wymagający komentarza to samonaprawianie testów interfejsu. Brzmi jak spełnienie marzeń, bo nikt nie lubi poprawiać selektorów po każdej zmianie ekranu. Pułapka polega na tym, że narzędzie nie odróżnia „przycisk zmienił identyfikator” od „przycisk zniknął, bo ktoś zepsuł widok”. W obu przypadkach znajdzie element najbardziej podobny do starego i test przejdzie. Test, który zawsze przechodzi, nie jest testem, jest dekoracją. Dlatego każda automatyczna naprawa musi zostawiać ślad, który człowiek przegląda.

Ile naprawdę oszczędzacie: co mówią badania z 2025 roku

Teraz liczby, bo bez nich ta dyskusja zamienia się w wymianę anegdot. World Quality Report 2025 od Capgemini, Sogeti i OpenText, oparty na odpowiedziach ponad 2 000 osób z kadry kierowniczej z 22 krajów, podaje średni wzrost produktywności na poziomie 19 procent, ale zaraz dodaje, że jedna trzecia organizacji widzi zysk minimalny. Ten sam World Quality Report 2025 pokazuje, że tylko 15 procent organizacji osiągnęło wdrożenie w skali całej firmy, 43 procent zostaje w fazie eksperymentu, a 30 procent działa w wąskich przypadkach użycia. Jako bariery skalowania World Quality Report 2025 wymienia ryzyko prywatności danych u 67 procent badanych, złożoność integracji u 64 procent, halucynacje i wątpliwą niezawodność u 60 procent oraz brak kompetencji z AI i uczenia maszynowego u 50 procent, bez zmiany wobec 2024 roku. Wniosek dla Was: średnia 19 procent to nie obietnica dla Waszego zespołu, tylko wypadkowa firm, które mierzyły, i firm, które zgadywały.

Perspektywę samych praktyków daje Stack Overflow Developer Survey 2025, w którym 84 procent badanych używa narzędzi AI w pracy nad kodem albo planuje ich używać, a według tego samego badania Stack Overflow z 2025 roku codziennie korzysta z nich 47,1 procent wszystkich badanych i 50,6 procent zawodowych programistów. Zaufanie nie nadąża za użyciem: w Stack Overflow Developer Survey 2025 trafności odpowiedzi AI ufa 33 procent badanych, a nie ufa 46 procent. Najczęstszą frustracją według Stack Overflow Developer Survey 2025 są „rozwiązania prawie dobre, ale nie do końca”, wskazane przez 66 procent, a 45,2 procent przyznaje, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu, niż zakładali. I jeszcze jedna liczba z Stack Overflow Developer Survey 2025, naszym zdaniem najzdrowsza w całym raporcie: 75,3 procent badanych i tak zapyta człowieka, kiedy nie ufa odpowiedzi modelu. Dla Was to znaczy tyle, że przegląd wygenerowanego materiału nie jest kosztem ukrytym, tylko głównym kosztem, i trzeba go wpisać do rachunku od pierwszego dnia.

Najtwardsze dane pochodzą z badania inżynierów Meta, opisanego w pracy Alshahwan i innych na arXiv w 2024 roku: ich narzędzie TestGen-LLM dopisywało testy jednostkowe do istniejących klas Instagrama i Facebooka, a każdy wynik przechodził filtr, bo test musiał się zbudować, przejść pięć razy pod rząd i podnieść pokrycie. W ocenie na produktach Reels i Stories, według tej samej pracy Meta z 2024 roku, 75 procent wygenerowanych przypadków poprawnie się zbudowało, 57 procent przechodziło stabilnie, a 25 procent podniosło pokrycie. Praca Alshahwan i innych z 2024 roku podaje też, że podczas wewnętrznych maratonów testowych narzędzie poprawiło 11,5 procent wszystkich klas, do których je zastosowano, a 73 procent jego rekomendacji inżynierowie przyjęli do produkcji. Przeczytajcie te liczby jeszcze raz: firma z własnym narzędziem, ogromną bazą kodu i automatycznym filtrem odsiewającym testy niestabilne, a mimo to prawie połowa wygenerowanych testów nie przeszła stabilnie i tylko jeden z trzech podniósł pokrycie. Przy ręcznym prompcie bez takiego filtra ten odsiew robi człowiek, i to jest koszt, którego nikt nie wpisuje do arkusza oszczędności. Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „AI pisze szybciej, niż ktokolwiek jest w stanie przeczytać. Dlatego wartość testera przenosi się z pisania testów na decyzję, które testy w ogóle mają sens.” Na marginesie: cały ten artykuł dotyczy używania AI do testowania, a testowanie samych systemów AI, czyli produktów, w których siedzi model, to osobny temat z osobnym warsztatem.

Narzędzia i pytania, które warto zadać przed zakupem

Nie wymienimy tu marek, bo rynek zmienia się szybciej niż artykuły na blogach, a kategorie zostają. Narzędzia AI dla testerów dzielą się dziś na cztery grupy. Asystent w edytorze kodu podpowiada kod testu podczas pisania; zapytajcie dostawcę, czy Wasz kod trafia do trenowania modelu, bo ryzykiem jest wyciek własności intelektualnej do cudzego modelu. Generator testów podpięty do repozytorium tworzy testy do istniejących klas; zapytajcie, jaki odsetek wygenerowanych testów u obecnych klientów przechodzi przegląd człowieka, bo ryzykiem jest zalew testów, które podnoszą statystyki, a nie wykrywalność błędów. Narzędzie do utrzymania testów interfejsu naprawia testy po zmianach ekranów; zapytajcie, czy każda naprawa zostawia ślad do przeglądu, bo ryzykiem jest uciszenie prawdziwej awarii. Agent uruchamiający testy sam planuje i wykonuje przebiegi bez człowieka; zapytajcie, jakie dokładnie uprawnienia ma w Waszym środowisku i co może zmienić, bo ryzykiem są działania, o których dowiecie się po fakcie. Rozszerzoną wersję tej listy znajdziecie w tekście siedem pytań, które warto zadać przed zapłaceniem za AI w testowaniu na naszym portalu Strefa QA.

Jak młody jest ten obszar, pokazuje sama organizacja standaryzująca zawód. W wersji 2.0 sylabusa Certified Tester AI Testing, opisanej przez ISTQB w 2026 roku, materiał skrócono z 11 rozdziałów do 7, szkolenie trwa 3 dni, a treści o używaniu AI do testowania w ogóle usunięto i przeniesiono do osobnej certyfikacji CT-GenAI. Wersja 2.0 dotyczy wyłącznie testowania systemów opartych na AI, z nowymi tematami jak testowanie generatywnej AI i dużych modeli językowych, testowanie eksploracyjne i red teaming oraz zgodność z ISO/IEC 25059; format egzaminu ISTQB pozostał bez zmian, czyli 40 pytań w 60 minut z progiem zdania 65 procent i 25 procentami dodatkowego czasu przy egzaminie w języku innym niż ojczysty. Skoro nawet ISTQB rozdzielił te dwa tematy dopiero teraz, to uczciwy sygnał, że kanonu dobrych praktyk jeszcze nie ma i Wasze własne wnioski z pilotaży warto spisywać u siebie, bo za rok będą cenniejsze niż niejeden podręcznik. Tomasz Stelmach przeprowadził w Quality Island ponad 40 wdrożeń AI w procesach testów i jakości oprogramowania, a esencję tych doświadczeń zebraliśmy też w formie zdalnej jako kurs online o AI w testowaniu oprogramowania.

Jak zmierzyć pilotaż, żeby wynik był wiarygodny

Typowy scenariusz, który widzimy u naszych klientów: dwa tygodnie entuzjazmu, repozytorium puchnie o 300 wygenerowanych testów, po miesiącu nikt nie umie ich utrzymać i nikt nie potrafi powiedzieć, czy było warto. Dzieje się tak, bo pilotaż ruszył bez punktu odniesienia i bez daty decyzji. Dobry pomiar wygląda tak, jak w projekcie automatyzacji dla Argos z naszego portfolio: najpierw punkt odniesienia, czyli regresja przed wydaniem trwająca 5 dni, potem wynik po zmianie, czyli 10 godzin. Podkreślmy uczciwie: to był projekt automatyzacji testów, nie wdrożenie AI, i przywołujemy go wyłącznie jako wzorzec liczenia efektu na twardej mierze, przed i po. Wasz pilotaż AI zasługuje na tę samą dyscyplinę:

Czego nie mierzyć? Liczby wygenerowanych testów. To najłatwiejsza metryka na świecie i jednocześnie najbardziej myląca, bo model wyprodukuje ich tyle, ile poprosicie, a każdy odrzucony w przeglądzie kosztował czyjś czas dwa razy: raz przy generowaniu, raz przy czytaniu. Wniosek dla Was: liczcie to, co przeszło przegląd i zostało w repozytorium, resztę traktujcie jak brudnopis. Aktualny przegląd tego, co w AI dla QA już działa, a co jeszcze nie, prowadzimy na bieżąco na Strefie QA.

Od czego zacząć w tym tygodniu

Trzy ruchy, każdy mieści się w jednym dniu roboczym. Po pierwsze, wybierzcie jedno zadanie z tabeli decyzyjnej, najlepiej dane testowe albo szkic przypadków, bo tam błąd widać najszybciej. Po drugie, zapiszcie czas bazowy: ile godzin zajęło Wam ostatnie takie zadanie zrobione ręcznie, bo bez tej liczby nigdy nie będziecie wiedzieć, czy coś zyskaliście. Po trzecie, uruchomcie szablon z sekcji drugiej na jednym prawdziwym wymaganiu z Waszego projektu i policzcie, ile z wygenerowanych przypadków przeszło Wasz przegląd bez poprawek.

A jeśli po tym eksperymencie uznacie, że chcecie przejść dalej z kimś, kto już się na tym sparzył za Was, to wiecie, gdzie nas szukać: robimy wdrożenia AI w procesie testów od planu pomiaru po pracę na Waszym kodzie, a terminy najbliższych warsztatów znajdziecie w kalendarzu szkoleń. Bez nacisku: szablon i tabela z tego artykułu wystarczą, żeby zacząć samodzielnie.

Powiązane na blogu Quality Island

• Agentic testing: czy Wasza praca właśnie się zmienia, czy znika
• Metryki DORA psują się w erze AI: dlaczego szybkość wydawania przestaje być dowodem jakości
• AI Act: testowanie systemów wysokiego ryzyka, test stronniczości i terminy 2027
• Testowanie systemów AI: jak zapewnić jakość w erze sztucznej inteligencji

Pełna lista źródeł

• Capgemini, Sogeti i OpenText, World Quality Report 2025, 17. edycja, listopad 2025, capgemini.com. Stąd próba ponad 2 000 osób z kadry kierowniczej z 22 krajów, 89 procent pilotujących, 15 procent w skali organizacji, 11 procent nieużywających, 19 procent wzrostu produktywności i bariery skalowania.
• Stack Overflow, Developer Survey 2025, sekcja AI, 2025, survey.stackoverflow.co. Stąd 84 procent używających albo planujących, 33 i 46 procent zaufania i braku zaufania, 66 procent o odpowiedziach prawie dobrych i 45,2 procent o czasie debugowania.
• Nadia Alshahwan i inni (Meta), „Automated Unit Test Improvement using Large Language Models at Meta”, arXiv 2402.09171, 2024, arxiv.org. Stąd 75, 57 i 25 procent dla testów zbudowanych, stabilnych i podnoszących pokrycie oraz 73 procent rekomendacji przyjętych do produkcji.
• ISTQB, Certified Tester AI Testing, zmiany w wersji 2.0 sylabusa, 2026, istqb.org. Stąd skrócenie sylabusa z 11 rozdziałów do 7, przeniesienie treści o używaniu AI do testowania do certyfikacji CT-GenAI i format egzaminu.
• Dane własne Quality Island, 2026: ponad 450 000 napisanych testów automatycznych, ponad 152 zrealizowane projekty, ponad 40 wdrożeń AI w procesach testów i jakości oprogramowania, wyniki projektu dla Argos (regresja z 5 dni do 10 godzin).