Strategia testowania w projekcie zwinnym to zapisana decyzja o tym, co, kiedy i na jakim poziomie sprawdzamy, zanim zmiana trafi na produkcję. Zmienia się nie jej definicja, a własność zestawu testów: utrzymuje go cały zespół razem z kodem, a nie osobna faza przed wydaniem. Ta zmiana nie ma jednej daty ani dokumentu.
Na skróty
Czego dowiesz się z artykułu:
- Co musi zawierać strategia testowania, żeby cokolwiek rozstrzygała
- Jak rozłożyć poziomy i typy testów, nie powielając tego samego pokrycia
- Co w praktyce oznacza przesunięcie testów w lewo
- Jaka rola zostaje dla test managera w zespole zwinnym
Dla kogo jest ten artykuł:
- Liderzy zespołów i test managerowie układający testowanie w pracy iteracyjnej
- Testerzy przechodzący z modelu fazowego do pracy w zespole produktowym
- Kierownicy projektów rozliczani z jakości, a nie z liczby wykonanych przypadków
Czas czytania: 7 minut
Co faktycznie rozstrzyga strategia testowania
Strategia odpowiada na pytania, których nie da się rozstrzygać osobno przy każdej zmianie: które poziomy testów są obowiązkowe, co blokuje wydanie, kto decyduje o ryzyku i jakie dane są używane do testów. Tym różni się od planu testów, który jest doraźny i dotyczy jednego zakresu albo wydania. Dokument, który zamiast tego opisuje narzędzia i nazwy środowisk, nie jest ani strategią, ani planem — jest inwentarzem.
Pierwszym rozstrzygnięciem jest zakres obowiązkowy. W zespole zwinnym najlepiej sprawdza się zapisanie go w definicji ukończenia: zmiana jest gotowa, gdy ma testy jednostkowe, przechodzi testy integracyjne i ma sprawdzony główny przepływ użytkownika. Reszta jest decyzją o ryzyku, podejmowaną świadomie i z nazwiskiem, nie przez pominięcie.
Drugim jest język. Program poziomu podstawowego opisany na istqb.org porządkuje terminologię testowania: poziomy testów — testy komponentów, integracji komponentów, systemowe, integracji systemów i akceptacyjne — oraz typy testów (funkcjonalne, niefunkcjonalne, czarnoskrzynkowe i białoskrzynkowe), obok których osobną kategorią są testy związane ze zmianą: potwierdzające i regresji. To nie jest formalizm — zespoły bez wspólnego słownika spierają się o to, czy coś jest „testem integracyjnym”, zamiast rozmawiać o pokryciu ryzyka.
Poziomy i typy: jak nie powielać tego samego pokrycia
Piramida testów jest modelem rozkładu, nie przepisem: najwięcej szybkich testów nisko (jednostkowe), mniej na poziomie integracji, najmniej kosztownych testów przez interfejs użytkownika. Model nie mówi, ile ma być testów — mówi, że koszt utrzymania i czas wykonania rosną ku górze, więc tam przenosi się tylko to, czego nie da się sprawdzić niżej.
Typowy błąd to równoległe pokrywanie tej samej reguły biznesowej na każdym poziomie naraz. Wygląda bezpiecznie i kosztuje podwójnie: każda zmiana reguły wymaga poprawy wszystkich warstw, więc zespół zaczyna omijać testy, bo to one spowalniają zmianę. Skuteczna reguła jest prostsza: reguła sprawdzana jednostkowo, integracja sprawdzana na styku, interfejs sprawdzany na głównych przepływach.
Odrębną decyzją są dane testowe. Bez ustalonego sposobu ich przygotowania zespół wraca do testów ręcznych, bo zestaw danych okazuje się nieodtwarzalny. Zapis w strategii może być krótki: skąd dane pochodzą, jak są anonimizowane i kto odpowiada za ich odświeżenie.
Przesunięcie testów w lewo i automatyzacja jako zdolność
Przewodnik learn.microsoft.com o przesunięciu testów w lewo opisuje to podejście jako wykonywanie testów wcześniej i częściej, blisko momentu wprowadzenia zmiany, zamiast gromadzenia ich w fazie przed wydaniem. Dla zespołu oznacza to konkret: zestaw szybkich testów przy każdej zmianie w kodzie i pełniejszy zestaw na gałęzi głównej, a nie jedna wielka kampania przed terminem.
Materiał dora.dev o automatyzacji testów stawia drugą część tej samej sprawy: automatyzacja jest zdolnością zespołu, utrzymywaną razem z kodem, a nie projektem zamkniętym po wdrożeniu narzędzia. Praktyczny wniosek jest niewygodny — zestaw, którego nikt nie naprawia po czerwonym przebiegu, w ciągu kilku tygodni przestaje być bramką i zaczyna być szumem.
Zmiana, o którą tu idzie, nie ma daty ani dokumentu, który by ją ogłosił — widać ją w tym, czego wymagają dziś materiały dora.dev i learn.microsoft.com cytowane wyżej. Zestaw traktowany jako zdolność zespołu potrzebuje danych testowych i środowisk odtwarzalnych na żądanie; przesunięcie w lewo bez nich kończy się szybkimi testami, które nie mają na czym działać.
Co zostaje dla test managera
Rola test managera w zespole zwinnym nie znika — przestaje być rolą planisty kampanii testowej. Zostaje odpowiedzialność za strategię jako całość: za wybór poziomów obowiązkowych, za analizę ryzyka produktu, za jakość danych testowych i za to, żeby zestaw automatyczny pozostawał bramką, a nie dekoracją.
Druga część tej roli jest trudniejsza do zapisania: utrzymanie wspólnego słownika i rozstrzyganie sporów o pokrycie. Tam, gdzie tego nikt nie robi, każdy zespół produktowy wytwarza własną terminologię i po kilku iteracjach raporty z sąsiednich zespołów przestają być porównywalne.
Najkrótszy test skuteczności strategii: weź ostatnią awarię na produkcji i sprawdź, na którym poziomie powinna zostać wykryta. Jeśli odpowiedź brzmi „na żadnym, bo nie mamy tam testów” — to jest właśnie następny punkt do zapisania.
Czytaj także
- Rodzaje testów oprogramowania — przewodnik dla zespołów IT — uporządkowane poziomy i typy testów, przydatne przy ustalaniu zakresu obowiązkowego
- Certyfikacja ISTQB — jak się przygotować do egzaminu — ścieżka certyfikacyjna dla osób porządkujących terminologię testowania
- Automatyzacja testów — Selenium, Cypress, Playwright: porównanie — warstwa narzędziowa dla zestawu, który ma zostać bramką
Rozwijaj kompetencje
Temat rozwijają szkolenia Automatyzacja testów — Selenium WebDriver i Java od podstaw do frameworka oraz Automatyzacja testów — Selenium WebDriver i Robot Framework. Pierwsze buduje framework testowy od podstaw, drugie pracuje na podejściu słowa kluczowego i czytelności zestawu. Skontaktuj się z nami, żeby dopasować zakres do stosu Twojego zespołu.
Najczęściej zadawane pytania (FAQ)
Co w strategii testowania zmienia automatyzacja testów w DevOps?
Przenosi punkt rozstrzygnięcia z fazy przed wydaniem do momentu wprowadzenia zmiany. Strategia musi wtedy nazwać, który zestaw biegnie przy każdej zmianie, który na gałęzi głównej i co się dzieje po czerwonym przebiegu. Bez tej ostatniej reguły zestaw przestaje być bramką, a zespół uczy się go omijać.
Czy certyfikacja ISTQB jest potrzebna, żeby napisać strategię testowania?
Nie jest warunkiem, ale daje to, czego brak najczęściej psuje strategie: wspólny słownik poziomów i typów testów. Program poziomu podstawowego porządkuje terminologię, dzięki czemu zapis „testy integracyjne obowiązkowe” znaczy to samo dla testera, programisty i kierownika projektu.
Jak testować API w strategii zwinnej?
Na poziomie integracji, przed testami przez interfejs użytkownika, i z kontraktem jako przedmiotem sprawdzenia: zgodność struktury odpowiedzi, kody błędów, obsługa brakujących pól. Testy przez interfejs zostawia się wtedy dla głównych przepływów użytkownika, bo tam są najdroższe w utrzymaniu.
Jak testować aplikacje webowe, gdy zespół nie ma testera?
Przez zapisanie minimum w definicji ukończenia i automatyzację tego minimum: testy jednostkowe reguł, sprawdzenie głównego przepływu w przeglądarce i szybki przebieg na każdej zmianie. Brak testera nie usuwa potrzeby strategii — przenosi odpowiedzialność za nią na lidera zespołu, który musi ją zapisać, zanim pierwsza awaria to zrobi za niego.