Testowanie statyczne: przeglądy, analiza statyczna i checklista wymagań

Testowanie statyczne to sprawdzanie produktów pracy, takich jak wymagania, historyjki użytkownika, kod, plany testów czy kontrakty API, bez uruchamiania oprogramowania. Robicie to ręcznie, w przeglądach, albo narzędziem, w analizie statycznej. Tak definiuje je sylabus ISTQB Certyfikowany Tester Poziom Podstawowy v4.0 w rozdziale 3 i tej terminologii trzymamy się w całym tekście. Najtańszy defekt to ten, który znaleźliście w zdaniu wymagania, zanim ktokolwiek napisał do niego linię kodu i dwadzieścia przypadków testowych.

Ten przewodnik nie kończy się na definicji. Dostajecie porównanie z testowaniem dynamicznym w pięciu punktach z sylabusa, tabelę czterech typów przeglądów, gotową checklistę przeglądu historyjki użytkownika z przykładem znalezionych anomalii oraz instrukcję czytania wyniku analizy statycznej na przykładzie bramki jakości SonarQube. Na końcu plan wdrożenia na pierwsze cztery tygodnie.

Czym jest testowanie statyczne według ISTQB?

Według sylabusa ISTQB CTFL v4.0 (sekcja 3.1) w testowaniu statycznym oprogramowanie nie musi być wykonywane, a produkty pracy ocenia się przez manualne badanie, czyli przeglądy, albo przy pomocy narzędzia, czyli analizę statyczną. Celem jest poprawa jakości, wykrywanie defektów i ocena takich cech jak czytelność, kompletność, poprawność, testowalność i spójność. Testowanie statyczne służy zarówno weryfikacji, jak i walidacji: sprawdzacie, czy dokument jest zrobiony dobrze, i czy opisuje to, czego interesariusze naprawdę potrzebują.

Przeglądowi podlega prawie wszystko, co da się przeczytać i zrozumieć: specyfikacja wymagań, kod źródłowy, plan testów, przypadki testowe, elementy rejestru produktu (backlogu), karty testów eksploracyjnych, dokumentacja projektowa, umowy i modele. Analiza statyczna potrzebuje z kolei struktury, względem której można coś sprawdzić, czyli kodu, modeli albo tekstu o formalnej składni. Sylabus wskazuje też wyjątek: nie analizujecie narzędziami kodu wykonywalnego firm trzecich, jeśli zabraniają tego względy prawne.

Czym testowanie statyczne różni się od dynamicznego?

Testowanie statyczne i testowanie dynamiczne się uzupełniają, a nie konkurują. Mają podobny cel, czyli wykrywanie defektów w produktach pracy, ale robią to inną drogą. Sylabus ISTQB v4.0 w sekcji 3.1.3 wymienia różnice, które zebraliśmy w tabeli, dodając do każdej przykład z codziennej pracy zespołu.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 3.1.3, 2024; przykłady: praktyka Quality Island, 2026.

W praktyce oba podejścia spotykają się w potoku CI: analiza statyczna kodu i testy jednostkowe uruchamiają się przy tym samym commicie, tylko pierwsza czyta kod, a drugie go wykonują. Szerszą mapę tego, gdzie w procesie siedzi który typ testów, znajdziecie w przeglądzie typów testów oprogramowania, a podział na poziomy w artykule o poziomach testowania.

Jakie defekty łatwiej znaleźć statycznie?

Sylabus wymienia siedem grup defektów, które łatwiej albo taniej znaleźć statycznie niż dynamicznie. Przy każdej dopisaliśmy przykład, jaki widzimy w projektach, które audytowaliśmy, żeby lista nie została abstrakcją.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 3.1.3, 2024; przykłady z praktyki Quality Island.

Ile naprawdę oszczędza wczesne wykrycie defektu?

Sylabus ISTQB mówi ostrożnie: przeglądy kosztują, ale ogólne koszty projektu są zwykle znacznie niższe niż bez przeglądów, bo mniej czasu idzie na późne poprawki. Nie podaje mnożnika i dobrze, bo popularne liczby w tej sprawie mają kruche podstawy.

