Testy akceptacyjne z promptów: przekształć funkcje w scenariusze

Dlaczego prompt funkcji często ukrywa wymagania

Prompty w stylu chatowym wydają się jasne, bo czyta się je jak rozmowę. Jednak często mieszczą w sobie wybory, reguły i wyjątki w kilku przyjaznych zdaniach. Luki wychodzą dopiero, gdy ktoś użyje funkcji w praktyce.

Większość promptów polega cicho na założeniach: kto może wykonać akcję, co liczy się jako „sukces” (zapisane, wysłane, opublikowane, opłacone), co się dzieje, gdy brakuje danych i co użytkownik powinien zobaczyć przy niepowodzeniu. Ukrywają też nieostre standardy typu „wystarczająco szybko” czy „wystarczająco bezpiecznie”.

Niejasności zwykle wychodzą późno jako bugi i prace naprawcze. Programista zbuduje to, co rozumie z promptu, reviewer zatwierdzi, bo wygląda dobrze, a potem użytkownicy napotkają dziwne przypadki: podwójne przesłania, strefy czasowe, częściowe dane czy niezgodności uprawnień. Poprawki później kosztują więcej, bo często dotykają kodu, tekstów interfejsu, a czasem modelu danych.

Jakość nie wymaga ogromnych zestawów testów. To zdolność do zaufania funkcji w normalnym użyciu i pod przewidywalnym obciążeniem. Mały zestaw dobrze dobranych scenariuszy daje to zaufanie bez setek testów.

Praktyczna definicja jakości dla funkcji zbudowanych z promptu:

• Główny cel użytkownika działa end‑to‑end (ścieżka szczęśliwa).
• Najważniejsze tryby błędów są obsłużone czysto (czytelne błędy, brak cichej korupcji danych).
• Funkcja zachowuje się spójnie (te same wejścia → ten sam wynik).
• Nic niebezpiecznego nie dzieje się przez przypadek (dostęp niewłaściwego użytkownika, podwójne akcje).

Właśnie po to przekształca się prompt w scenariusze akceptacyjne: weź nieostre żądanie i zamień je na 5–10 kontroli, które ujawniają ukryte reguły wcześnie. Nie próbujesz testować wszystkiego — chcesz złapać te błędy, które rzeczywiście się pojawiają.

Jeśli budujesz z szybkiego promptu w narzędziu vibe‑coding takim jak Koder.ai, wynik może wyglądać na kompletny, a i tak pominąć reguły brzegowe. Zestaw zwarte scenariuszy zmusza do nazwania tych reguł, gdy zmiany są jeszcze tanie.

Jak wygląda dobry scenariusz akceptacyjny

Scenariusz akceptacyjny to krótki, prosty opis działania użytkownika i rezultatu, który powinien zobaczyć.

Trzymaj się powierzchni: co użytkownik może zrobić i co produkt pokazuje lub zmienia. Unikaj wewnętrznych szczegółów jak tabele bazy, wywołania API, zadania w tle czy który framework jest używany. Te detale mogą mieć znaczenie później, ale czynią scenariusze kruche i trudniejsze do uzgodnienia.

Dobry scenariusz jest też niezależny. Powinien dać się łatwo uruchomić jutro na czystym środowisku, bez polegania na tym, że inny scenariusz został wcześniej uruchomiony. Jeśli scenariusz zależy od wcześniejszego stanu, powiedz to jasno w setupie (np. „użytkownik ma już aktywną subskrypcję”).

Prosty kształt, który działa

Wiele zespołów używa Given‑When‑Then, bo wymusza jasność bez zamieniania scenariuszy w pełną specyfikację.

Scenariusz jest zwykle „gotowy”, gdy ma jeden cel, jasny stan początkowy, konkretną akcję i widoczny rezultat. Powinien być binarny: każdy z zespołu może powiedzieć „pass” lub „fail” po jego uruchomieniu.

Przykład: „Given zalogowany użytkownik bez zapamiętanej metody płatności, when wybiera Pro i potwierdza płatność, then widzi komunikat o sukcesie i plan widoczny jako Pro na koncie.”

Jeśli budujesz w chat‑first builderze takim jak Koder.ai, stosuj tę samą zasadę: testuj zachowanie wygenerowanej aplikacji (to, czego doświadcza użytkownik), a nie to, jak platforma wyprodukowała kod.

Wybierz format scenariusza, którego zespół faktycznie użyje

