Jak napisać plan testów: 13 sekcji, kryteria wyjścia i przykład

Plan testów (ang. test plan) to dokument, który dla jednego projektu albo wydania zapisuje, co testujecie, czego świadomie nie testujecie, jak, gdzie, kto, do kiedy i po czym poznacie, że testy można zakończyć. Nie jest raportem ani listą przypadków testowych, tylko umową zespołu z interesariuszami o tym, jak będzie wyglądała informacja o jakości przed decyzją o wydaniu. Dobry plan testów rozstrzyga spory, zanim ktoś zdąży się o nie pokłócić na tydzień przed premierą.

Poniżej dostajecie trzynaście sekcji planu z komentarzem, który z nich ma znaczenie dla budżetu, poprawne definicje kryteriów wejścia i wyjścia według sylabusa ISTQB CTFL v4.0.1 (razem z tym, jak mają się do Definition of Ready i Definition of Done), wypełniony przykład dla małego projektu e-commerce oraz szablon Word do pobrania.

Czym jest plan testów i czym różni się od strategii testów?

Plan testów opisuje cele testowania i sposób, w jaki zespół je osiągnie w konkretnym projekcie. Tak definiuje go sylabus ISTQB Certified Tester Foundation Level v4.0.1 (ISTQB, 2024) w rozdziale 5.1.1 i od razu dodaje, że ważniejszy od samego dokumentu jest proces jego pisania: zmusza do przemyślenia ryzyk, harmonogramu, ludzi, narzędzi i kosztów, zanim zaczną boleć.

Ten sam rozdział wymienia typową zawartość planu: kontekst testowania (zakres, cele, podstawa testów), założenia i ograniczenia, interesariuszy (role, odpowiedzialność, potrzeby rekrutacyjne i szkoleniowe), komunikację, rejestr ryzyk produktowych i projektowych, podejście do testów (poziomy, typy, techniki, produkty testowe, kryteria wejścia i wyjścia, niezależność testowania, metryki, wymagania wobec danych i środowiska) oraz budżet i harmonogram. Po szczegóły sylabus odsyła do normy ISO/IEC/IEEE 29119-3:2021, która opisuje szablony dokumentacji testowej, w tym planu testów, i zastąpiła starszy standard IEEE 829. Norma daje listę kontrolną, ale nie narzuca formy: plan może mieć dwie strony albo czterdzieści.

Najczęstsze pomylenie pojęć dotyczy strategii. Polityka testów i strategia testów to dokumenty organizacji: mówią, jak firma testuje zawsze, na przykład jakie poziomy testów obowiązują i kto zatwierdza wydanie. Plan testów dotyczy jednego projektu albo wydania i według ISTQB ma pokazać, że testowanie trzyma się polityki i strategii, albo wyjaśnić, dlaczego w tym projekcie od nich odchodzi. Jeśli w Waszej firmie strategii jeszcze nie ma, plan zaczyna pełnić jej rolę, co kończy się trzynastoma różnymi planami w trzynastu zespołach. Jak zbudować poziom wyżej, pokazujemy w tekście o strategii testowania w organizacji.

Kto pisze plan testów i kto go zatwierdza?

Plan pisze lider testów albo test manager, a w mniejszych zespołach najbardziej doświadczony tester w projekcie. Pisze go jednak z cudzych informacji. Zakres i priorytety daje właściciel produktu, ograniczenia techniczne i kolejność dostarczania funkcji programiści, środowisko i dane administratorzy, a budżet kierownik projektu. Plan napisany samodzielnie przy biurku zwykle trzyma się dobrze tylko do pierwszego spotkania z resztą zespołu.

Ważniejsze od autora jest to, kto plan akceptuje. Podpis właściciela produktu albo sponsora pod sekcjami „Poza zakresem”, „Ryzyka” i „Kryteria wyjścia” oznacza, że decyzje o ryzyku podjęła osoba, która za nie odpowiada biznesowo, a nie tester, który je tylko zapisał. Jeśli plan nie ma takiej akceptacji, w praktyce jest notatką zespołu testowego.

