Plan testów QA i 3 rodzaje ryzyka, których nikt nie uwzględnia

Większość planów testów wygląda dziś bardzo podobnie. Zakres funkcjonalny, scenariusze pozytywne i negatywne, pokrycie, automatyzacja, środowiska, dane testowe. Dokumenty są coraz bardziej dopracowane, narzędzia nowocześniejsze, wykresy bardziej zielone, a mimo to liczba incydentów na produkcji nie spada. Co gorsza, incydenty wracają w tych samych miejscach, choć w planie testów wszystko zostało opisane, odhaczone i zamknięte.

To frustrujący paradoks jakości. Robicie wszystko zgodnie ze sztuką, a i tak przychodzi telefon z biznesu, że coś nie działa. Odpowiedź jest niewygodna, ale prosta. Plan testów najczęściej odpowiada na pytanie, czy funkcja działa. Za rzadko odpowiada na pytanie, czy system jest bezpieczny w świecie zależności, konfiguracji i ludzkich skrótów. Poniżej trzy ryzyka, które najczęściej wypadają z planów, bo formalnie „to nie bug”, a w praktyce to właśnie one najbardziej bolą.

Trzy ryzyka w jednej tabeli

Ryzyko 1: dryf integracji, czyli cudza zmiana, Wasza awaria

Pierwszym pomijanym ryzykiem jest dryf integracji zewnętrznych. Płatności, dostawcy wiadomości, systemy scoringowe, CRM, platformy logistyczne. W planie testów pojawiają się zwykle jako „sprawdzić integrację”, bez mechanizmu, który realnie chroni przed zmianą po drugiej stronie. To klasyczny ślepy punkt, bo formalnie nic u Was się nie zmieniło, a produkcja przestaje działać.

Odpowiedzią są testy kontraktowe. Martin Fowler opisuje je jako testy, które sprawdzają, czy usługa nadal spełnia oczekiwania konsumenta, zamiast polegać wyłącznie na zaślepce udającej zewnętrzny system. Kluczowa różnica wobec zwykłego testu integracyjnego jest taka, że kontrakt jest artefaktem: żyje razem z kodem, a jego naruszenie widać przed wdrożeniem, nie po nim. Praktyczne wdrożenie tego podejścia opisuje dokumentacja Pact, a raport Postman o stanie API pokazuje, jakie praktyki wokół API są dziś powszechne, a jakie wciąż niszowe.

W planie testów zapisujecie to nie jako pojedynczy przypadek, tylko jako stały mechanizm kontroli. Kontrakt jako artefakt utrzymywany razem z kodem. Testy kontraktowe uruchamiane cyklicznie, nie tylko przy zmianie po Waszej stronie. Monitoring syntetyczny najważniejszych endpointów, żeby złapać degradację, zanim zrobi to klient. I plan awaryjny: rozwiązanie zastępcze, przełącznik funkcji, szybkie przejście na wersję zgodną. To jest testowanie ryzyka, a nie testowanie pojedynczej funkcji.

Ryzyko 2: rozjazd konfiguracji, czyli inne środowisko, inne prawa fizyki

Drugie ryzyko, które notorycznie wypada z planów, to rozjazd konfiguracji między środowiskami. Środowisko testowe i produkcja „teoretycznie są takie same”, ale w praktyce różnią się czasami oczekiwania, limitami, flagami funkcji, wersjami zależności, politykami pamięci podręcznej i parametrami skalowania. Testy przechodzą, bo działają na środowisku testowym. Produkcja pada, bo działa na innym zestawie reguł. A potem słyszycie: przecież testowaliśmy, było zielono.

W świecie infrastruktury jako kodu to zjawisko ma nazwę: dryf, czyli sytuacja, w której realny stan infrastruktury odjeżdża od tego, co jest w konfiguracji. HashiCorp opisuje wykrywanie takiego rozjazdu jako osobną funkcję platformy, dokładnie dlatego, że sam plik konfiguracyjny nie gwarantuje, jak wygląda środowisko dziś. Dla QA to ważny sygnał: jeśli nikt nie sprawdza parytetu, testy sprawdzają aplikację w warunkach, których produkcja nie zna.

W planie testów oznacza to trzy zapisy. Definicja parytetu: co ma być identyczne między środowiskami, a co może się różnić i dlaczego. Automatyczna walidacja rozjazdu przed wdrożeniem, jako część bramki, nie jako zadanie na później. I testy niefunkcjonalne oparte na parametrach produkcyjnych, a nie „na oko”. Osobny punkt to flagi funkcji i konfiguracja uruchomieniowa, bo to najczęstsze miejsce cichej różnicy: kod jest ten sam, zachowanie inne. Podobny mechanizm dotyczy danych: środowisko testowe zasilane zrzutem z produkcji wygląda realistycznie, a jest jednocześnie ryzykiem, o czym piszemy w tekście o danych testowych a GDPR.