Najlepszy format to ten, który ludzie będą pisać i czytać. Jeśli połowa zespołu używa długich narracji, a druga połowa pisze lakoniczne punkty, pojawią się luki, duplikaty i spory o sformułowania zamiast pracy nad jakością.

Given‑When‑Then działa dobrze, gdy funkcja jest interaktywna i stanowa. Prosta tabela sprawdza się, gdy masz reguły wejście‑wyjście i wiele podobnych przypadków.

Jeśli zespół jest podzielony, wybierz jeden format na 30 dni i dostosuj go potem. Jeśli reviewerzy ciągle pytają „co to znaczy sukces?”, zwykle znak, by przejść do Given‑When‑Then. Jeśli scenariusze stają się rozwlekłe, tabela będzie łatwiejsza do przejrzenia.

Cokolwiek wybierzesz, ustandaryzuj. Trzymaj te same nagłówki, ten sam czas i poziom szczegółu. Uzgodnij też, czego nie włączać: pixel‑perfect UI, implementację wewnętrzną i gadanie o bazie danych. Scenariusze powinny opisywać to, co widzi użytkownik i jakie gwarancje daje system.

Gdzie trzymać scenariusze, żeby nie zniknęły

Umieść scenariusze tam, gdzie praca już się odbywa i trzymaj je blisko funkcji.

Popularne opcje to przechowywanie ich obok kodu produktu, w ticketach w sekcji „Acceptance scenarios” lub w współdzielonym dokumencie z jedną stroną na funkcję. Jeśli używasz Koder.ai, możesz też trzymać scenariusze w trybie Planowania, żeby zostały z historią budowy wraz z snapshotami i punktami rollbacku.

Kluczowe jest, żeby były przeszukiwalne, jedno źródło prawdy i wymóg scenariuszy przed uznaniem, że development się zaczyna.

Krok po kroku: zamień jeden prompt funkcji na 5–10 scenariuszy

Zacznij od przepisania promptu jako celu użytkownika plus jasnej linii mety. Użyj jednego zdania dla celu (kto chce czego), potem 2–4 kryteriów sukcesu, które możesz zweryfikować bez kłótni. Jeśli nie możesz wskazać widocznego rezultatu, to jeszcze nie masz testu.

Następnie rozbierz prompt na wejścia, wyjścia i reguły. Wejścia to to, co podaje lub wybiera użytkownik. Wyjścia to to, co system pokazuje, zapisuje, wysyła lub blokuje. Reguły to „tylko jeśli” i „musi” ukryte między wierszami.

Potem sprawdź, od czego zależy działanie funkcji. Tu kryją się luki scenariuszowe: wymagane dane, role użytkowników, uprawnienia, integracje i stany systemu. Przykładowo, jeśli budujesz aplikację w Koder.ai, określ, czy użytkownik musi być zalogowany, mieć utworzony projekt lub spełniać warunki planu, zanim akcja będzie możliwa.

Teraz napisz najmniejszy zestaw scenariuszy, który udowodni, że funkcja działa: zwykle 1–2 ścieżki szczęśliwe, a potem 4–8 przypadków brzegowych. Każdy scenariusz skupiony na jednej przyczynie potencjalnego niepowodzenia.

Dobry wybór przypadków brzegowych to: brak lub nieprawidłowe wpisy, niezgodność uprawnień, konflikty stanu typu „już wysłane”, problemy z zależnościami zewnętrznymi jak timeouty i zachowanie przy odzyskiwaniu (czytelne błędy, bez częściowego zapisu).

Zakończ szybkim przeglądem „co może pójść nie tak?”. Szukaj cichych niepowodzeń, mylących komunikatów i miejsc, gdzie system mógłby stworzyć błędne dane.

Jak napisać ścieżkę szczęśliwą bez przesadnego analizowania

Scenariusz ścieżki szczęśliwej to najkrótsza, najbardziej normalna droga, gdzie wszystko idzie dobrze. Jeśli zrobisz ją nudną umyślnie, stanie się solidną podstawą, która ułatwia wykrycie przypadków brzegowych później.

Nazwij domyślnego użytkownika i domyślne dane. Użyj realnej roli, nie „Użytkownik”: „zalogowany klient z potwierdzonym e‑mailem” lub „Admin z uprawnieniami do edycji rozliczeń”. Potem określ najmniejsze przykładowe dane: jeden projekt, jedna pozycja na liście, jedna zapamiętana metoda płatności. To utrzymuje scenariusze konkretne i redukuje ukryte założenia.