Po co plan testów, skoro pracujecie zwinnie?

Bo zwinność zmienia formę planu, a nie jego potrzebę. Sylabus ISTQB w rozdziale 5.1.2 opisuje dwa poziomy planowania w modelach iteracyjnych. Planowanie wydania patrzy na cały release: tu powstaje podejście do testów i plan testów wspólny dla wszystkich iteracji, a testerzy pomagają pisać testowalne historyjki i kryteria akceptacji. Planowanie iteracji patrzy na jeden sprint: tu testerzy analizują ryzyko konkretnych historyjek, dzielą je na zadania testowe i szacują pracę.

W zespole scrumowym plan testów to więc zwykle jedna, dwie strony na wydanie plus dwie umowy, które żyją w narzędziu do zadań: Definition of Ready i Definition of Done. Według ISTQB cel planu się nie zmienia. Plan dokumentuje sposób i harmonogram osiągnięcia celów testowania, pomaga dopilnować, że testy spełnią ustalone kryteria, służy do komunikacji z zespołem i interesariuszami oraz pokazuje zgodność z polityką i strategią testów. Zespół, który mówi „nie mamy planu testów, jesteśmy agile”, zwykle ma plan, tylko trzyma go w głowie jednej osoby, która akurat jest na urlopie.

Co powinien zawierać plan testów? 13 sekcji z komentarzem

Poniższe trzynaście sekcji odpowiada układowi szablonu Word. Nie każda musi mieć osobny rozdział: w małym projekcie kilka zmieści się w jednej tabeli. Przy każdej piszemy, na co patrzeć, bo opis „co to jest” znajdziecie w każdym podręczniku, a pytanie „gdzie to się psuje” zwykle zostaje bez odpowiedzi.

1. Wstęp i cel

Dwa cele, których nie warto mieszać. Cel dokumentu mówi, po co powstał plan, na przykład „uzgodnić zakres i kryteria testów wersji 2.4”. Cel testowania mówi, jaką informację dostaną interesariusze, na przykład „dać właścicielowi produktu podstawę do decyzji o wydaniu 28.11”. Jedno zdanie celu testowania wystarczy, jeśli zawiera nazwę decyzji i datę.

2. Zakres testów

Sekcja, która najmocniej wpływa na budżet. Wypiszcie poziomy i typy testów, które wykonacie (modułowe, integracyjne, systemowe, regresja, wydajnościowe, bezpieczeństwa), i obok każdego jedną liczbę: ile przypadków, ile użytkowników w teście obciążeniowym, ile konfiguracji przeglądarek. Równie ważna jest lista pominięć z uzasadnieniem. „Nie testujemy panelu administracyjnego, bo nie zmienia się w tej wersji” chroni obie strony. „Nie testujemy bezpieczeństwa” bez słowa wyjaśnienia jest zaproszeniem do sporu po pierwszym incydencie.

3. Przedmiot testów

Co dokładnie dostaje zespół testowy: cała aplikacja, wybrane moduły, usługa API, konkretna wersja z konkretnego builda. Wpiszcie numer wersji albo sposób jej identyfikacji, bo „testujemy nowy koszyk” po trzech wdrożeniach poprawek przestaje cokolwiek znaczyć.

4. Kryteria zaliczenia i niezaliczenia testów

Tu najłatwiej o błąd pojęciowy. Kryterium zaliczenia mówi, kiedy pojedynczy test albo element testowy uznajecie za zaliczony: rzeczywisty wynik zgadza się z oczekiwanym, a mierzone wartości mieszczą się w progu. Starszy standard IEEE 829 miał na to osobną sekcję planu (item pass/fail criteria). To nie jest to samo co podział na test pozytywny i negatywny. Test pozytywny sprawdza zachowanie dla poprawnych danych, negatywny dla niepoprawnych, i każdy z nich może zakończyć się zaliczeniem albo niezaliczeniem.