Jak zmierzyć to u siebie? Najprościej przez dwie metryki z sylabusa (sekcja 5.3.1): liczbę defektów znalezionych w przeglądach i odsetek wykrytych defektów w kolejnych fazach. Z naszego doświadczenia wystarczą dwa sprinty z rzetelnym oznaczaniem, w której fazie defekt powstał i w której go znaleziono, żeby zespół przestał dyskutować, czy przeglądy „się opłacają”. Więcej o rachunku kosztów jakości piszemy w tekście o kosztach późno wykrytych błędów i w artykule o shift left testing.

Te liczby pokrywają się z jednym z czynników powodzenia z sylabusa ISTQB (sekcja 3.2.5): przeglądajcie małe fragmenty, żeby przeglądający nie tracili koncentracji. Pull request na 2 000 linii nie zostanie przejrzany, zostanie co najwyżej zatwierdzony.

Jakie są rodzaje przeglądów i który wybrać?

Sylabus ISTQB v4.0 opisuje cztery często stosowane typy przeglądów, od najmniej do najbardziej formalnego. Ten sam produkt pracy może przejść kilka z nich, na przykład najpierw przegląd nieformalny, a potem inspekcję. O wyborze decydują cel, krytyczność i złożoność produktu, wymagania prawne oraz potrzeba śladu audytowego.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 3.2.4, 2024 (polska wersja SJSI 4.0.0.1, 2025).

Uwaga na tłumaczenie, bo przyda się na egzaminie: walkthrough to w polskiej wersji sylabusa przejrzenie, nie „przejście”, jak bywa w tekstach w sieci. Pełne zestawienie zmian między sylabusami opisaliśmy w porównaniu ISTQB 4.0 i 3.1.

Jak przebiega przegląd i kto w nim uczestniczy?

Ogólny proces przeglądu definiuje norma ISO/IEC 20246, a sylabus ISTQB streszcza go w pięciu czynnościach. Im bardziej formalny przegląd, tym więcej zadań z każdej czynności trzeba wykonać.

1. Planowanie. Ustalacie zakres: cel, produkt pracy, oceniane charakterystyki jakościowe, obszary szczególnej uwagi, kryteria wyjścia, standardy, nakład pracy i ramy czasowe.
2. Rozpoczęcie przeglądu. Każdy uczestnik ma dostęp do produktu pracy, zna swoją rolę i dostaje wszystko, czego potrzebuje.
3. Przegląd indywidualny. Każdy przeglądający ocenia produkt i notuje anomalie, zalecenia i pytania, korzystając z techniki przeglądu, na przykład z listy kontrolnej albo scenariuszy.
4. Przekazanie informacji i analiza. Anomalia nie musi być defektem, więc każdą omawiacie i nadajecie jej status, właściciela i działanie. Tu zapada decyzja o poziomie jakości produktu.
5. Usunięcie defektów i raportowanie. Dla każdego defektu powstaje raport o defekcie, po spełnieniu kryteriów wyjścia produkt pracy jest odbierany, a wyniki trafiają do raportu.

Jedna zasada z sylabusa robi największą różnicę w kulturze zespołu: ocena uczestników nigdy nie jest celem przeglądu. Przegląd, po którym autor szuka nowej pracy, znajduje mniej defektów niż przegląd, po którym autor stawia kawę, bo następnym razem pokaże kod wcześniej. O tym, jak przeglądy psują się w praktyce, piszemy też na portalu Strefa QA w tekście o najczęstszych antywzorcach w testowaniu.

Checklista przeglądu historyjki użytkownika: jak wygląda w praktyce?

Sylabus ISTQB wskazuje wprost, że techniki przeglądu stosuje się, żeby historyjki użytkownika były kompletne, zrozumiałe i miały testowalne kryteria akceptacji, a testerzy pomagają je ulepszać, zadając właściwe pytania. Poniżej przykład historyjki, jaką mogliście dostać w piątek po południu, i wynik jej przeglądu indywidualnego.

