Testy manualne: rodzaje, przykład przypadku testowego i raport błędu

Testy manualne to sprawdzanie oprogramowania przez człowieka, bez skryptu, który klika za niego: tester projektuje przypadki, wykonuje je, obserwuje i ocenia wynik. Poniżej znajdziecie rodzaje testów manualnych z zastosowaniem i trzy wzory do skopiowania: przypadek testowy, kartę sesji eksploracyjnej i raport błędu. To materiał dla Was, jeśli wchodzicie do zawodu albo prowadzicie zespół i chcecie ujednolicić warsztat Waszych testerów.

Jeśli szukacie porównania z automatyzacją, przeczytajcie najpierw tekst o tym, czym różnią się testowanie manualne i automatyczne. Tutaj zostajemy przy samej pracy ręcznej i robimy ją porządnie.

Czym są testy manualne i czym różnią się od klikania?

Testy manualne różnią się od klikania tym, że mają cel, dane i oczekiwany wynik zapisany przed wykonaniem. Sylabus ISTQB CTFL 4.0 dzieli proces testowy na siedem grup czynności: planowanie, monitorowanie i nadzór, analizę, projektowanie, implementację, wykonanie i ukończenie. Wykonanie scenariusza to więc jedna z siedmiu, a pozostałe sześć decyduje, czy znajdziecie błąd, za który zapłaci klient.

Człowiek jest tu narzędziem pomiarowym. Zauważa mylący komunikat, niespójny układ ekranu i sytuację, której nikt nie przewidział w wymaganiach. Według sylabusa ISTQB CTFL 4.0 (2023) jedna z siedmiu zasad mówi, że testowanie wyczerpujące jest niemożliwe, więc tester musi wybierać, co sprawdzić. Wybór oparty na ryzyku i technikach projektowania to właśnie warsztat, który odróżnia testera od osoby, która przeklikała aplikację. Zasady omawiamy na przykładach w artykule o 7 zasadach testowania według ISTQB.

Jakie są rodzaje testów manualnych?

Rodzaje testów manualnych różnią się tym, ile przygotowania wymagają i co dają w zamian. Scenariusze dają powtarzalność, eksploracja daje odkrycia, listy kontrolne dają szybkość. Dojrzały zespół używa wszystkich, w proporcji zależnej od etapu projektu.

Testy eksploracyjne, oparte na listach kontrolnych i zgadywanie błędów ISTQB zalicza do technik opartych na doświadczeniu, a podział klas równoważności i wartości brzegowe do technik czarnoskrzynkowych. Ta różnica ma praktyczny sens: technika czarnoskrzynkowa daje przypadki, które powtórzy każdy, a technika doświadczeniowa zależy od tego, kto testuje. Akceptację opisujemy szerzej w tekście o testach akceptacyjnych UAT, a ćwiczymy obie grupy technik na szkoleniu testy eksploracyjne i heurystyczne.

Jak napisać przypadek testowy? Przykład z wartościami brzegowymi

Weźmy wymaganie, które ma prawie każdy sklep: darmowa dostawa od 200,00 zł. Analiza wartości brzegowych mówi, żeby testować tuż pod granicą, na granicy i tuż nad nią, czyli 199,99 zł, 200,00 zł i 200,01 zł. Programiści mylą się najczęściej właśnie na granicy, bo znak większy i znak większy lub równy różnią się jednym znakiem.

Czwarty wiersz to przypadek, którego zwykle brakuje w wymaganiu. Dobry tester nie zgaduje odpowiedzi, tylko zadaje pytanie analitykowi, zanim błąd trafi do kodu. A tak wygląda pełny przypadek testowy dla granicy, gotowy do wklejenia do narzędzia do zarządzania testami:

ID: TC-KOSZ-014
Tytuł: Darmowa dostawa od 200,00 zł, wartość brzegowa
Priorytet: wysoki (wpływa na koszt każdego zamówienia)
Warunki wstępne: użytkownik zalogowany, koszyk pusty, adres w Polsce
Dane: produkt A 199,99 zł, produkt B 0,01 zł
Kroki:
  1. Dodaj produkt A do koszyka.
  2. Przejdź do podsumowania i odczytaj koszt dostawy.
  3. Dodaj produkt B.
  4. Odśwież podsumowanie.
Oczekiwany wynik:
  po kroku 2: dostawa 14,99 zł, suma 214,98 zł
  po kroku 4: dostawa 0,00 zł, suma 200,00 zł
Powiązane wymaganie: REQ-DOST-03

Zwróćcie uwagę na pole Dane: przypadek bez konkretnych wartości każdy tester wykona inaczej. Różnicę między scenariuszem a przypadkiem testowym wyjaśnia artykuł jak napisać dobry scenariusz testowy, a dokumentację krok po kroku ćwiczymy na szkoleniu tworzenie dokumentacji testowej.

Jak prowadzić sesję eksploracyjną? Karta testu do skopiowania

Sesja eksploracyjna ma misję, limit czasu i zapis wyników. Metodę opisali Jonathan i James Bach w tekście Session-Based Test Management (2000), opracowanym przy projektach w Hewlett-Packard. Sesja trwa zwykle od 60 do 120 minut, a po niej tester omawia notatki z liderem. Dzięki temu eksploracja przestaje być niewidzialną pracą, której nie da się zaplanować ani rozliczyć.

KARTA SESJI EKSPLORACYJNEJ
Misja (charter): zbadać zmianę adresu dostawy w trakcie zamówienia
  pod kątem utraty danych i błędnego przeliczenia kosztów
Tester: Anna K.          Start: 10:00    Czas: 90 min
Środowisko: staging, build 4.12.0, Chrome 141, Android 15
Podział czasu: testowanie 70%, raportowanie błędów 20%, przygotowanie 10%
Notatki:
  - zmiana kraju na Niemcy nie przelicza VAT do odświeżenia strony
  - kod pocztowy z literami przyjęty bez walidacji
Błędy: BUG-2231, BUG-2232
Pytania do zespołu: czy paczkomat może być adresem faktury?
Kolejna sesja: płatność odroczona

W naszych projektach karta sesji zastępuje dziesiątki szczegółowych przypadków przy funkcjach, które jeszcze się zmieniają: pisanie kroków do ekranu, który jutro wygląda inaczej, to praca na śmietnik. Definicję testowania eksploracyjnego znajdziecie w słowniku ISTQB.

Jak zgłosić błąd po teście manualnym? Wzór raportu

Raport błędu to produkt testu manualnego, który czyta ktoś inny. Musi pozwolić odtworzyć problem bez pytań uzupełniających, więc ma kroki z danymi, wynik oczekiwany z odwołaniem do wymagania, wynik rzeczywisty, powtarzalność i dowód. Poniżej raport z błędu, który znalazł przypadek TC-KOSZ-014:

Tytuł: Koszt dostawy nie znika po przekroczeniu 200,00 zł w koszyku
Środowisko: staging, build 4.12.0, Chrome 141 na Windows 11
Kroki odtworzenia:
  1. Zaloguj się kontem test.dostawa@example.com.
  2. Dodaj produkt A (199,99 zł), przejdź do podsumowania.
  3. Dodaj produkt B (0,01 zł) i odśwież podsumowanie.

Druga część raportu mówi, czym wynik różni się od oczekiwania, jak często występuje i dlaczego jest ważny:

Wynik oczekiwany: dostawa 0,00 zł, suma 200,00 zł (REQ-DOST-03)
Wynik rzeczywisty: dostawa 14,99 zł, suma 214,99 zł
Powtarzalność: 5 na 5 prób; przy sumie 200,01 zł działa poprawnie
Ważność: wysoka (klient płaci za dostawę, która ma być darmowa)
Załączniki: nagranie ekranu, zrzut zakładki Network z odpowiedzią /api/cart
Hipoteza: warunek porównuje sumę operatorem > zamiast >=

