Sztuka pisania przypadków testowych. Pisz przypadki testowe jak Stephen King i Kurt Vonnegut

My cenimy w naszych książkach głębię, jaką daje jednoczesne oglądanie wielu pięknych momentów życia.

Kurt Vonnegut, Rzeźnia numer pięć

Co mają wspólnego autor Lśnienia i twórca Rzeźni numer pięć z technicznymi przypadkami testowymi? Więcej niż się wydaje. Bo dobry test to nie tylko ciąg kroków do wykonania. To także opowieść: o użytkowniku, jego motywacjach i losach w cyfrowym świecie. A kto opowiada lepiej niż wielcy pisarze? Jeśli chcesz, by twoje testy były zrozumiałe, angażujące i użyteczne – zacznij pisać je jak mistrz horroru Stephen King i korzystaj z rad genialnego Kurta Vonneguta.

Przypadki testowe są głównym narzędziem w zasobniku testera. Dobrze napisane pomagają zrozumieć testowany system i zapewnić, że wymagania zostały zrozumiane, a na samym końcu spełnione. Ułatwiają komunikację w zespole – nie tylko między testerami, ale też z programistami, analitykami czy menedżerami. Dzięki nim testowanie staje się powtarzalne, mierzalne i odporne na zapomnienie. Zamiast zgadywać, co należy sprawdzić – testujesz to, co zostało jasno opisane. Przypadki testowe to dokumentacja wiedzy o systemie, która rośnie razem z projektem i pozwala zachować kontrolę nad projektem.

W poniższym artykule będę wzorował się na dwóch książkach: Zlituj się nad czytelnikiem Kurta Vonneguta i Suzanne McConnel oraz Jak pisać. Pamiętnik rzemieślnika Stephena Kinga.

Dlaczego testy to też opowieści (założenia wstępne)

Aby zastosować rady wielkich pisarzy do pisania testów, załóżmy, że proces testowania jest opowieścią o testowanym systemie:

Testy mają, tak jak opowieści, początek, rozwinięcie i zakończenie:

• Początek – w przypadku testowania będzie to przygotowanie się do testu: zapoznanie się ze specyfikacją/przypadkiem użycia funkcjonalności, którą będziemy testować, przygotowanie danych, zapoznanie się z potrzebami klienta końcowego – bohatera naszej opowieści.
• Rozwinięcie – to wykonanie testu, wprowadzenie danych, sprawdzenie czy kalkulacja została wykonana poprawnie,
• Zakończenie – to zaraportowanie wyniku, zdanie raportu, zaplanowanie następnej czynności.

Użytkownik końcowy/Persona klienta, będzie naszym bohaterem (więcej na ten temat znajdziecie w moim artykule Persona – testowanie z wykorzystywaniem technik z gier RPG).

Tak jak każdy dobry bohater również użytkownik końcowy ma swój cel, w którego osiągnięciu pozwala mu system, który testujemy, np. rozliczenie faktury, zaplanowanie trasy lotu samolotu.

Jak i w opowieści, tak i w testach, szalenie ważny jest kontekst. Dane testowe, warunki początkowe, zakres, uzasadnienie biznesowe projektu – wszystko składa się na świat przedstawiony i to w tym zakresie będziemy wykonywać testy.

Fabuła to scenariusze testowe – sekwencja kroków, które wykonujemy, można porównać do działań bohatera w powieści.

Dobry przypadek testowy prowadzi użytkownika przez scenariusz krok po kroku i może być wykorzystany w innych kontekstach. Celem lepszej komunikacji jest dogłębne zrozumienie wymagań, które w efekcie przyniesie mniej błędów.

Kurt Vonnegut: struktura i charakter

Vonnegut był nie tylko pisarzem, ale też świetnym nauczycielem pisania. Jego rady idealnie pasują do tworzenia testów:

• „Give the reader at least one character they can root for” – w testach: daj użytkownikowi „postać” (np. rolę użytkownika) z celem.
• Vonnegut kochał strukturę – wykorzystaj to do pisania scenariuszy testowych (początek, środek, kulminacja).
• Humor i absurd – testy mogą być kreatywne, byle z sensem (np. testowanie nietypowych danych wejściowych).