Przy testach wydajnościowych zapiszcie progi tak, żeby nie dało się ich interpretować dwojako: metryka, percentyl, obciążenie i czas trwania. Przydają się czas odpowiedzi (95. albo 99. percentyl, nie średnia, bo średnia ukrywa najwolniejsze żądania), czas do pierwszego bajtu, przepustowość w żądaniach na sekundę, odsetek nieudanych transakcji i zużycie pamięci oraz procesora po stronie serwera. Więcej o mierzalnych wymaganiach dla wydajności, zabezpieczeń i użyteczności znajdziecie w tekście o testach niefunkcjonalnych.

5. Kryteria wejścia, wyjścia i zawieszenia

Kryteria zaliczenia oceniają pojedynczy test. Kryteria wejścia i wyjścia oceniają całą czynność testową, na przykład poziom testów systemowych albo testy całego wydania. Ponieważ to najczęściej źle rozumiana część planu, poświęcamy jej osobny rozdział niżej. Kryteria zawieszenia i wznowienia mówią, kiedy przerwać testy, bo dalsza praca nie ma sensu (na przykład środowisko nie działa albo błąd blokuje główną ścieżkę), i co musi się stać, żeby wrócić.

6. Lista wymagań i funkcjonalności do przetestowania

Lista funkcji albo historyjek użytkownika, które obejmują testy, najlepiej z identyfikatorami z narzędzia do zadań. Dzięki temu w raporcie końcowym pokażecie pokrycie wymagań: ile z nich ma przypisane testy i ile z tych testów jest zaliczonych. Bez identyfikatorów taki raport trzeba składać ręcznie dzień przed wydaniem.

7. Środowisko testowe

Sprzęt, system operacyjny, przeglądarki, urządzenia mobilne, usługi zewnętrzne w trybie testowym i dane testowe. Podawajcie wersje, nie nazwy: „Chrome i Safari w dwóch ostatnich wersjach, iOS 17 i 18” zamiast „popularne przeglądarki”. Zapiszcie też, kto odpowiada za środowisko i ile trwa jego odtworzenie. Jak je przygotować, opisujemy w tekście o środowisku testowym.

8. Harmonogram testów

Fazy i typy testów przypisane do dat, a przy każdej fazie zależność: testy integracyjne płatności startują, gdy jest dostęp do trybu sandbox bramki. Harmonogram bez zależności wygląda dobrze tylko do pierwszego opóźnienia po stronie programistów. Zapas na retesty i regresję po poprawkach wpiszcie jako osobną pozycję, a nie jako cichą rezerwę, bo cicha rezerwa zawsze zostaje zjedzona pierwsza.

9. Raport z testów

Jakie produkty testowe dostaną interesariusze i kiedy: raporty postępu (na przykład codziennie w trakcie fazy testów) i raport końcowy z rekomendacją. Zapiszcie odbiorcę każdego raportu. Raport końcowy porównuje stan z kryteriami wyjścia i mówi wprost, które są spełnione, a które nie. Wzór znajdziecie w tekście o tym, co musi zawierać raport z testów.

10. Lista narzędzi

Narzędzia do zarządzania testami, zgłaszania błędów, automatyzacji, testów API i wydajności, z wersjami i właścicielem licencji. Przy dłuższej liście podzielcie je na grupy. Jeśli dopiero dobieracie zestaw, pomoże przegląd narzędzi do testowania oprogramowania.

11. Zarządzanie incydentami i błędami

Cykl życia zgłoszenia od wykrycia przez poprawkę po retest i zamknięcie, skala ważności z definicjami („krytyczny: blokuje zakup, brak obejścia”) i czas reakcji dla każdej wagi. Bez definicji wag kryterium wyjścia „0 otwartych błędów krytycznych” można spełnić, obniżając wagę zgłoszeń. Standard samego zgłoszenia opisujemy w tekście o tym, jak poprawnie zgłosić błąd.

12. Role i odpowiedzialność

Kto testuje który obszar, kto ustala priorytety błędów, kto decyduje o zawieszeniu testów i kto podpisuje raport końcowy. Najprościej zrobić to tabelą osób i decyzji. Tu też wpisujecie potrzeby szkoleniowe i kadrowe, o których wspomina ISTQB, na przykład „tester automatyzujący do testów obciążeniowych od tygodnia 2”.