Ryzyko 3: obejście kontroli, czyli bramka ominięta „tylko raz”

Trzecie ryzyko jest najbardziej niewygodne, bo dotyczy ludzi. Sytuacji, w której ktoś pod presją czasu omija kontrolę jakości: pomija testy, robi wdrożenie awaryjne, wypuszcza poprawkę bez pełnego zestawu bramek. To ryzyko prawie nigdy nie trafia do planu testów, bo plan zakłada, że proces działa. A w realnym świecie proces bywa obchodzony. Mechanizm jest prosty i powtarzalny: jeśli bramkę da się ominąć, prędzej czy później ktoś ją ominie. Nie ze złej woli, tylko z presji.

Tu plan testów powinien zawierać nie przypadek testowy, tylko politykę. Kiedy wolno zrobić wyjątek, a kiedy nie. Kto może go zatwierdzić i jak jest dokumentowany. Ślad audytowy: kto, kiedy, dlaczego. Zasada dwóch par oczu przy wydaniach wysokiego ryzyka. I obowiązkowy przegląd po każdym obejściu, nawet jeśli się udało, bo to też jest sygnał ryzyka. To testowanie procesu, nie funkcji, i często właśnie ono decyduje o różnicy między „mieliśmy pecha” a „mieliśmy system”.

Dlaczego te ryzyka wypadają z planów testów

Wszystkie trzy mają jedną wspólną cechę: nie pasują do klasycznego modelu testowania. Nie są pojedynczym przypadkiem testowym, nie da się ich przypiąć do jednej historyjki użytkownika, nie mają jednego właściciela. Leżą na styku QA, DevOps, bezpieczeństwa i produktu, a wszystko, co leży na styku, ma tendencję do wypadania z dokumentu. Dochodzi do tego psychologia: plan testów lubi rzeczy, które da się odhaczyć, a ryzyka integracyjne, konfiguracyjne i procesowe wymagają mechanizmów ciągłej kontroli, nie odhaczenia.

Efekt jest taki, że dokument wygląda profesjonalnie i daje fałszywe poczucie bezpieczeństwa. To najdroższy rodzaj ryzyka, bo nikt go nie widzi na przeglądzie. Podobny mechanizm działa przy metrykach: zielony wykres uspokaja, choć nie mówi nic o ryzyku, o czym piszemy w tekście o tym, dlaczego dashboard jakości kłamie.

Jak powinien wyglądać dobry plan testów

Dojrzały plan nie zaczyna się od listy przypadków testowych. Zaczyna się od mapy ryzyk: krytyczne ścieżki biznesowe, zależności zewnętrzne, parytet środowisk, miejsca, w których człowiek może obejść system. Dopiero potem dobiera się techniki, bo technika ma być odpowiedzią na ryzyko, a nie rytuałem. W praktyce taki plan działa jak filtr z trzema koszykami.

I tu wraca ekonomia jakości. Jeśli duża część czasu zespołu idzie na naprawy i pracę nieplanowaną, to znaczy, że koszt ryzyk jest wysoki, a plan testów nie trafia w główne źródła strat. W takiej sytuacji nie potrzebujecie więcej testów. Potrzebujecie lepszego planowania ryzyka: mniej scenariuszy o niskiej wartości, więcej kontroli tam, gdzie ryzyko eksploduje najdrożej. Jak policzyć, ile te straty realnie kosztują, rozkładamy w tekście o tym, ile naprawdę kosztuje bug w produkcji.

Podsumowanie

Jeśli w Waszym planie testów nie ma zależności zewnętrznych, parytetu konfiguracji i ryzyka obejścia bramek, macie dokument, który wygląda profesjonalnie, ale daje fałszywe poczucie bezpieczeństwa. Trzy mechanizmy, które to zmieniają, są tanie w porównaniu z jednym incydentem: testy kontraktowe dla krytycznych integracji, automatyczna kontrola parytetu środowisk i spisana polityka wyjątków ze śladem audytowym.

W Quality Island pomagamy zespołom QA i liderom IT przejść z testowania funkcji na zarządzanie ryzykiem jakościowym. Robimy to w ramach zarządzania testami: mapa ryzyk, krytyczne ścieżki, mechanizmy wykrywania dryfu i zasady dotyczące wyjątków. Jeśli chcecie zobaczyć, jakie ślepe punkty ma dziś Wasz plan testów, zacznijcie od trzeciego pytania z tego tekstu: ile razy w ostatnim kwartale ktoś ominął bramkę i gdzie to jest zapisane. Odpowiedź zwykle mówi więcej niż cały dokument. Bo jakość nie kończy się tam, gdzie kończą się przypadki testowe.