Historyjka SKLEP-412
Jako zalogowany klient chcę użyć kodu rabatowego w koszyku,
żeby zapłacić mniej.

Kryteria akceptacji:
1. Klient wpisuje kod w polu "Kod rabatowy" i klika "Zastosuj".
2. Poprawny kod obniża cenę.
3. Niepoprawny kod pokazuje komunikat błędu.
4. Strona działa szybko.

Źródło: checklista Quality Island do przeglądu historyjek, oparta na sekcjach 3.1 i 4.5 sylabusa ISTQB CTFL v4.0.1.

Osiem pytań, dwadzieścia minut i siedem anomalii, zanim powstała pierwsza linia kodu. W naszych projektach taka lista żyje w szablonie zadania w narzędziu do śledzenia pracy, więc nikt nie musi jej pamiętać. Jeśli chcecie, żeby wymagania od początku dało się testować, ćwiczymy to na szkoleniu Analiza testowa: od wymagań do przypadków testowych, a progi takie jak w kryterium 4 na szkoleniu Analiza wymagań niefunkcjonalnych (NFR).

Jak czytać wynik analizy statycznej kodu na przykładzie SonarQube?

Analiza statyczna kodu źródłowego to druga noga testowania statycznego. Sylabus ISTQB podkreśla, że często jest częścią potoku CI i poza konkretnymi defektami kodu ocenia też utrzymywalność i bezpieczeństwo. Najczęściej spotykane narzędzie w firmach, z którymi pracujemy, to SonarQube, więc na nim pokażemy, jak czytać wynik.

Wynik zaczyna się od bramki jakości (quality gate), czyli zestawu warunków, które kod musi spełnić, żeby zmiana mogła przejść dalej. Wbudowana bramka „Sonar way” według dokumentacji SonarQube Server ma cztery warunki i wszystkie dotyczą nowego kodu, a nie całego repozytorium:

Źródło: SonarSource, dokumentacja SonarQube Server, Introduction to quality gates, 2026.

Zasada „tylko nowy kod” jest kluczowa dla starszych systemów: nie musicie naprawić 12 000 starych problemów, żeby zacząć, wystarczy nie dokładać nowych. Poniżej uproszczony fragment, na którym analiza statyczna zgłosi kilka problemów, zanim jakikolwiek test go uruchomi.

public BigDecimal naliczRabat(String kod, BigDecimal kwota) {
    String sql = "SELECT procent FROM rabaty WHERE kod = '" + kod + "'";
    Rabat rabat = repozytorium.znajdz(sql);
    int licznik;
    if (rabat.aktywny()) {
        return kwota.multiply(rabat.procent()).divide(new BigDecimal("100"));
    }
    return kwota;
}

Źródło: przykład Quality Island, 2026; nazwy kategorii według modelu ISO/IEC 25010 i dokumentacji SonarQube.

Uruchomienie analizy w Mavenie z czekaniem na wynik bramki wygląda tak, a parametr sonar.qualitygate.wait sprawia, że czerwona bramka zatrzymuje potok:

mvn verify sonar:sonar \
  -Dsonar.host.url=https://sonar.twoja-firma.pl \
  -Dsonar.token=$SONAR_TOKEN \
  -Dsonar.qualitygate.wait=true

Analiza statyczna ma też ograniczenia. Zgłasza fałszywe alarmy, a zespół, który dostaje 300 ostrzeżeń dziennie, przestaje je czytać. Dlatego zaczynacie od małego, uzgodnionego zestawu reguł i rozszerzacie go stopniowo. Wdrożenie takiej bramki w potoku robimy w ramach usługi budowy procesów CI/CD.

Kiedy testowanie statyczne nie działa?

Testowanie statyczne zawodzi zwykle z tych samych kilku powodów. Każdy z nich ma odpowiednik w czynnikach powodzenia z sylabusa ISTQB (sekcja 3.2.5), więc lista działa też jak diagnoza.

