Testowanie jako proces, nie faza

“Będziemy testować, jak development skończy.”

To zdanie odpowiada za więcej incydentów produkcyjnych, opóźnionych sprintów i problemów z jakością niż niemal każda inna decyzja techniczna. Traktuje testowanie jak fazę — coś, co dzieje się po developmencie — zamiast jak ciągły proces wpleciony w każdy etap budowania oprogramowania.

Przejście od “testowania jako fazy” do “testowania jako procesu” jest częściowo techniczne (pipeline CI/CD, quality gates), ale przede wszystkim kulturowe. W tym artykule wyjaśnię, jak wygląda ta zmiana w praktyce i jak ją wdrożyć krok po kroku.

Stary model: testowanie jako faza

W klasycznym modelu kaskadowym SDLC (Software Development Lifecycle) przepływ wygląda tak:

Wymagania → Projekt → Implementacja → Testowanie → Wdrożenie → Utrzymanie

Testowanie zajmuje jedną konkretną fazę. Praca płynie w jednym kierunku. Defekty znalezione w testowaniu wracają do implementacji — tworząc pętlę feedbacku, która może trwać tygodniami.

Nawet w zespołach, które przeszły na Agile, ten model myślowy przetrwał:

• Planowanie sprintu: programiści biorą story, QA biorą story
• Środek sprintu: programiści budują, QA czeka
• Koniec sprintu: programiści “przekazują” do QA
• QA znajduje bugi, programiści je naprawiają
• Jeśli naprawa zajmuje zbyt długo, funkcje przesuwają się na następny sprint

Brzmi znajomo? To model kaskadowy w sprincie. Ceremonie się zmieniły, model myślowy — nie.

SDLC vs STLC

Kluczowy wniosek: testowanie ma własny cykl życia — STLC (Software Testing Lifecycle) — który działa równolegle z developmentem, nie po nim.

Fazy SDLC:

1. Wymagania
2. Projekt
3. Implementacja
4. Testowanie
5. Wdrożenie
6. Utrzymanie

Fazy STLC:

1. Analiza wymagań → QA przegląda wymagania pod kątem testowalności
2. Planowanie testów → strategia testów, zakres, zasoby
3. Projektowanie testów → pisanie przypadków testowych, zakres automatyzacji
4. Konfiguracja środowiska → środowiska testowe, dane, narzędzia
5. Wykonywanie testów → uruchamianie testów, zgłaszanie defektów
6. Zamknięcie testów → metryki, wnioski, raportowanie

Ważna rzecz: faza 1 STLC zaczyna się, gdy zaczyna się faza 1 SDLC. QA przegląda wymagania gdy product owner je pisze. QA projektuje testy gdy programiści projektują implementację.

W języku Agile: oba cykle działają w ramach każdego sprintu.

Ciągłe testowanie (Continuous Testing)

Ciągłe testowanie oznacza uruchamianie automatycznych testów na każdym etapie pipeline’u dostarczania — otrzymując feedback w minutach, nie w dniach.

To nie tylko “uruchamiaj CI przy każdym commicie.” Ciągłe testowanie wymaga:

• Właściwych testów na właściwym etapie
• Wystarczająco szybkich, by nie przerywać flow programisty
• Wyników możliwych do działania — błędy, które mówią co się zepsuło, nie tylko że coś się zepsuło

Pipeline ciągłego testowania

Pre-commit    →   PR/commit       →   Merge do main    →   Harmonogram
─────────────     ────────────────    ─────────────────    ─────────────────
Testy jedn.       Testy jedn.         Integracyjne         Pełna suita E2E
Linting           Integracyjne        Smoke E2E            Testy wydajn.
Sprawdz. typów    Sprawdz. typów      Skan bezpiecz.       Skany bezpiecz.
                                      Pełna integracja     Audyt dostępności

Czas: <30s        Czas: <5 min        Czas: <15 min        Czas: nieogranicz.

Cel: programista commituje kod i w ciągu 5 minut wie, czy coś ważnego jest zepsute. Nie zmienił jeszcze kontekstu. Naprawa zajmuje minuty, nie godziny.

Zasada 10 minut

Badania nad produktywnością programistów konsekwentnie pokazują, że jeśli pętla feedbacku trwa ponad 10 minut, programiści przestają na nią czekać. Przełączają się na inne zadanie, tracą kontekst, i koszt naprawienia błędu rośnie.

Zmierz swoją obecną pętlę feedbacku: Od git push do “wszystkie sprawdzenia przeszły” — jak długo? Jeśli ponad 10 minut, pipeline wymaga optymalizacji, a nie tylko więcej testów.

Typowe rozwiązania dla wolnych pipeline’ów:

• Zrównoleglenie wykonania testów (uruchamianie na wielu agentach)
• Oddzielenie szybkich testów (jednostkowych) od wolnych (E2E) na różne etapy
• Cache’owanie zależności (npm, NuGet, pip) między uruchomieniami
• Uruchamianie tylko testów dotkniętych zmianami na PRach

Quality gates w CI/CD

