Prompt, Review, Deliver – dokumentacja QA w erze AI

Kiedy ostatnio z własnej woli spisałeś procedury testowe w swoim projekcie?

Nie dlatego, że ktoś tego wymagał. Dlatego, że chciałeś mieć porządek, albo żeby kolejna osoba w zespole nie pytała cię o to samo po raz piąty. Jeśli odpowiedź brzmi „nie pamiętam", witaj w klubie. Jesteśmy w nim prawie wszyscy.

Dokumentacja QA ma problem wizerunkowy. Kojarzy się z pracą magisterską: pisanie zajmuje tygodnie, a czytanie… cóż, rzadko kto ma na to czas. Tymczasem koszt jej braku jest całkiem realny i policzalny.

Ile kosztuje brak dokumentacji

Weźmy trzy scenariusze, które widział zapewne każdy, kto pracował w większym projekcie przez kilka lat.

Onboarding. Nowy tester wchodzi do zespołu, nie ma aktualnej dokumentacji, więc przez 2 – 4 tygodnie gania ludzi po Slackach i Teamsach, zadaje pytania, na które odpowiedzi dawno powinny być zapisane. Mnożymy to przez stawkę godzinową wszystkich zaangażowanych i nagle okazuje się, że brak jednego dokumentu kosztował firmę kilkanaście tysięcy złotych. Albo i więcej.

Retencja wiedzy i awarie. Odchodzą dwie osoby, które „miały to w głowie". W piątek wieczorem coś pada na produkcji. Łatwiej jest naprawiać coś, co wiemy jak działa – albo przynajmniej mamy do tego dokumentację. Bez tego dzwonimy do testera, bo najczęściej jest to osoba, która na tyle już napsuła w aplikacji, że „na pewno wie". Agenci AI już potrafią skrócić downtime kilkukrotnie poprzez pomoc w troubleshootingu na podstawie kodu i dokumentacji. Ale żeby to zadziałało, ta dokumentacja musi gdzieś istnieć.

Wymogi prawne i certyfikacje. W regulowanych branżach (finanse, pharma, administracja) prowadzenie i utrzymanie dokumentacji wynikają z konkretnych zapisów. Przykłady? DORA, ISO 27001, GxP, NIS2. Zaniedbanie na tym polu potrafi zablokować wielomilionowy kontrakt Enterprise albo doprowadzić do nałożenia kar lub cofnięcia certyfikacji. I wtedy nagle management zaczyna biegać z pianą na ustach. 

Co AI zmienia w procesie

Dobra wiadomość: AI potrafi wyprodukować ogromną ilość tekstu. Od przypadków testowych po plany testów, strategie, macierze śledzalności, dokumentację testów automatycznych, analizy logów. Zła wiadomość: duża część tego tekstu to bzdury. Czasami bardzo przekonujące bzdury.

Zmiana, którą AI wymusza, jest bardziej w roli testera, niż w narzędziach. Zamiast siedzieć przed szarym ekranem (lub białym – nie oceniam) i próbować zebrać myśli po pięciu godzinach testowania, dostajesz w kilka minut gotowy draft. Nie jest idealny, ani gotowy do wysłania, ale to coś, od czego możesz zacząć. Przesuwasz się więc z pozycji autora na pozycję redaktora. „Senior Reviewer" zamiast „Junior Writer z pustym dokumentem".

Dlaczego review jest ważniejszy niż prompt

AI w roli generatora dokumentacji jest jak zdolny junior. Pisze szybko, zna szablony, formatuje ładnie. Nie zna kontekstu Twojego projektu, znajomości wymagań klienta (tych spisanych i nie), historii zmian. I z pełną pewnością siebie wygeneruje coś, co wygląda profesjonalnie i brzmi rozsądnie. Z tym, że gdy się wczytasz okaże się, że to wszystko jest merytorycznie błędne.

„AI nie ma NIP-u". Tak stwierdziliśmy z Tomkiem Szyborskim podczas prezentacji na QA Summit 2026. AI nie poniesie odpowiedzialności prawnej za błędy w dokumentacji. Audytor nie przyjmie tłumaczenia „model tak wygenerował". Jeśli jesteś na B2B, odpowiadasz za to całym majątkiem. Na UoP, co do zasady trzykrotnością pensji. W obu przypadkach review to różnica pomiędzy dużą oszczędnością, a dużym problemem.

Weryfikuj merytorykę, a dopiero później stylistykę – jeśli wystarczy czasu. To ważna kolejność. Łatwo się wciągnąć w poprawianie przecinków, usuwanie długich myślników i przeredagowywanie “zasady trzech”. A tymczasem trzeci akapit zawiera halucynację, która w test planie zamieni się w pominięty scenariusz i w konsekwencji awarię na produkcji.

Jak ustawić fundament: persona, kontekst, instrukcje

Zanim w ogóle zaczniesz pisać prompty do konkretnych dokumentów, musisz zrobić coś, co dużo osób pomija: ustawić bazę. Przez „bazę" rozumiem:

1. Persona modelu. Kim ma być AI w kontekście Twojej pracy? Doświadczonym testerem w bankowości? Specjalistą od automatyzacji w pharma? Persona wpływa na ton, poziom szczegółowości i to, jakie założenia model przyjmie domyślnie.
2. Kontekst ogólny. Jaki projekt, jaka metodyka, jakie narzędzia. Jeśli pracujesz w Jirze z Confluence i Xray, model powinien o tym wiedzieć zanim go o cokolwiek poprosisz. Podaj mu stack technologiczny. A jeśli Twoja firma ma specyficzne szablony albo naming conventions, to też ważne informacje. 
3. Instrukcje systemowe. Format wyjściowy, ograniczenia (np. „jeśli nie masz pewności, napisz: DO UZUPEŁNIENIA"), wzorce few-shot, czyli przykłady dobrych i złych odpowiedzi, które kalibrują model.
4. Narzędzia i rozszerzenia. Warto też zastanowić się, jakie pluginy, connectory czy MCP-y (Model Context Protocol) mogą być przydatne w Twoim workflow. Czy model może mieć dostęp do Jiry? Do Google Drive z dokumentacją projektu? Do systemu zarządzania testami? Włączenie (a czasami opracowanie) odpowiednich integracji przed rozpoczęciem pracy potrafi zrobić ogromną różnicę w jakości wyników.

Definiując podstawy, masz fundamenty do dalszej pracy. Bez nich każdy prompt zaczyna od zera i wynik jest totalnie nieprzewidywalny.

Framework 3K: Kontekst, Kontekst, Kontekst

Gdy mamy już opisane podstawy, pora na prompt. Aby nie przepalać tokenów nadaremno, proponuję prostą zasadę do zapamiętania. Nazywam to frameworkiem 3K, żeby łatwo zapamiętać: Kontekst, Kontekst, Kontekst (parafrazując ze słynnego “Location, Location, Location”).

1. Kontekst #1: Kim jestem? Moja rola w tym konkretnym dokumencie. Nie ogólnie „tester", ale „Senior QA engineer odpowiedzialny za testy wydajnościowe modułu płatności w systemie bankowym". Im precyzyjniej, tym lepszy wynik.
2. Kontekst #2: Co chcę osiągnąć? Cel biznesowy dokumentu i oczekiwany format. Chcę test plan? Macierz śledzalności? Przypadki testowe w formie tabeli? A może scenariusze w Gherkin? Każdy z tych formatów wymaga innego podejścia.
3. Kontekst #3: Dla kogo piszę? Kto przeczyta ten dokument? Product Owner, developer, audytor ISO, tester UAT, manager nie-techniczny? To zmienia język, poziom szczegółowości, nawet strukturę dokumentu.

Moje doświadczenie: różnica między promptem bez kontekstów a promptem z pełnym 3K to jak różnica między „napisz mi test plan" a dokumentem, który po review faktycznie nadaje się do użycia. Pamiętajmy – “garbage in, garbage out”. Niby banał, ale w kontekście LLM pozwala zaoszczędzić czas, frustrację i tokeny.

Jak to wygląda w praktyce

Konkretny przykład z prezentacji. Kolega, Tomasz Szyborski, opowiadał o swoim doświadczeniu z dokumentacją testów wydajnościowych. Kiedyś tworzenie takiego dokumentu od zera dla dużej organizacji zajmowało mu kwartał (tworzenie, uwagi od stakeholderów, poprawki…). Wynik: 80 stron, jak dobra praca magisterska. Ze wsparciem AI, z odpowiednim kontekstem i solidnym review, tworzy porównywalny draft w ciągu jednego dnia.

W innym scenariuszu: dostarczenie AI wymagań biznesowych jako input skutkowało wygenerowaniem 21 przypadków testowych w 6 grupach (happy path, testy negatywne, walidacja logów) plus “z automatu” utworzenie traceability matrix. W kilka minut. Oczywiście po review część z nich trafiła do kosza albo wymagała przeróbek, ale punkt wyjścia był lepszy niż “pusta kartka”.

Ogólnie szacuję, że AI uwalnia od 20% do 40% czasu testera. Ten czas nie idzie na picie kawy. Przechodzi z mechanicznego klepania tekstu na analizę i myślenie krytyczne. Czyli na to, za co tak naprawdę powinniśmy być opłacani.

Podczas sesji Q&A na QA Summit padło pytanie o mierzenie opłacalności. Najprościej: loguj czas per zadanie przed i po wdrożeniu AI do swojego workflow. Bez twardych danych ciężko przekonać organizację, a „czuję, że jest szybciej" nie wystarczy na spotkaniu z budżetem.

Trenuj swojego LLM-a

Coś, o czym rzadko się mówi w kontekście dokumentacji QA: feedback loop.

Po review dokumentu, który wygenerował mi Claude, piszę krótki feedback i każę mu zapamiętać, na co ma zwracać uwagę w przyszłości. Czasami wrzucam poprawiony przeze mnie tekst i proszę o przeanalizowanie poprawek i zapamiętanie wniosków. Nie chodzi o jednorazowy prompt. Chodzi o systematyczne kalibrowanie modelu pod swoje potrzeby.

Czy to działa? Zazwyczaj tak. Z doświadczenia wiem, że niektóre modele lepiej korzystają z zapamiętanego feedbacku, inne gorzej. Warto przetestować to we własnym zakresie. Tak, przepalisz kilka tokenów, ale potencjalny zysk to LLM, który z czasem coraz lepiej rozumie Twój kontekst, styl i preferencje.

Bezpieczeństwo: kiedy AI to ryzyko, nie zysk

Tu muszę być bezpośredni, bo to temat, przy którym widziałem ludzi tracących pracę.

Dane osobowe (PII), logi z produkcji, kody źródłowe objęte NDA. To nie może trafiać do chmury publicznej bez odpowiednich umów (DPA). Brzmi oczywiste? Spotkałem już przypadki spektakularnych wylotów z pracy po nieumiejętnym posługiwaniu się LLM-em. I nie mówię tu o juniorach.

W sektorze finansowym czy farmaceutycznym mamy do czynienia z takimi wytycznymi, jak np. RODO, NIS2, DORA. Polityka AI w firmie powinna określać, co wolno, czego nie wolno i jakie narzędzia są zatwierdzone. Niektóre firmy już mają takie polityki, inne jeszcze nie. Ale brak polityki nie oznacza braku odpowiedzialności.

Podstawowy filtr bezpieczeństwa sprowadza się do jednego pytania: „Czy te dane mogą legalnie opuścić moją firmę?" Jeśli odpowiedź brzmi „nie" albo „nie wiem", nie wysyłasz ich do żadnego modelu w chmurze. Nawet jeśli odznaczyłeś checkbox “Zezwalam na wykorzystywanie moich danych do trenowania modelu”. Koniec dyskusji.

Jeśli pracujesz w większej organizacji, jest spora szansa, że firma już wdrożyła lub wdraża lokalne instancje LLM dopuszczone do użytku wewnętrznego. Warto zapytać, zanim zaczniemy budować coś na własną rękę.

Dla tych, którzy chcą postawić coś samodzielnie (freelancerzy, mniejsze zespoły), jest kilka sprawdzonych opcji. Ollama jako silnik inferencyjny plus Obsidian jako notatnik z kontekstem to jedna ścieżka. Dla osób, które wolą graficzny interfejs przypominający ChatGPT, proponuję LM Studio albo Open WebUI z lokalnym modelem (Llama, Gemma) – pozwalają rozpocząć bez dotykania terminala. Dane nie opuszczają Twojego komputera, nie ma telemetrii, nie trzeba nawet zakładać konta. Jakość i tempo generowania będą niższe niż u dużych modeli komercyjnych, ale za to masz pełną kontrolę. Oczywiście pod warunkiem, że dysponujesz sprzętem, który takie modele obsłuży. I tutaj mam dobrą wiadomość – niewielkie modele są coraz bardziej użyteczne, a sprzęt w rozsądnych kwotach – coraz bardziej wydajny. 

Niezależnie od wybranej ścieżki, zawsze warto upewnić się, że Twój setup jest zgodny z polityką AI obowiązującą w organizacji, dla której pracujesz. A parafrazując klasyka: organizacje dzielą się na takie, które mają politykę AI, i te, które będą miały politykę AI.

Ekonomia tokenów: o czym nikt nie mówi

Wątek, który rzadko pojawia się na konferencjach QA, a który warto mieć z tyłu głowy. Dostawcy LLM na razie działają „pod wodą", paląc pieniądze inwestorów. Ci natomiast oczekują, że ich inwestycje zaczną z czasem przynosić zyski. To oznacza, że obecne ceny tokenów i darmowe plany to okres promocyjny, nie stan docelowy.

Firmy, które szybko uzależniają swoje procesy od AI, mogą za kilka lat obudzić się w sytuacji, gdzie vendor podnosi ceny, a wycofanie się jest zbyt kosztowne, bo cały workflow został zbudowany wokół konkretnego modelu. Warto mieć to z tyłu głowy. Powinniśmy LLM traktować jako narzędzie w naszym arsenale, ale nie jako fundament, na którym stoi cały proces.

Podsumowanie

Workflow „Prompt, Review, Deliver" to ewolucja narzędzi. AI skraca czas tworzenia dokumentacji z tygodni do godzin, ale to wiedza domenowa i krytyczne oko testera decydują o jakości wyniku.

Cztery rzeczy na wynos:

1. Sprawdź, czy i jak możesz używać LLM w swojej organizacji.
2. Stwórz fundament (persona, kontekst ogólny, instrukcje) zanim zaczniesz pisać prompty. 
3. Dla każdego dokumentu zdefiniuj 3K: kim jestem, co chcę osiągnąć, dla kogo piszę. 
4. Traktuj review jako najważniejszy etap procesu, a nie formalność.

AI to dobry młotek. Ale warto patrzeć, gdzie uderzasz.

Prezentacja „Prompt, review, deliver — dokumentacja QA w erze AI" została wygłoszona wspólnie z Tomaszem Szyborskim na QA Summit 2026 (22 kwietnia 2026). Slajdy: SpeakerDeck. Nagranie: YouTube.