Gdy zespół zbliża się do wydania nowej wersji, samo „przetestujemy wszystko” szybko przestaje wystarczać. Potrzebny jest konkretny plan, który pokazuje, co sprawdzamy, jakimi metodami, kto za to odpowiada i kiedy można bezpiecznie zakończyć testy. W dokumentacji spotkasz też angielskie określenie test plans, ale najważniejsze pozostaje praktyczne zarządzanie zakresem, ryzykiem i decyzją o wydaniu.
Dobry plan testów porządkuje decyzje przed wydaniem
- Zakres określa, co zostanie sprawdzone, a co świadomie pozostaje poza testami.
- Podejście oparte na ryzyku kieruje czas zespołu do funkcji najważniejszych dla użytkownika i biznesu.
- Role, środowiska i dane muszą być opisane, zanim rozpocznie się wykonanie testów.
- Kryteria wejścia i wyjścia chronią zespół przed testowaniem w niesprzyjających warunkach i wydaniem produktu z krytycznymi błędami.
- Aktualizowany dokument jest użyteczny także w Agile i CI/CD, gdzie zakres zmienia się często.
Czym jest plan testów i po co zespołowi
Plan testów to dokument opisujący cele, zakres, podejście, zasoby i harmonogram działań testowych dla produktu, wersji albo konkretnego poziomu testów. Nie jest listą wszystkich przypadków testowych. Ma pomóc zespołowi podjąć świadomą decyzję, czy produkt spełnia wymagania i czy ryzyko wydania jest akceptowalne.
W praktyce odróżniam trzy poziomy dokumentacji. Strategia testów mówi, jakie ogólne zasady obowiązują w organizacji lub projekcie. Plan przekłada je na konkretną wersję, a przypadki testowe opisują pojedyncze scenariusze wraz z krokami i oczekiwanym rezultatem.
| Element | Główne pytanie | Przykład |
|---|---|---|
| Strategia | Jak ogólnie testujemy? | Testy oparte na ryzyku, automatyzacja regresji |
| Plan testów | Co i kiedy sprawdzimy w tej wersji? | Nowy proces płatności przed wydaniem aplikacji |
| Przypadek testowy | Jak sprawdzimy konkretną funkcję? | Płatność kartą z poprawnym i błędnym kodem 3-D Secure |
Norma ISO/IEC/IEEE 29119 opisuje plan jako szczegółowy opis celów testowania oraz środków i harmonogramu potrzebnych do ich osiągnięcia. Dopuszcza też kilka planów w jednym projekcie, na przykład plan główny oraz osobne plany dla testów systemowych, wydajnościowych czy akceptacyjnych. To rozsądne podejście, gdy produkt jest duży i jedna strona dokumentu nie wystarcza do zarządzania całością.
Co powinien zawierać dobry plan testów
Nie ma sensu kopiować rozbudowanego szablonu do małego projektu. Dla aplikacji rozwijanej przez kilka osób wystarczy zwięzły dokument, jeśli odpowiada na najważniejsze pytania i wskazuje osobę odpowiedzialną za każdą decyzję.
Cel, zakres i ryzyko
Na początku zapisuję, co testy mają potwierdzić. Celem może być sprawdzenie nowej funkcji, ograniczenie ryzyka utraty zamówień albo potwierdzenie zgodności z wymaganiami bezpieczeństwa. Zakres powinien wyraźnie wskazywać zarówno obszary objęte testami, jak i te wyłączone z bieżącej iteracji.
Najlepiej priorytetyzować testy według ryzyka. Funkcja, która obsługuje płatności lub dane osobowe, zwykle wymaga większej uwagi niż rzadko używany ekran ustawień. Nie testujemy wszystkiego z taką samą intensywnością, bo w praktyce zawsze ograniczają nas czas, ludzie albo dostępne środowiska.
Podejście testowe
Ta część opisuje, jakie poziomy i typy testów zostaną wykorzystane. Mogą to być testy jednostkowe, integracyjne, systemowe, akceptacyjne, wydajnościowe, bezpieczeństwa i użyteczności. Przy każdym typie warto dopisać, co ma wykazać i kto odpowiada za wynik.
Trzeba również określić proporcje między testami manualnymi a automatycznymi. Automatyzacja dobrze sprawdza powtarzalną regresję, ale nie zastąpi oceny użyteczności, eksploracji ani weryfikacji nieoczywistych zachowań. Z mojego doświadczenia wynika, że największy błąd polega na automatyzowaniu scenariuszy, które zmieniają się co kilka dni.
Zasoby, środowisko i dane
Plan powinien wskazywać, kto projektuje przypadki, kto wykonuje testy, kto analizuje defekty i kto zatwierdza wynik. Należy też opisać wersję aplikacji, konfigurację środowiska, obsługiwane przeglądarki, urządzenia oraz wymagane integracje.
Osobnego zapisu wymagają dane testowe. Jeśli test obejmuje płatności, logowanie lub dane osobowe, trzeba ustalić, czy używamy anonimizowanych danych, mocków czy środowiska sandbox. Brak takiej decyzji często opóźnia testy bardziej niż sam błąd w aplikacji.
Przeczytaj również: Jak stworzyć plan testów, który naprawdę działa?
Harmonogram, raportowanie i kryteria zakończenia
Harmonogram nie musi przewidywać każdego dnia pracy. Powinien jednak wskazywać najważniejsze punkty, takie jak gotowość środowiska, rozpoczęcie testów regresji, testy akceptacyjne i termin decyzji o wydaniu. W planie zapisuję też format raportu oraz częstotliwość komunikowania postępu.
Kryteria wyjścia powinny być mierzalne. Przykładowo dla krytycznej wersji można przyjąć brak otwartych defektów blokujących, wykonanie 100% scenariuszy krytycznych oraz uzgodnioną liczbę testów zakończonych wynikiem pozytywnym. To przykład, a nie uniwersalny standard. Próg musi odpowiadać ryzyku produktu i tolerancji biznesu.
Jak przygotować plan testów krok po kroku
Najsprawniej tworzy się go razem z osobami, które później będą korzystać z dokumentu. Sam tester może opisać scenariusze, ale bez udziału dewelopera, product ownera i osoby odpowiedzialnej za wydanie łatwo pominąć ograniczenia techniczne albo biznesowe.
- Opisz produkt i wersję. Zapisz, co jest testowanym obiektem, jaki zakres zmian obejmuje wydanie i jakie wymagania są dla niego najważniejsze.
- Zidentyfikuj ryzyka. Wskaż funkcje, których awaria może wywołać straty finansowe, problemy prawne, utratę danych albo pogorszenie doświadczenia użytkownika.
- Dobierz poziomy i typy testów. Ustal, które obszary wymagają testów jednostkowych, integracyjnych, systemowych, wydajnościowych lub bezpieczeństwa.
- Podziel odpowiedzialność. Przypisz właścicieli zadań, dostęp do środowisk, przygotowanie danych i akceptację wyników.
- Ustal warunki rozpoczęcia i zakończenia. Zdefiniuj, kiedy wersja jest gotowa do testów oraz jakie wyniki pozwalają przejść do wydania.
- Uzgodnij sposób reagowania na zmiany. Określ, kto aktualizuje plan, gdy zmieni się zakres, termin albo poziom ryzyka.
Przykład jest prosty. Dla nowego checkoutu plan może obejmować koszyk, rabaty, płatności i potwierdzenie zamówienia, a poza zakresem pozostawić panel administracyjny. Najwyższy priorytet otrzymają płatności i zapis zamówienia, ponieważ ich awaria bezpośrednio wpływa na przychód.
W takim przypadku kryterium wejścia może brzmieć: dostępna wersja release candidate, przygotowane dane i działająca bramka sandbox. Kryterium wyjścia może obejmować 100% scenariuszy płatności zakończonych poprawnie, brak błędów krytycznych oraz zaakceptowaną listę problemów o niższym priorytecie.
Jak zarządzać testami w Agile i CI/CD
W zwinnym projekcie plan testów nie powinien być dokumentem napisanym raz na początku i później ignorowanym. Aktualizuję go przy zmianie zakresu, ryzyka, architektury lub terminu wydania. W przypadku krótkich sprintów często lepiej sprawdza się lekki plan na poziomie wydania uzupełniany zadaniami w narzędziu do zarządzania pracą.
W CI/CD część kontroli może wykonywać pipeline. Po każdym buildzie warto uruchamiać testy jednostkowe i integracyjne, a przed wdrożeniem na produkcję dodać testy dymne, czyli szybkie sprawdzenie, czy najważniejsze funkcje w ogóle działają. Testy end-to-end powinny być dobrze dobrane, ponieważ są zwykle wolniejsze i bardziej podatne na problemy środowiskowe.
Plan powinien też określać, jak mierzymy postęp. Przydatne są między innymi liczba wykonanych testów, odsetek zakończonych powodzeniem, liczba defektów według priorytetu, czas ich naprawy oraz pokrycie wymagań. Sam procent pozytywnych testów nie mówi jeszcze o jakości, jeśli zespół pominął najważniejsze ryzyka.
W dużych projektach sprawdza się podział na plan główny i plany szczegółowe. ISTQB wskazuje, że planowanie może obejmować osobne dokumenty dla poziomów testów, takich jak testy systemowe i akceptacyjne, albo dla typów testów, na przykład wydajnościowych. Taki podział ułatwia pracę, ale tylko wtedy, gdy ktoś pilnuje spójności między dokumentami.
Najczęstsze błędy w planowaniu testów
| Błąd | Skutek | Lepsze podejście |
|---|---|---|
| Testowanie wszystkiego jednakowo | Brak czasu na obszary wysokiego ryzyka | Priorytetyzacja według wpływu i prawdopodobieństwa awarii |
| Plan bez właścicieli zadań | Problemy pozostają „czyjeś”, ale nikt ich nie rozwiązuje | Jednoznaczne przypisanie odpowiedzialności |
| Brak kryteriów wyjścia | Decyzja o wydaniu opiera się na presji lub intuicji | Uzgodnione progi dla defektów i wykonania testów |
| Nieaktualny dokument | Testerzy pracują według starego zakresu | Krótki przegląd planu przy każdej istotnej zmianie |
| Skupienie wyłącznie na funkcjach | Problemy z wydajnością, bezpieczeństwem lub użytecznością wychodzą za późno | Dobór typów testów do realnych ryzyk produktu |
Często spotykam też plany, które są zbyt długie, ale nie odpowiadają na podstawowe pytania. Kilkadziesiąt stron nie pomoże, jeśli nie wiadomo, co jest najważniejszym ryzykiem i kto podejmuje decyzję o wydaniu. Lepiej mieć pięć aktualnych stron niż rozbudowany szablon, którego nikt nie czyta.
Drugim problemem jest mylenie pokrycia wymagań z dowodem jakości. Pokrycie pokazuje, czy wymagania mają przypisane testy, ale nie mówi, czy wymagania są kompletne ani czy testy obejmują nieoczekiwane zachowania. Dlatego do planu warto dodać testy eksploracyjne i przegląd ryzyk z osobą znającą proces biznesowy.
Nie należy też traktować automatyzacji jako celu samego w sobie. Jeśli utrzymanie testu kosztuje więcej niż ręczne sprawdzenie funkcji wykonywanej raz na kwartał, automatyzacja może być złym wyborem. Największą wartość zwykle dają stabilne scenariusze regresji, które uruchamiamy często i które chronią krytyczne ścieżki użytkownika.
Plan, który pomaga podjąć decyzję o wydaniu
Dobry dokument nie gwarantuje, że produkt będzie wolny od błędów. Daje jednak zespołowi wspólny język do oceny ryzyka i pozwala jasno powiedzieć, co zostało sprawdzone, czego nie sprawdzono i dlaczego.
Przed zatwierdzeniem planu przechodzę przez trzy pytania. Czy zakres odpowiada rzeczywistym zmianom? Czy najpoważniejsze ryzyka mają przypisane testy i właścicieli? Czy kryteria zakończenia pozwalają podjąć decyzję bez zgadywania?
Jeśli odpowiedź na wszystkie trzy pytania brzmi „tak”, plan spełnia swoje zadanie. Nie jest ozdobnym dokumentem dla audytora, tylko praktycznym narzędziem zarządzania jakością, które pomaga wydać produkt z pełną świadomością jego mocnych stron i ograniczeń.
