Kiedy prompt przestaje wystarczać - sygnały, że czas zbudować własne narzędzie QA
Cztery poziomy pracy z AI w testowaniu
Jest taki moment w pracy z AI, który łatwo przegapić. Otwierasz czat, wklejasz prompt, który znasz już prawie na pamięć, dopisujesz kontekst projektu, który tłumaczyłeś modelowi w zeszłym tygodniu, i poprawiasz wynik dokładnie w tych samych miejscach co ostatnio. Formalnie używasz AI, więc wszystko wygląda na nowoczesne i szybkie. W praktyce wykonujesz ręcznie powtarzalny proces, tylko że jego środkowy krok odbywa się w oknie czatu.
Większość rozmów o AI w testowaniu kręci się wokół promptów: jak je pisać, jakie role nadawać modelowi, ile przykładów dorzucić. To ważne i sam do tego wracam, ale prompt ma swój sufit. W pewnym momencie dalsze dopieszczanie instrukcji daje coraz mniej, a problemem przestaje być jakość odpowiedzi, tylko to, że za każdym razem musisz ten proces uruchomić, nakarmić danymi i posprzątać po nim samodzielnie.
Dlatego zamiast pytać "jak napisać lepszy prompt", warto czasem zapytać "czy to w ogóle powinien być prompt". Poniżej opisuję, jak na to patrzę: jako na drabinę z czterema poziomami, gdzie każdy kolejny oszczędza więcej czasu, ale wymaga trochę więcej przygotowania i odpowiedzialności.
Cztery poziomy pracy z AI w testowaniu
Nie traktuję tych poziomów jak oceny, kto jest "lepszym" testerem. To raczej mapa, która pomaga zdecydować, ile wysiłku warto włożyć w konkretne zadanie. To samo zadanie u jednej osoby może spokojnie zostać na poziomie czatu, a u innej - robione codziennie i dla całego zespołu - aż prosi się o narzędzie.
Czat - pytasz AI na bieżąco, bez przygotowania: "napisz przypadki testowe do tego formularza", "popraw opis tego zgłoszenia".
Biblioteka promptów - masz sprawdzone prompty do zadań, które powtarzasz, i nie wymyślasz ich za każdym razem od zera.
Prompt z kontekstem projektu - instrukcja zna Twój projekt: reguły domenowe, format zgłoszeń, konwencje nazewnictwa, typowe ryzyka.
Własne narzędzie - z pomocą AI budujesz mały program, skrypt albo aplikację, które wykonują zadanie bez ręcznego wklejania promptów.
Każdy poziom rozwiązuje inny problem i każdy ma swoją cenę. Zanim przejdę do sygnałów, że warto wejść wyżej, przyjrzyjmy się, co dzieje się na każdym stopniu.
Poziom 1 - czat, czyli szybko i od zera
Czat jest najlepszym miejscem na start i na zadania jednorazowe. Nie wymaga żadnego przygotowania, odpowiedź masz w kilka sekund, a przy pytaniach eksploracyjnych - "jakie ryzyka widzisz w tej funkcji?" - często daje dobry punkt wyjścia do rozmowy z zespołem. Jeśli dane zadanie zdarza Ci się raz na kwartał, nie ma sensu budować wokół niego czegokolwiek więcej.
Problem zaczyna się wtedy, gdy czat staje się jedynym sposobem pracy z AI. Model nie pamięta, że Twój projekt ma specyficzne reguły walidacji, że zgłoszenia piszecie w konkretnym formacie albo że pewnych ścieżek nie da się przetestować na środowisku testowym. Za każdym razem tłumaczysz to od nowa, a jakość wyniku zależy od tego, ile kontekstu akurat chciało Ci się wpisać.
Efekt uboczny jest mniej oczywisty: wyniki stają się nieporównywalne. Dwa zgłoszenia błędów poprawione przez AI w tym samym tygodniu mogą wyglądać zupełnie inaczej, bo za każdym razem prompt był trochę inny. Dla jednej osoby to drobiazg, ale w zespole, który próbuje utrzymać spójny standard zgłoszeń, zaczyna to przeszkadzać.
Poziom 2 - biblioteka promptów, czyli powtarzalna jakość
Drugi poziom to moment, w którym zauważasz, że część zadań wraca regularnie, i zapisujesz prompty, które działają. Może to być notatka, plik w repozytorium albo wspólna baza w zespole. Zyskujesz stałą jakość: ten sam prompt daje podobny wynik, łatwiej go poprawiać i można się nim podzielić z kimś, kto dopiero zaczyna.
Na tym poziomie pojawia się też coś, czego czat nie daje - możliwość iterowania. Jeśli prompt do generowania przypadków testowych regularnie pomija przypadki brzegowe, poprawiasz go raz i problem znika we wszystkich kolejnych użyciach. To pierwsza forma "inżynierii" w pracy z AI: przestajesz traktować model jak rozmówcę, a zaczynasz traktować prompt jak artefakt, który ma swoją historię zmian.
Ograniczenie jest jedno, ale istotne: nadal wszystko robisz ręcznie. Kopiujesz prompt, wklejasz dane, przenosisz wynik do Jiry, arkusza albo repozytorium. Jeśli zadanie zajmuje pięć minut i robisz je raz w tygodniu, to w porządku. Jeśli robisz je kilka razy dziennie, te pięć minut zaczyna się sumować w godziny, które nie mają nic wspólnego z testowaniem.
Jeśli chcesz zacząć od tego poziomu, nie musisz budować biblioteki od zera. W Prompt Hubie dla testerów i QA zebrałem prompty do codziennej pracy - Playwright, Swagger, DevTools, CI/CD i testy manualne - rozwijane razem ze społecznością: https://prompty.rwasik.pl/
Poziom 3 - prompt, który zna Twój projekt
Trzeci poziom to prompt, który przestaje być uniwersalny. Zamiast "napisz przypadki testowe do formularza" masz instrukcję, która zawiera reguły domenowe projektu, przykładowe dane, format, w jakim zespół zapisuje przypadki, i listę ryzyk, które w tym systemie wracają najczęściej. Wynik pasuje do projektu bez długiego poprawiania, bo model dostaje to, czego wcześniej musiał się domyślać.
W praktyce ten poziom często wygląda jak szablon z miejscami do uzupełnienia albo jak projekt w narzędziu AI z dołączoną dokumentacją. Różnica względem poziomu drugiego jest taka, że wiedza o projekcie przestaje siedzieć tylko w Twojej głowie. Zostaje zapisana w sposób, który działa także wtedy, gdy z promptu korzysta ktoś inny z zespołu albo Ty po trzech tygodniach urlopu.
Tu jednak łatwo przecenić, ile da się osiągnąć samym promptem. Prompt z kontekstem nadal wymaga, żebyś to Ty go uruchomił, dostarczył dane wejściowe i ocenił wynik. Jeśli zadanie składa się z kilku kroków - pobierz dane, przetwórz, porównaj, zapisz raport - to każdy z nich nadal przechodzi przez Twoje ręce. Właśnie w tym miejscu najczęściej pojawia się pytanie, czy to nie powinno być narzędzie.
Poziom 4 - własne narzędzie QA
Czwarty poziom to zmiana roli AI. Model przestaje być miejscem, w którym wykonujesz pracę, a staje się pomocnikiem przy budowaniu czegoś, co tę pracę wykonuje za Ciebie. Może to być generator danych testowych, skrypt porównujący odpowiedzi API między środowiskami, prosty analizator logów albo mała aplikacja webowa dla całego zespołu. Raz zbudowane narzędzie działa w kilka sekund i daje powtarzalny wynik niezależnie od tego, kto i kiedy je uruchomi.
Najważniejsze jest to, że nie musisz być programistą, żeby zbudować takie narzędzie. Musisz natomiast dobrze rozumieć problem, który rozwiązujesz, i umieć opisać go precyzyjnie - a to akurat jest codzienna praca testera. Wymagania, warunki brzegowe, kryteria akceptacji, przypadki negatywne: wszystko, co robisz przy analizie funkcji, jest dokładnie tym, czego AI potrzebuje, żeby zbudować sensowne narzędzie.
Ten poziom ma też swoją cenę, o której mówi się za rzadko. Narzędzie zbudowane z pomocą AI trzeba przetestować tak samo jak każde inne oprogramowanie. Model potrafi wygenerować kod, który wygląda poprawnie, przechodzi pierwsze uruchomienie i po cichu ignoruje część przypadków. Tester ma tu przewagę, bo weryfikowanie, czy coś naprawdę robi to, co obiecuje, jest jego zawodem - ale tylko wtedy, gdy z tej przewagi świadomie korzysta.
Sygnały, że czas wejść poziom wyżej
Nie każde zadanie powinno skończyć jako narzędzie i to jest równie ważne jak sama drabina. Przejście na wyższy poziom ma sens wtedy, gdy koszt powtarzania zaczyna przewyższać koszt przygotowania. Oto sygnały, na które warto zwracać uwagę:
Wklejasz ten sam prompt po raz kolejny w tym samym celu. To najprostszy sygnał, że czat powinien ustąpić miejsca bibliotece, a biblioteka - promptowi z kontekstem.
Za każdym razem dopisujesz ten sam kontekst projektu. Jeśli tłumaczysz modelowi reguły domeny po raz trzeci, ta wiedza powinna trafić do szablonu, a nie do Twojej pamięci.
Poprawiasz wynik w tych samych miejscach. Powtarzalne poprawki oznaczają, że problem leży w procesie, a nie w pojedynczej odpowiedzi modelu.
Zadanie ma kilka kroków i przenosisz dane między narzędziami. Kopiowanie z czatu do arkusza, z arkusza do Jiry i z powrotem to klasyczny kandydat na automatyzację.
Z tego samego procesu potrzebuje skorzystać ktoś jeszcze. Prompt w Twojej notatce pomaga Tobie, narzędzie pomaga całemu zespołowi.
Wynik musi być powtarzalny i porównywalny. Jeśli dwa uruchomienia tego samego zadania nie mogą się różnić, bo ktoś na ich podstawie podejmuje decyzję, czat jest złym miejscem na taki proces.
Jeden sygnał nie musi od razu oznaczać budowania narzędzia. Kiedy jednak przy jednym zadaniu zaczynasz odhaczać trzy albo cztery z tych punktów, to warto zatrzymać się na godzinę i policzyć, ile czasu ten proces zjada w skali miesiąca.
Czego nie robić na żadnym poziomie
Pierwszy błąd, na który łatwo wpaść przy wchodzeniu na wyższe poziomy, to przenoszenie zaufania razem z automatyzacją. Na poziomie czatu każdą odpowiedź czytasz uważnie, bo widzisz ją pierwszy raz. Na poziomie narzędzia wynik pojawia się w sekundę, wygląda profesjonalnie i bardzo łatwo przestać go sprawdzać. Tymczasem błąd w narzędziu powtarza się przy każdym uruchomieniu, więc jego koszt jest większy niż pojedyncza zła odpowiedź w czacie.
Drugi błąd to budowanie narzędzia do problemu, który nie istnieje. Jeśli zadanie zdarza się rzadko albo za każdym razem wygląda inaczej, narzędzie będzie wymagało więcej utrzymania, niż zaoszczędzi czasu. W takich sytuacjach dobry prompt z kontekstem projektu w zupełności wystarczy, a czas lepiej przeznaczyć na proces, który naprawdę się powtarza.
Trzeci błąd to przeskakiwanie poziomów. Trudno zbudować sensowne narzędzie do procesu, którego nie umiesz jeszcze dobrze opisać w prompcie. Biblioteka i prompt z kontekstem to nie są etapy do odhaczenia, tylko sposób na zrozumienie, czego tak naprawdę oczekujesz od wyniku - a ta wiedza przydaje się dokładnie w momencie, gdy z AI zaczynasz budować narzędzie.
Co z tego wynika dla testera
Praca z AI w testowaniu coraz mniej przypomina zadawanie pytań, a coraz bardziej projektowanie procesów. Tester, który zatrzymuje się na poziomie czatu, korzysta z AI, ale wiele powtarzalnej pracy nadal wykonuje ręcznie. Tester, który potrafi rozpoznać, kiedy prompt przestaje wystarczać, i zamienić go w narzędzie, zyskuje coś więcej niż czas: zyskuje powtarzalność, którą może przekazać zespołowi.
Najciekawsze jest to, że kompetencje potrzebne na najwyższym poziomie to te same, które od lat definiują dobrego testera. Precyzyjne opisanie problemu, myślenie o przypadkach brzegowych i nieufność wobec wyniku, który "wygląda dobrze", są dziś tak samo potrzebne przy budowaniu narzędzi z AI, jak przy testowaniu cudzego kodu. AI zmienia narzędzia, ale nie zmienia tego, za co tester odpowiada.
Przy okazji: takiego podejścia - od pojedynczego promptu do własnych narzędzi QA, które realnie skracają codzienną pracę - uczę na warsztacie "Tester z AI". Szczegóły znajdziesz tutaj: https://ai.rwasik.pl/