13. Ryzyka

Rejestr ryzyk produktowych (co może nie działać u użytkownika) i projektowych (co może opóźnić testy). Każde ryzyko ma prawdopodobieństwo, wpływ, działanie zapobiegawcze i osobę, która decyduje, gdy ryzyko się zmaterializuje. Ryzyko bez działania jest tylko listą obaw.

Czym są kryteria wejścia i wyjścia według ISTQB?

Kryteria wejścia określają warunki wstępne, które muszą być spełnione, żeby rozpocząć daną czynność. Kryteria wyjścia określają, co trzeba osiągnąć, żeby uznać czynność za zakończoną. Tak definiuje je sylabus ISTQB CTFL v4.0.1 w rozdziale 5.1.3 i dodaje, że definiuje się je dla każdego poziomu testów osobno, bo zależą od celów testowania. Jeśli kryteria wejścia nie są spełnione, czynność będzie według sylabusa trudniejsza, dłuższa, droższa i bardziej ryzykowna. Kryterium wyjścia nie oznacza więc „funkcja działa zgodnie z założeniami”, tylko „osiągnęliśmy to, co uzgodniliśmy jako warunek zakończenia testów”.

Definition of Done ma swoje źródło w Scrum Guide 2020, gdzie jest formalnym opisem stanu przyrostu spełniającego miary jakości wymagane dla produktu. Definition of Ready w Scrum Guide nie występuje. To praktyka zespołów, którą sylabus ISTQB porządkuje jako kryteria wejścia dla historyjki. W praktyce DoD jednej historyjki („testy akceptacyjne zaliczone, testy jednostkowe w potoku zielone, brak otwartych błędów krytycznych”) nie zastępuje kryteriów wyjścia całego wydania („regresja wykonana na środowisku przedprodukcyjnym, test obciążeniowy zaliczony”). Plan testów wydania potrzebuje obu poziomów.

Dwie reguły, które ułatwiają pisanie kryteriów. Po pierwsze, każde kryterium da się sprawdzić bez dyskusji: liczba, procent, tak lub nie. „Aplikacja działa stabilnie” nie jest kryterium, „0 otwartych błędów krytycznych i najwyżej 3 otwarte błędy wysokie z zaakceptowanym obejściem” jest. Po drugie, kryteria wyjścia odnoszą się do ryzyka, a nie do wysiłku. „Wykonaliśmy 500 przypadków” mówi, ile pracy włożyliście. „Pokryliśmy testami 100% wymagań o wysokim ryzyku” mówi, czego się dowiedzieliście. Pojęcia z rozdziału 5 sylabusa są częścią egzaminu, który przygotowujemy na szkoleniu Certyfikowany Tester Poziom Podstawowy.

Jak wygląda wypełniony plan testów? Przykład dla małego projektu

Opis sekcji to jedno, ale najwięcej uczy gotowy fragment. Poniżej skrócony plan testów dla małego projektu: sklep internetowy dodaje płatność BLIK i nowy koszyk, wydanie za trzy tygodnie, w zespole dwóch testerów i czterech programistów. Liczby są przykładowe i pokazują poziom konkretu, którego warto oczekiwać od własnego planu. Dla projektu tej skali cały dokument mieści się na dwóch, trzech stronach.

Kryteria w przykładowym planie zapisujemy liczbami, bo to one wywołują najwięcej sporów. Zwróćcie uwagę, że kryteria wyjścia mówią o całej fazie testów wydania, a nie o pojedynczej funkcji:

Trzy rzeczy w tym przykładzie są ważniejsze niż reszta. Sekcja „Poza zakresem” jest równie konkretna jak zakres i przypisuje odpowiedzialność właściwej stronie. Testy bezpieczeństwa sklepu nie znikają, tylko mają innego wykonawcę i są warunkiem wydania; jeśli takiego wykonawcy jeszcze nie macie, prowadzimy testy bezpieczeństwa aplikacji. Ryzyka mają przypisane działanie i osobę, która decyduje. A kryteria wyjścia oddzielają rekomendację zespołu testowego od decyzji biznesowej, którą podejmuje właściciel produktu. Jeśli plan ma powstawać w sprintach, a nie raz na projekt, przyda się tekst Strefy QA o tym, jak wdrożyć QA w zespole agile bez spowalniania developmentu.

Jakie błędy najczęściej psują plan testów?

Te same pułapki widzimy w dokumentacji testowej przy audytach QA niezależnie od wielkości firmy. Każda ma prostą poprawkę.

• Plan pisany dla audytora. Czterdzieści stron, których nikt nie otwiera po zatwierdzeniu. Poprawka: jedna strona podsumowania na początku (zakres, poza zakresem, kryteria wyjścia, daty, decydent), reszta w załącznikach.
• Zakres bez liczb. „Testy regresji” bez liczby przypadków i czasu nie da się wycenić ani rozliczyć. Poprawka: przy każdym typie testów jedna liczba.
• Kryteria pisane przymiotnikami. „Stabilnie”, „wydajnie”, „bez istotnych błędów”. Poprawka: próg, który da się sprawdzić bez dyskusji, i definicje wag błędów.
• Pomylenie poziomów kryteriów. Kryterium zaliczenia pojedynczego testu wpisane jako kryterium wyjścia całej fazy albo DoD historyjki potraktowane jak zgoda na wydanie. Poprawka: osobno kryteria zaliczenia, osobno wejście i wyjście dla każdego poziomu testów.
• Pominięcia bez właściciela. „Poza zakresem” bez informacji, kto to robi zamiast Was. Poprawka: przy każdym pominięciu wykonawca albo świadoma akceptacja ryzyka.
• Plan zamrożony. Dokument zatwierdzony na starcie i nieaktualizowany po zmianie zakresu. Poprawka: wersja i data przy każdej zmianie, a zmiana zakresu oznacza zmianę planu.

Od czego zacząć pisanie planu testów?

Zacznijcie od trzech sekcji, które najmocniej wpływają na budżet i decyzję o wydaniu: zakres razem z listą pominięć, kryteria wyjścia w liczbach oraz ryzyka z działaniami. Pokażcie je właścicielowi produktu przed rozpisaniem reszty. Jeśli na tym etapie nie ma zgody, pozostałe dziesięć sekcji niczego nie uratuje. Potem uzupełnijcie środowisko, harmonogram z zależnościami i role, a szablon Word z tego artykułu da Wam strukturę, żeby niczego nie pominąć.

Jeśli wolicie, żeby ktoś z zewnątrz spojrzał na Wasz proces, zespół Quality Island przygotowuje plany i strategie testów, prowadzi testy oprogramowania i testy wydajności z progami zapisanymi w planie, a przy dużej regresji pomaga z automatyzacją testów. Napiszcie do nas, a ustalimy podejście dopasowane do Waszego projektu.

Powiązane na blogu Quality Island

• Strategia testowania w organizacji: czego uczy nas case PKO BP
• Raport z testów: co musi zawierać
• Środowisko testowe: jak je przygotować
• Testy niefunkcjonalne: rodzaje według ISO/IEC 25010 i przykłady wymagań
• Jak poprawnie zgłosić błąd

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Rozdział 5.1.1 (cel i zawartość planu testów), 5.1.2 (planowanie wydania i iteracji), 5.1.3 (kryteria wejścia i wyjścia, Definition of Ready i Definition of Done)
• ISTQB, Certified Tester Foundation Level, opis certyfikacji v4.0, 2023
• ISO, IEC, IEEE, ISO/IEC/IEEE 29119-3:2021, Software and systems engineering, Software testing, Part 3: Test documentation, 2021
• Ken Schwaber, Jeff Sutherland, The Scrum Guide, 2020. Definicja Definition of Done
• Przykład planu testów w tym artykule: dane ilustracyjne Quality Island, nie dotyczą konkretnego klienta