Napisz najkrótszą drogę do sukcesu jako pierwszą. Usuń kroki opcjonalne i alternatywne przepływy. Jeśli funkcja to „Utwórz zadanie”, ścieżka szczęśliwa nie powinna zawierać filtrowania, sortowania ani edycji po utworzeniu.

Prosty sposób, by utrzymać to zwarte, to potwierdzić cztery rzeczy:

• Użytkownik widzi właściwy ekran lub stan w odpowiednim momencie.
• System pokazuje właściwy komunikat (sukces, potwierdzenie lub dalsza instrukcja).
• Dane są zapisane (co zostało przechowane, nie jak).
• Użytkownik może kontynuować (dostępna jest następna sensowna akcja).

Potem dodaj jeden wariant, który zmienia tylko jedną zmienną. Wybierz tę, która najczęściej się łamie później, np. „tytuł jest długi” lub „użytkownik nie ma istniejących elementów”, i zachowaj wszystko inne identyczne.

Przykład: jeśli prompt mówi „Dodaj toast 'Snapshot created' po zapisaniu snapshotu”, ścieżka szczęśliwa to: użytkownik klika Utwórz snapshot, widzi stan ładowania, otrzymuje „Snapshot created”, a snapshot pojawia się na liście z właściwym timestampem. Wariant jednego parametru to ten sam przebieg, ale z pustą nazwą i jasną regułą domyślnego nazewnictwa.

Praktyczne menu przypadków brzegowych do wyboru

Przypadki brzegowe to miejsce, gdzie kryje się większość bugów, i nie potrzebujesz ogromnego zestawu, żeby je złapać. Dla każdego promptu funkcji wybierz mały zestaw, który odzwierciedla realne zachowania i tryby awarii.

Typowe kategorie do wyciągnięcia:

• Problemy wejściowe (puste wartości, za długie, zły format, znaki specjalne).
• Problemy stanu (brak uprawnień, wygasła sesja, brak wymaganych danych, konto niezweryfikowane).
• Problemy konkurencji (podwójne kliknięcie wysyła dwa razy, dwie zakładki edytujące jednocześnie, retry po spinnerze).
• Problemy integracji (timeouty, niedostępny dostawca, częściowa awaria, limity rate).
• Problemy danych (duplikaty, rekord usunięty w trakcie, przestarzałe dane, problemy z zaokrąglaniem).

Nie każda funkcja potrzebuje każdej kategorii. Pole wyszukiwania bardziej dba o wejścia. Przepływ płatności bardziej o integracje i dane.

Wybierz przypadki brzegowe pasujące do ryzyka: duży koszt błędu (pieniądze, bezpieczeństwo, prywatność), wysoka częstotliwość, łatwo łamane przepływy, znane wcześniejsze błędy lub problemy trudne do wykrycia po fakcie.

Przykład: dla „zmiany planu subskrypcji” scenariusze, które często się opłacają, to wygaśnięcie sesji w trakcie checkoutu, podwójne kliknięcie „Potwierdź” i timeout dostawcy płatności, który pozostawia plan niezmieniony przy jednoczesnym pokazaniu jasnego komunikatu.

Przykład: prompt funkcji do zwartego zestawu scenariuszy

Przykładowy prompt funkcji (w prostym języku):

„Kiedy coś popsułem, chcę przywrócić aplikację do poprzedniego snapshotu, aby ostatnia działająca wersja znów była aktywna.”

Poniżej zwarty zestaw scenariuszy. Każdy jest krótki, ale precyzuje rezultat.

Ścieżki szczęśliwe (2)

S1 [Wymagane] Przywróć do najnowszego snapshotu

Given jestem zalogowany i jestem właścicielem aplikacji

When wybieram „Rollback” i potwierdzam

Then aplikacja wdraża poprzedni snapshot, a status aplikacji pokazuje nową wersję jako aktywną

S2 [Wymagane] Przywróć do wybranego snapshotu

Given przeglądam listę snapshotów dla mojej aplikacji

When wybieram snapshot „A” i potwierdzam rollback

Then snapshot „A” staje się wersją aktywną i widzę, kiedy został utworzony

Przypadki brzegowe (6)

S3 [Wymagane] Brak dostępu (auth)

Given jestem zalogowany, ale nie mam dostępu do tej aplikacji

When próbuję wykonać rollback

Then widzę błąd dostępu i rollback nie rozpoczyna się

S4 [Wymagane] Snapshot nie znaleziony (walidacja)