Dwa pola robią tu największą różnicę. Powtarzalność z informacją, że przy 200,01 zł działa, zawęża przyczynę do jednego warunku. Hipoteza oszczędza programiście pół godziny szukania, ale jest oznaczona jako hipoteza, nie diagnoza.

Więcej o tym, jak pisać zgłoszenia, które nie wracają z dopiskiem nie da się odtworzyć, piszemy w poradniku jak poprawnie zgłosić błąd. Raport bez kroków odtworzenia to zagadka kryminalna, a programiści rzadko mają czas na kryminały w środku sprintu.

Co robi tester manualny w ciągu dnia pracy?

Tester manualny pracuje w całym cyklu zmiany, nie tylko na końcu. Typowy dzień w zespole Scrum wygląda mniej więcej tak:

Najważniejszym produktem tej pracy jest dla Was informacja o ryzyku, na podstawie której zespół decyduje o wydaniu. Jeśli rozważacie ten zawód, ścieżkę wejścia opisuje artykuł jak zostać testerem oprogramowania, a typowe wymagania pracodawców tekst o obowiązkach i wymaganiach wobec testera. Najbardziej uporządkowaną drogą jest kompleksowy kurs testera manualnego połączony z praktyką w projekcie stażowym dla testera manualnego.

Jakich narzędzi używa się w testach manualnych?

Test manualny nie wymaga pisania kodu, ale wymaga narzędzi. Ta tabela pokazuje zestaw, z którym tester manualny jest samodzielny w typowym projekcie webowym:

Podstawy zapytań do bazy dla testerów ćwiczymy na szkoleniu bazy danych i SQL dla testerów, a pełny przegląd narzędzi znajdziecie w zestawieniu narzędzi do testowania oprogramowania.

Kiedy testy manualne wygrywają z automatyzacją?

Testy manualne wygrywają tam, gdzie potrzebna jest ocena człowieka albo test uruchomicie kilka razy w życiu: nowa funkcja w budowie, użyteczność, dostępność z czytnikiem ekranu, eksploracja po incydencie, odbiór od dostawcy. Automatyzacja wygrywa przy regresji uruchamianej przy każdym wydaniu. W Quality Island napisaliśmy ponad 450 000 testów automatycznych i właśnie dlatego wiemy, że żaden z nich nie zastąpił testera przy nowej funkcji. Proporcje i próg opłacalności automatyzacji omawia artykuł testowanie manualne vs testowanie automatyczne.

Jakie błędy najczęściej psują testowanie manualne?

Większość słabych testów manualnych psuje kilka powtarzalnych nawyków. Każdy z nich ma proste lekarstwo:

Jak inni testerzy radzą sobie z tymi nawykami, możecie posłuchać na Testing Ground Conference, a krótkie analizy warsztatu QA publikuje Strefa QA. Gdy chcecie ułożyć to w zespole, zacznijcie od szkoleń z testowania manualnego albo od zleconych testów funkcjonalnych, które pokażą punkt startowy.

Powiązane na blogu Quality Island

• Testowanie manualne i automatyczne: jakie są różnice i kiedy wybrać każde podejście
• Jak poprawnie zgłosić błąd: praktyczny przewodnik po raporcie
• Scenariusz testowy: jak go napisać i czym różni się od przypadku testowego
• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Jak zostać testerem oprogramowania: ścieżka krok po kroku

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level, sylabus 4.0 (2023)
• ISTQB Glossary, exploratory testing (2024)
• ISTQB, A global milestone: 1 000 000 certyfikatów (maj 2025)
• Jonathan Bach, James Bach, Session-Based Test Management (2000)
• Jakob Nielsen, Nielsen Norman Group, Why You Only Need to Test with 5 Users (2000)
• Quality Island, dane własne: liczba przeszkolonych specjalistów i testów automatycznych (2026)