Cel, cel, cel

Każda postać powinna czegoś chcieć, nawet jeśli to tylko szklanka wody.

Kurt Vonnegut, Tabakiera z Bagombo

W testach – każda persona ma cel: zalogować się, znaleźć produkt, uniknąć błędu. Opisz to jak cel bohatera. Dobry przypadek testowy odwołuje się konkretnie do jednego wymagania, tak aby można było prześledzić zależności oraz określić stopień pokrycia testami. Warto skonstruować przypadek testowy w taki sposób, aby testował jedną funkcjonalność/przypadek użycia na raz. Oczywiście podczas jego wykonywania możemy sprawdzać inne aspekty testowanego systemu.

Dobrą radą jest, aby nazwa przypadku testowego była niczym nazwa rozdziału książki: stanowiła syntezę tego, co chcemy sprawdzić poprzez wykonanie testu i jednocześnie umożliwiała łatwe zidentyfikowanie przypadku testowego.

Struktura ma znaczenie

Zaczynaj tak blisko końca, jak tylko to możliwe.

Kurt Vonnegut, Tabakiera z Bagombo

Podaj czytelnikom jak najwięcej informacji w jak najkrótszym czasie. Do diabła z suspensem. Czytelnicy powinni mieć tak pełne rozeznanie w tym, co się dzieje, gdzie i dlaczego, żeby mogli sami dokończyć opowiadanie, gdyby karaluch pożerały ostatnich kilka stron.

Kurt Vonnegut, Tabakiera z Bagombo

Przypadek testowy powinien składać się z następujących elementów:

• nazwa  (name) – określa cel testu, ułatwia jego identyfikacje i wpisuje w kontekst.
• warunki wstępne (preconditions) – sekcja opisuje, w jakim stanie musi być system, zanim rozpoczniemy testy.
• dane testowe (test data) – informacje wejściowe, które będziemy wykorzystywać podczas testu.
• kroki (test steps) – szczegółowy opis akcji podejmowanych przez testera w celu osiągnięcia celu.
• oczekiwany wynik (expected result) – stan systemu po wykonanym kroku lub po teście.
• szczegóły testu (test details) – sekcja zawiera informacje dotyczące wykonania testu (środowisko, system operacyjny, rodzaj testu, przypisany tester, status przypadku testowego, status wykonania przypadku testowego).

Vonnegut szkicował fabuły jako wykresy emocji. Ty możesz robić to samo z testami:

• początek (ustawienie),
• środek (akcja),
• kulminacja (sprawdzenie), z
• akończenie (oczekiwany rezultat).

W krokach opisuj akcje użytkownika, a w oczekiwanym rezultacie stan systemu w taki sposób, żeby móc później łatwo poznać, że akcja przyniosła oczekiwany rezultat, dzięki czemu kroki z przypadków testowych będzie można wykorzystać do raportowania defektów.

W przypadku dokumentowania przypadków testowych warto rozważyć użycie narzędzi takich jak TestRail, Xray (dla Jira), Zephyr, czy nawet Google Sheets – jeśli projekt jest niewielki. Niezależnie od narzędzia, zasada pozostaje ta sama: struktura, cel, dane, kroki, oczekiwany rezultat.

Priorytetyzacja przypadków testowych

Nie wszystkie przypadki testowe są równie ważne. W praktyce warto ustalić ich priorytety, aby skupić się najpierw na tych, które mają największy wpływ na jakość systemu. Oto trzy popularne podejścia:

1. Analiza ryzyka – oceń prawdopodobieństwo wystąpienia błędu oraz jego wpływ. Przypadki o wysokim ryzyku należy wykonywać w pierwszej kolejności.
2. Metoda MoSCoW – podziel przypadki na Must have (musi być), Should have (powinno być), Could have (może być) i Won’t have (nie będzie).
3. Krytyczność funkcji biznesowej – skup się na testach dla funkcji najczęściej używanych lub krytycznych z punktu widzenia klienta (np. logowanie, płatności).