Given ID snapshotu nie istnieje (albo został usunięty)

When próbuję do niego przywrócić

Then dostaję jasny komunikat „snapshot nie znaleziony”

S5 [Wymagane] Podwójne wysłanie (duplikaty)

Given klikam „Potwierdź rollback” dwa razy szybko

When wysłane zostaje drugie żądanie

Then tylko jeden rollback się uruchamia i widzę pojedynczy wynik

S6 [Wymagane] Błąd wdrożenia (awaria)

Given rollback się rozpoczął

When wdrożenie kończy się błędem

Then aktualna wersja pozostaje aktywna, a błąd jest pokazany

S7 [Opcjonalne] Timeout lub utrata połączenia

Given moje połączenie zrywa się w połowie rollbacku

When odświeżę stronę

Then widzę, czy rollback nadal trwa, czy się zakończył

S8 [Opcjonalne] Już na tym snapshocie

Given snapshot „A” jest już aktywny

When próbuję przywrócić do snapshotu „A”

Then informują mnie, że nic się nie zmieniło i żadne nowe wdrożenie nie startuje

Każdy scenariusz odpowiada na trzy pytania: kto to robi, co robi i co musi być prawdziwe po akcji.

Jak utrzymać wysokie pokrycie przy małych zestawach

Celem nie jest „przetestować wszystko”. Celem jest pokryć ryzyka, które zaszkodzą użytkownikom, bez tworzenia sterty scenariuszy, których nikt nie uruchamia.

Jedna praktyczna sztuczka to oznaczanie scenariuszy według sposobu ich użycia:

• Smoke: 1–2 scenariusze, które udowadniają end‑to‑end, że funkcja działa.
• Regression: 2–6 scenariuszy dla ważnych reguł i przeszłych bugów.
• Exploratory: kilka „spróbuj tego” dla dziwnych przypadków i oceny UX.

Ogranicz się do jednego scenariusza na odrębne ryzyko. Jeśli dwa scenariusze zawodzą z tego samego powodu, prawdopodobnie potrzebujesz tylko jednego. „Nieprawidłowy format e‑mail” i „brak e‑maila” to różne ryzyka. Ale „brak e‑maila w Kroku 1” i „brak e‑maila w Kroku 2” mogą być tym samym ryzykiem, jeśli reguła jest identyczna.

Unikaj też powielania kroków UI w wielu scenariuszach. Trzymaj powtarzające się części krótkie i skup się na tym, co się zmienia. To jeszcze ważniejsze przy budowie w chat‑based narzędziu jak Koder.ai, bo UI może się przesuwać, gdy reguła biznesowa pozostaje ta sama.

Wreszcie, zdecyduj, co sprawdzać teraz, a co później. Część kontroli lepiej robić ręcznie na początku, a potem automatyzować, gdy funkcja się ustabilizuje:

• Manualnie teraz: sformułowania, układ, stany wizualne, momenty „wydaje się mylące”.
• Automatyzować wkrótce: obliczenia, uprawnienia, poprawność zapisu danych, krytyczne przepływy.
• Automatyzować później: rzadkie quarki urządzeń, nietypowe timingi przeglądarki, awarie zewnętrznych usług.

Typowe błędy, które czynią scenariusze bezużytecznymi

Scenariusz powinien chronić przed niespodziankami, nie opisywać, jak zespół planuje zbudować funkcję.

Najczęstszy błąd to zamienienie celu użytkownika w checklistę techniczną. Jeśli scenariusz mówi „API zwraca 200” albo „tabela X ma kolumnę Y”, wiąże cię to z jednym rozwiązaniem i wciąż nie dowodzi, że użytkownik dostał to, czego potrzebował.

Innym problemem jest łączenie wielu celów w jeden długi scenariusz. Wygląda jak pełna podróż, ale gdy zawiedzie, nikt nie wie dlaczego. Jeden scenariusz powinien odpowiadać na jedno pytanie.

Uważaj też na przypadki brzegowe, które brzmią sprytnie, ale nie są realistyczne. „Użytkownik ma 10 milionów projektów” czy „sieć pada co 2 sekundy” rzadko odpowiadają produkcji i są trudne do odtworzenia. Wybieraj przypadki, które możesz przygotować w kilka minut.

Unikaj też niejasnych wyników typu „działa”, „bez błędów” czy „zakończono pomyślnie”. Te słowa ukrywają dokładny rezultat, który trzeba zweryfikować.