Quality gate to twarda blokada w pipeline: “nie przechodź dalej, jeśli ten warunek nie jest spełniony.”

Quality gates to mechanizm, który sprawia, że ciągłe testowanie ma sens. Bez nich błędy testów mają charakter doradczy — łatwo je zignorować pod presją deadlinu.

Rodzaje quality gates

Wskaźnik przejścia testów:

# GitHub Actions — zatrzymaj job, jeśli jakikolwiek test nie przejdzie
- name: Uruchom testy jednostkowe
  run: dotnet test --no-build
  # Kod wyjścia niezerowy = testy nie przeszły = pipeline się zatrzymuje

Minimalne pokrycie kodu:

- name: Sprawdź pokrycie
  run: |
    dotnet test --collect:"XPlat Code Coverage"
    # Zatrzymaj, jeśli pokrycie < 80%
    python sprawdz_pokrycie.py --min 80

Uwaga dotycząca pokrycia: 80% to popularny próg, ale pokrycie mierzy wykonane linie, nie przetestowane scenariusze. Wysokie pokrycie ze słabymi asercjami jest bezwartościowe. Używaj pokrycia jako dolnej granicy, nie sufitu.

Analiza statyczna:

- name: Analiza statyczna
  run: dotnet format --verify-no-changes

Skan bezpieczeństwa:

- name: Skan podatności zależności
  run: dotnet list package --vulnerable --include-transitive

Ochrona gałęzi jako wymuszenie jakości

Reguły ochrony gałęzi na GitHubie sprawiają, że quality gates są obowiązkowe:

# W ustawieniach repozytorium:
# Wymagane sprawdzenia statusu przed mergem:
# - CI / testy-jednostkowe
# - CI / testy-integracyjne
# - CodeQL
# Wymagaj aktualności gałęzi przed mergem
# Wymagaj przynajmniej 1 zatwierdzenia

Przy tych ustawieniach żaden kod nie trafia do main bez przejścia quality gates. Bez wyjątków. Bez “naprawimy to w następnym PR.”

Od fazy do procesu — praktyczna transformacja

Kultury jakości zespołu nie możesz zmienić z dnia na dzień. Ale możesz ją zmienić w pięciu krokach, z których każdy dostarcza wartość sam w sobie:

Krok 1 — QA na planowaniu sprintu (ten sprint) Zaproś QA na planowanie sprintu. Dla każdego story zapytaj: “Po czym będziemy wiedzieć, że to jest gotowe?” Udokumentuj odpowiedź jako kryteria akceptacji. Koszt: 0. Wartość: natychmiastowa.

Krok 2 — Pre-commit hooki dla testów jednostkowych (ten tydzień) Dodaj git pre-commit hook uruchamiający testy jednostkowe przed zezwoleniem na commit. Programiści dostają feedback przed pushem — nie 20 minut później w CI.

Krok 3 — Blokada merge: wymagane zielone CI (ten sprint) Włącz reguły ochrony gałęzi. Żaden PR nie przechodzi bez zielonego CI. To samo w sobie eliminuje całą klasę incydentów “ups, zapomniałem uruchomić testy.”

Krok 4 — Definicja ukończenia zawiera kryteria testów (ten sprint) Dodaj do Definition of Done: “Testy jednostkowe przechodzą,” “Nowy kod ma pokrycie testami,” “Sesja eksploracyjna zakończona dla nowych funkcji.”

Krok 5 — Zaplanowane sesje eksploracyjne (cyklicznie) Zarezerwuj 60–90 minut na sprint na ustrukturyzowane exploratory testing ostatnio wydanych funkcji. Właśnie wtedy znajdziesz bugi, które pominęły testy oskryptowane.

Mierzenie transformacji

Skąd wiesz, że transformacja działa? Śledź te metryki:

Metryka	Przed	Cel
Czas od commitu do feedbacku z testów	30+ minut	< 5 minut
Defekty znalezione w produkcji	Baseline	Malejące kwartał do kwartału
Defekty znalezione przez QA vs przez programistów	QA znajduje większość	Programiści 50%+
Prędkość sprintu stracona na późne odkrycia QA	Wysoka	Bliska zeru
Średni czas wykrycia (MTTD)	Dni	Godziny

Podsumowanie

Przejście od “testowania jako fazy” do “testowania jako procesu” to jedna z najbardziej znaczących zmian, jaką może wprowadzić zespół inżynierski. Redukuje incydenty produkcyjne, skraca cykle sprintowe i sprawia, że jakość staje się wspólną odpowiedzialnością, a nie bottleneckiem.

To też zmiana kulturowa, co oznacza, że wymaga cierpliwości i konsekwencji. Elementy techniczne — quality gates, pipeline CI/CD, pre-commit hooki — to łatwa część. Trudna część to zmiana modelu myślowego.

Zacznij od Kroku 1: zaangażuj QA w planowanie sprintu już w tym sprincie. Nie kosztuje nic i zmienia wszystko.

---

To jest piąty artykuł z serii Seria 1 — QA Ogólne.