Zastosowanie takich metod priorytetyzacji pozwala lepiej zarządzać czasem testowania i zasobami zespołu.

Nie bój się absurdu

Vonnegut kochał absurdalne sytuacje. Ty też możesz testować skrajności: „co, jeśli użytkownik ma w nazwisku 1000 liter?”, „a co, jeśli wybrał wszystkie możliwe opcje na raz?”.

Podczas pisania tzw. Edge cases – brzegowych przypadków testowych – stawiamy świat na głowie i sprawdzamy, czy działa. Tak jak w najlepszej literaturze sprawdzamy, co by się stało, gdyby samochód był złym duchem albo opisujemy kosmiczne zoo, w którym są pokazywani kosmici – w tym ludzie.

Edge cases, czyli przypadki brzegowe, to testy zaprojektowane z myślą o zachowaniu systemu na granicy dopuszczalnych wartości. Ich głównym celem jest ujawnienie błędów, które nie występują w typowych warunkach, ale mogą mieć poważne konsekwencje, gdy jednak do nich dojdzie. Piszemy graniczne przypadki testowe, aby sprawdzić zachowanie systemu przy pustych wartościach (brak Internetu), przy celowym „psuciu” systemu, przy ekstremalnych danych wejściowych (242 telewizory w koszyku, zamówienie na nieistniejący adres).

Stephen King: prostota, rytm i konkret

Stephen King to mistrz pisania w stylu „czyta się jednym tchem”. Spójrzmy, jakich rad mistrz horroru udziela początkującym pisarzom.

Język ma być prosty

Pisz przy otwartych drzwiach, redaguj przy otwartych.

Stephen King

Najpierw napisz przypadek testowy tak, jak go rozumiesz. Potem dopracuj go z myślą o innych. Zaplanuj przegląd przypadków testowych z innym testerem, programistą bądź product ownerem. Warto zadbać o to, żeby przypadki testowe były tak napisane, żeby można wysłać je do użytkownika końcowego/klienta.

King radzi unikać zbędnych przymiotników, ozdobników i skrótów myślowych. W testach również: proste, klarowne kroki są najlepsze. Warto pamiętać, żeby korzystać z tego samego zestawu pojęć, co programiści i biznes. Pisz przypadki testowe tak, aby mogły zostać prosto przerobione na instrukcje użytkownika lub jako dokumentacje produktową. Pamiętaj o takim przygotowaniu, żeby było łatwo je zautomatyzować: jednoznaczne dane, przejrzysta struktura. Warto też wziąć pod uwagę, że przypadki testowe, które tworzymy, mogą zostać użyte przez innego testera albo programistę, dlatego warto pisać przykładowe dane i uszczegółowić spodziewany rezultat. 

Rytm i napięcie

Nie chodzi o suspens w sensie literackim, ale o to, by test miał logiczny ciąg zdarzeń i naturalne tempo, a każdy krok ma wynikać z poprzedniego.

Przypadki testowe powinny być jak najbardziej zatomizowane, jeden przypadek sprawdza jeden obszar testowy na raz. Poświęć chwilę na to, aby każdy z kroków przypadku testowego miał odpowiadający mu oczekiwany rezultat, dzięki czemu jednoznacznie będziesz mógł ocenić, czy dany krok został wykonany.

To co ukryte, to czego nie widać, również ma znaczenie przy pisaniu przypadków testowych w kontekście założeń poczynionych co do stanu systemu, wiedzy testera oraz etapu wytwarzania oprogramowania. Przypadki testowe powinny być sprawdzane i odpowiednio poprawiane przy każdej zmianie systemu.

Jeżeli piszesz wysokopoziomowe przypadki testowe pod testy akceptacyjne, to bierz pod uwagę to, co jest ukryte:

• wiedza potrzebna użytkownikowi, aby wykonać dany przypadek testowy,
• narzędzia i dane testowe,
• środowisko testowe.

Przypadek testowy jako narracja: krok po kroku

Przypadek testowy można potraktować jak małą opowieść:

• Ekspozycja – w jakim jesteśmy kontekście? Jakie dane wprowadzono? Jakie warunki początkowe?
• Konflikt – co użytkownik robi? Jaką akcję podejmuje? Gdzie może pojawić się ryzyko?
• Kulminacja – system reaguje. Czy pojawia się błąd? Czy dzieje się coś niespodziewanego?
• Rozwiązanie – co powinno się stać? Jak wygląda sukces, a jak porażka?

Dzięki tej narracyjnej strukturze testy stają się bardziej intuicyjne i naturalne do odtworzenia.

• Nadawaj im tytuły jak rozdziały książek („TC_104_Zaloguj się jak zapominalski użytkownik” zamiast „TC_104_Login_invalid”).
• Twórz persony użytkowników – jak bohaterów opowieści.
• Pamiętaj o czytelniku – inżynierze, który przyjdzie po tobie.
• Zamiast „TC_0345_EditAccount_InvalidData”, spróbuj: „Edytuj dane użytkownika z błędnym adresem e-mail” – od razu wiadomo, o co chodzi.

Persona jako bohater

Wprowadź użytkownika jako postać: „Klient zalogowany jako premium”, „Nowy użytkownik po rejestracji”, „Administrator bez pełnych uprawnień”. Łatwiej wtedy wyobrazić sobie kontekst.

Dziesięć przykazań pisania przypadków testowych

1. Znaj swojego bohatera. Zawsze określ, kto jest użytkownikiem testowanego scenariusza.
2. Zacznij od końca. Zdefiniuj cel testu, zanim napiszesz pierwszy krok.
3. Pisz konkretnie. Używaj jednoznacznych danych, czytelnych kroków i mierzalnych oczekiwań.
4. Unikaj ozdobników. Prostota i klarowność to fundament testu – jak u Kinga.
5. Szanuj strukturę. Każdy test powinien mieć początek, rozwinięcie i zakończenie.
6. Nie bój się absurdu. Projektuj testy ekstremalne i brzegowe – one pokazują siłę systemu.
7. Myśl jak czytelnik. Twój test powinien być zrozumiały nawet dla osoby spoza zespołu.
8. Dobrze tytułuj. Tytuł testu powinien od razu mówić, co jest sprawdzane.
9. Testuj jedno na raz. Jeden przypadek – jeden cel. Nie mieszaj celów w ramach jednego testu.
10. Ewaluuj i rozwijaj. Przypadek testowy nie jest wieczny – wracaj do niego po zmianach w systemie.

Podsumowanie

Pisanie przypadków testowych nie musi być nudne, mechaniczne ani sztywne. Wręcz przeciwnie – może być twórczym procesem, który łączy precyzję inżynierską z narracyjną klarownością i empatią dla użytkownika. Inspirując się Stephenem Kingiem i Kurtem Vonnegutem, uczymy się myśleć o testach jak o opowieściach: z bohaterem, konfliktem, celem i puentą.

Dobrze napisany przypadek testowy nie tylko sprawdza działanie systemu, ale również przekazuje wiedzę, wspiera komunikację zespołową i ułatwia przyszłe decyzje projektowe. To dokument, który może przetrwać zmiany, ewoluować z produktem i służyć wielu odbiorcom – testerom, deweloperom, analitykom, a nawet klientom.

Pamiętaj: przypadek testowy to coś więcej niż lista kroków. To historia o tym, jak działa Twój system – i jak powinien działać. Pisz ją świadomie, odpowiedzialnie i z wyobraźnią.

Stephen King nauczy cię prostoty i rytmu.

Kurt Vonnegut – struktury i charakteru.

Ty połącz to wszystko i pisz testy, które się czyta z przyjemnością – nawet jeśli kończą się błędem 500.

Bibliografia

• Praca testera w dobie AI – połącz DALL-E i storytelling
• Stephen King, Jak pisać. Pamiętnik rzemieślnika
• Kurt Vonnegut, Zlituj się nad czytelnikiem. Zasady twórczego pisania
• How Much is Enough? Testing as Story-Telling
• Jak napisać dobry przypadek testowy?
• Rex Black on Software Testing Best Practices