Krótki przykład „użyteczne” vs „bezużyteczne”

Jeśli budujesz funkcję eksportu źródeł jak w Koder.ai, słaby scenariusz to: „Gdy użytkownik kliknie eksport, system zipuje repo i zwraca 200.” Testuje to implementację, nie obietnicę.

Lepszy scenariusz: „Given projekt z dwoma snapshotami, when użytkownik eksportuje, then pobrany plik zawiera kod bieżącego snapshotu, a log eksportu zapisuje kto i kiedy eksportował.”

Nie zapomnij ścieżek „nie”: „Given użytkownik bez uprawnienia do eksportu, when próbuje eksportować, then opcja jest ukryta lub zablokowana i nie tworzy się żaden rekord eksportu.” Jedna linia może ochronić zarówno bezpieczeństwo, jak i integralność danych.

Szybka checklista przed zaakceptowaniem zestawu scenariuszy

Przed uznaniem zestawu za „gotowy”, przeczytaj go jak wybredny użytkownik i jak administrator bazy. Jeśli nie potrafisz powiedzieć, co musi być prawdą przed testem, albo co znaczy „sukces”, to nie jest gotowe.

Dobry zestaw jest mały, ale konkretny. Powinieneś móc przekazać go komuś, kto nie pisał funkcji, i otrzymać te same wyniki.

Użyj tego szybkiego przeglądu by zatwierdzić (albo odesłać) scenariusze:

• Każdy scenariusz ma jeden jasny warunek wstępny i jeden główny wynik.
• Oczekiwane rezultaty obejmują to, co użytkownik widzi i co zostaje zapisane.
• Uprawnienia są uwzględnione tam, gdzie mają znaczenie (przynajmniej jeden przypadek dozwolony i jeden odmowny).
• Ważne integracje mają przynajmniej jeden realistyczny tryb awarii.
• Zestaw pozostaje w zakresie 5–10 scenariuszy, bez powtórzeń.

Jeśli generujesz scenariusze w chat‑based builderze jak Koder.ai, trzymaj ten sam standard: żadnego ogólnego „działa jak oczekiwano”. Żądaj obserwowalnych wyników i zapisanych zmian, a zatwierdzaj tylko to, co możesz zweryfikować.

Następne kroki: włącz prompt→testy do swojego workflowu

Zrób ze scenariuszy realny krok procesu, nie sprzątanie na końcu.

Pisz scenariusze zanim zacznie się implementacja, gdy funkcję wciąż można tanio zmienić. Zmusza to zespół do odpowiedzi na niewygodne pytania wcześnie: co znaczy „sukces”, co się dzieje przy złym wejściu i czego jeszcze nie będziemy wspierać.

Używaj scenariuszy jako wspólnej definicji „done”. Product odpowiada za intent, QA za myślenie o ryzyku, engineering za wykonalność. Gdy wszyscy trzej czytają ten sam zestaw scenariuszy i zgadzają się, unikasz wysyłania czegoś „ukończonego”, ale nieakceptowalnego.

Workflow, który sprawdza się w większości zespołów:

• Zamień każdy prompt funkcji na 5–10 scenariuszy, w tym 1 ścieżkę szczęśliwą i mały zestaw przypadków brzegowych.
• Szybko je przejrzyj i wyjaśnij otwarte pytania prostym językiem.
• Zaimplementuj to, co scenariusze opisują; dodaj scenariusz, jeśli w trakcie rozwoju pojawi się nowe wymaganie.
• Użyj scenariuszy jako checklisty akceptacyjnej podczas review, nie jako ogólnego „wygląda dobrze”.
• Aktualizuj scenariusze, gdy prompt się zmienia, żeby testy odpowiadały rzeczywistości.

Jeśli budujesz w Koder.ai, szkicowanie scenariuszy najpierw, a potem użycie Planning Mode może pomóc mapować każdy scenariusz na ekrany, reguły danych i widoczne dla użytkownika rezultaty zanim wygenerujesz lub edytujesz kod.

Dla ryzykownych zmian zrób snapshot przed iteracją. Jeśli nowy przypadek brzegowy złamie działający przepływ, rollback może uratować dzień rozplątywania efektów ubocznych.

Trzymaj scenariusze obok zgłoszenia funkcji (lub w tym samym tickecie) i traktuj je jak wersjonowane wymagania. Gdy prompt ewoluuje, zestaw scenariuszy powinien iść za nim, inaczej Twoje „gotowe” cicho się rozjedzie.