Dobry plan testów to nie 30-stronicowy dokument, którego nikt nie czyta, tylko krótka odpowiedź na pytanie: co, jak i kiedy sprawdzamy, żeby wypuścić produkt bez niespodzianek. W praktyce u klientów widzę, że problem rzadko leży w braku narzędzi czy testerów, leży w tym, że nikt na starcie nie ustalił zakresu, ryzyk i kryteriów wyjścia. Ten wpis pokazuje, od czego zacząć, i daje mini-szablon do wypełnienia w godzinę zamiast w tydzień.
Po co w ogóle plan testów
Plan testów robi trzy rzeczy naraz. Po pierwsze, wymusza rozmowę, zanim zaczniemy klikać, ktoś musi powiedzieć, co jest krytyczne, a co możemy odpuścić. Po drugie, daje wspólny język zespołowi, product ownerowi i klientowi: jeśli w planie stoi, że wydajność testujemy dopiero po MVP, nikt się później nie zdziwi. Po trzecie, chroni testera, kiedy pada pytanie „dlaczego tego nie sprawdziliście”, masz na piśmie, że dany obszar był świadomie poza zakresem.
Największy błąd to traktowanie planu jak formalności do odhaczenia. Drugi największy, przekombinowanie. Nie potrzebujesz szablonu IEEE 829 w projekcie, który robią trzy osoby przez sześć tygodni. Potrzebujesz jednej strony, do której realnie wracasz.
Kluczowe elementy planu testów
Niezależnie od skali projektu, dobry plan odpowiada na kilka konkretnych pytań. Nie każde wymaga akapitu, czasem wystarczy jedno zdanie. Ważne, żeby żadnego nie pominąć milczeniem.
Zakres i cele: co testujemy, a czego nie
Zacznij od tego, co jest w zakresie (in scope) i, równie ważne, co poza nim (out of scope). Jeśli integrację z systemem płatności testujemy tylko na sandboxie, a produkcyjnych transakcji nie ruszamy, napisz to wprost. Cel opisz mierzalnie: nie „przetestować aplikację”, tylko „potwierdzić, że rejestracja i logowanie działają na trzech głównych przeglądarkach”.
Ryzyka: od nich planuj priorytety
To sekcja pomijana najczęściej, a dająca najwięcej. Wypisz, co może pójść nie tak i co boli najbardziej: utrata danych klienta, błąd w płatnościach, RODO, niedostępność w godzinach szczytu. Ryzyko układa priorytety, obszar wysokiego ryzyka testujesz wcześnie i dokładnie, niskiego pobieżnie albo wcale. To sedno testowania opartego na ryzyku.
Poziomy i typy testów
- Jednostkowe i integracyjne: zwykle po stronie deweloperów, ale warto wiedzieć, co pokrywają, żeby nie dublować pracy.
- Systemowe / funkcjonalne: serce pracy QA: sprawdzamy, czy funkcje działają zgodnie z wymaganiami.
- Akceptacyjne (UAT): potwierdzenie od strony biznesu, że produkt naprawdę rozwiązuje problem.
- Niefunkcjonalne: wydajność, bezpieczeństwo, dostępność, o ile są w zakresie.
Tu też decydujesz, co idzie manualnie, a co automatyzujesz, np. Selenium lub Playwright do testów interfejsu, JMeter do testów wydajności, i czy automaty uruchamiają się przy każdej zmianie w pipeline CI/CD. O tym, kiedy automatyzacja faktycznie się opłaca, piszę we wpisie testy manualne czy automatyczne.
Środowiska i dane testowe
Napisz, gdzie testujesz (dev, staging, produkcja tylko do smoke testów) i skąd bierzesz dane. Brak realistycznych danych testowych potrafi zablokować cały harmonogram, zaplanuj to wcześnie: anonimizowana kopia produkcji, generator danych albo ręcznie przygotowane konta testowe. Wskaż też, kto odpowiada za dostępność środowiska, bo „staging padł” to najczęstsze usprawiedliwienie poślizgów.
Kryteria wejścia i wyjścia
Kryteria wejścia mówią, kiedy w ogóle zaczynamy testy (np. build wdrożony na staging, dokumentacja gotowa). Kryteria wyjścia mówią, kiedy kończymy i możemy wydać: wszystkie przypadki krytyczne przeszły, brak otwartych błędów blokujących, kluczowe ścieżki pokryte. Bez tego testy „kończą się”, gdy skończy się czas, a to nie to samo co gotowość do wydania.
Harmonogram i role
Nie musisz rozpisywać go co do dnia. Wystarczy kolejność i punkty zależne od innych zespołów: kiedy dostajemy build, ile trwa cykl testów, kiedy jest bufor na regresję po poprawkach. Do ról wystarczy jedno zdanie: kto pisze przypadki, kto wykonuje, kto akceptuje wydanie. Jasny właściciel decyzji „wydajemy / nie wydajemy” jest ważniejszy niż ładny wykres Gantta.
Jak zacząć lekko i nie przekombinować
Moja rada z praktyki: pierwszą wersję napisz na jednej stronie i pokaż zespołowi tego samego dnia. Lepszy szkic, który wywoła dyskusję, niż idealny dokument oddany na końcu projektu. Szczegóły dopisuj tylko tam, gdzie realnie brakuje jasności.
Kiedy zakres i ryzyka są spisane, kolejny naturalny krok to rozbicie ich na konkretne scenariusze, pokazuję to we wpisie o tym, jak napisać dobry przypadek testowy.
Mini-szablon planu testów (lista sekcji)
Skopiuj poniższe sekcje do dokumentu i wypełnij jednym–dwoma zdaniami każdą. Dla większości projektów małej i średniej skali to wystarczy.
| Sekcja | Co wpisać |
|---|---|
| 1. Cel i kontekst | Co i po co testujemy, w jednym zdaniu |
| 2. Zakres | In scope / out of scope, wprost |
| 3. Ryzyka | Co boli najbardziej, priorytety |
| 4. Poziomy i typy testów | Funkcjonalne, UAT, niefunkcjonalne, manualne vs. automatyczne |
| 5. Środowiska i dane | Gdzie testujemy, skąd dane, kto pilnuje |
| 6. Kryteria wejścia/wyjścia | Kiedy zaczynamy, kiedy wydajemy |
| 7. Harmonogram | Kolejność, zależności, bufor na regresję |
| 8. Role | Kto pisze, wykonuje, akceptuje |
| 9. Narzędzia i raportowanie | Gdzie żyją przypadki i błędy, jak raportujemy |
Jak pomagam w tym jako QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości i najczęściej wchodzę do projektów właśnie na tym etapie, kiedy testy „jakoś się dzieją”, ale nikt nie wie, czy da się bezpiecznie wydać. Pomagam ustawić plan testów proporcjonalny do ryzyka i skali projektu, wskazać, co automatyzować, a co zostawić manualnie, i wpiąć to w codzienną pracę zespołu. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta. Zobacz zakres usług oraz to, jak wygląda współpraca krok po kroku.
Jeśli zaczynasz nowy projekt albo chcesz uporządkować testy w trwającym, odezwij się. Wspólnie przejdziemy przez powyższe sekcje i wyjdziesz z gotowym, lekkim planem.