• Brak celu i kryteriów wyjścia. „Rzućcie okiem” nie jest celem. Cel to na przykład: wszystkie kryteria akceptacji testowalne, zero anomalii krytycznych otwartych.
• Za duże porcje. Specyfikacja na 80 stron w jednym przeglądzie kończy się przeglądem pierwszych dziesięciu.
• Brak czasu na przygotowanie. Przegląd indywidualny robiony na spotkaniu to czytanie na głos, nie przegląd.
• Ocena ludzi zamiast produktu. Zespół przestaje pokazywać wczesne wersje, a defekty przychodzą później i drożej.
• Szum z narzędzia. Pełny zestaw reguł włączony w pierwszym tygodniu na starym kodzie zabija zaufanie do analizy statycznej.
• Brak domknięcia. Anomalie bez właściciela i statusu wracają w kolejnym wydaniu jako błędy produkcyjne.

Ostatni punkt łączy się z tym, jak zgłaszacie defekty po przeglądzie. Struktura dobrego zgłoszenia jest taka sama jak po testach dynamicznych, opisaliśmy ją w poradniku jak poprawnie zgłosić błąd.

Od czego zacząć testowanie statyczne w Waszym zespole?

Nie zaczynajcie od inspekcji wszystkiego. Z naszego doświadczenia najlepiej działa plan na cztery tygodnie, w którym każdy krok daje widoczny efekt, zanim przyjdzie następny.

Źródło: plan Quality Island, oparty na sekcjach 3.2.2 do 3.2.5 sylabusa ISTQB CTFL v4.0.1.

Po czterech tygodniach porównajcie dwie liczby: ile defektów znaleźliście w przeglądach i ile podobnych defektów wróciło z testów systemowych albo z produkcji. To jest Wasz własny mnożnik, mocniejszy niż każdy wykres z konferencji. Jeśli chcecie zrobić to z zewnętrznym spojrzeniem, sprawdzamy dojrzałość przeglądów i analizy statycznej w ramach audytu QA, a szerszy plan jakości dla całej organizacji, taki jak strategia jakości wdrożona dla PKO BP, układamy w ramach usługi strategia jakości oprogramowania. Wspólny język przeglądów i całego rozdziału 3 daje zespołowi szkolenie Certyfikowany Tester Poziom Podstawowy v4.0. Na wszystkich naszych szkoleniach przeszkoliliśmy już ponad 2 500 specjalistów.

Powiązane na blogu Quality Island

• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Jak napisać plan testów: kompletny przewodnik po dokumencie
• 7 zasad testowania oprogramowania według ISTQB: przykłady z projektów QA
• Testowanie manualne vs automatyczne: jakie proporcje i kiedy automatyzacja się zwraca

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Rozdział 3: definicja testowania statycznego, produkty pracy, różnice wobec testowania dynamicznego, proces przeglądu, role, typy przeglądów i czynniki powodzenia.
• SJSI, Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w. 4.0, wersja polska 4.0.0.1, 2025. Polskie nazwy: przejrzenie, przegląd techniczny, protokolant, lider przeglądu.
• ISO/IEC, ISO/IEC 20246 Software and systems engineering: Work product reviews, 2017. Ogólny proces przeglądu, do którego odwołuje się sylabus.
• SonarSource, SonarQube Server: Introduction to quality gates, 2026. Warunki bramki Sonar way dla nowego kodu.
• SmartBear, Best Practices for Code Review, 2026 (dostęp). 200 do 400 linii na przegląd, poniżej 500 linii na godzinę, do 60 minut, 70 do 90% wykrytych defektów; badanie zespołu Cisco Systems.
• Laurent Bossavit, Leanpub, The Leprechauns of Software Engineering, dostęp 2026. Rozdział 10 o historii krzywej kosztu defektów.
• Dane własne Quality Island, 2026: ponad 2 500 przeszkolonych specjalistów, strategia jakości dla PKO BP (zakres prac), checklista przeglądu historyjek używana w projektach.