7 zasad testowania oprogramowania według ISTQB: przykłady z projektów QA

7 zasad testowania to siedem obserwacji opisanych w sylabusie ISTQB Certyfikowany Tester Poziom Podstawowy 4.0, które tłumaczą, czego testowanie oprogramowania może dowieść, a czego nie, gdzie szukać błędów i kiedy zaczynać testy. Znacie je pewnie z egzaminu. W tym artykule pokazujemy, jak każda z nich wygląda w prawdziwym projekcie i jaką decyzję z niej wyciągnąć w poniedziałek rano.

Wiele zespołów testuje intensywnie, a błędy i tak trafiają na produkcję. Rzadko winna jest pracowitość, częściej brak wspólnych założeń: tester zakłada, że regresja jest kompletna, product owner, że „przetestowane” znaczy „bez błędów”, a programista, że testy zaczną się dopiero po merge’u. Siedem zasad testowania oprogramowania porządkuje te założenia, zanim zamienią się w incydent.

Czym jest 7 zasad testowania według ISTQB?

Sylabus ISTQB w wersji 4.0.1 z września 2024 roku opisuje siedem zasad w podrozdziale 1.3 i od kandydata na egzaminie oczekuje, że potrafi je objaśnić. Każda zasada ma w sylabusie źródło w literaturze, od raportu NATO z 1970 roku po książkę Kanera z 2011 roku, więc to nie są slogany, tylko streszczenie kilkudziesięciu lat obserwacji. Polskie brzmienie pochodzi z tłumaczenia Stowarzyszenia Jakości Systemów Informatycznych.

Jeśli przygotowujecie się do certyfikacji, cały sylabus przerobicie na szkoleniu Foundation Level 4.0, a o tym, komu egzamin się opłaca, piszemy w tekście certyfikat ISTQB: czy warto go zdawać. Dalej skupiamy się na praktyce.

Zasada 1: dlaczego testy nie dowodzą braku błędów?

Bo testy sprawdzają próbkę, nie całość. Sylabus mówi wprost, że testowanie zmniejsza prawdopodobieństwo, że w produkcie zostaną niewykryte defekty, ale samo niewykrycie defektów nie jest dowodem poprawności. Zielony raport z 400 przypadków testowych oznacza tylko tyle, że te 400 ścieżek działa w tych danych i w tym środowisku.

W praktyce zasada 1 zmienia przede wszystkim sposób raportowania. W naszych projektach z sektora medycznego, gdzie dla ChaosGears budowaliśmy dokumentację testową i odbiorczą oraz realizowaliśmy procedury odbiorcze, raport z odbioru nigdy nie mówi „system wolny od błędów”. Mówi, które wymagania pokryto, którymi testami, z jakim wynikiem i jakie ryzyka zostały świadomie zaakceptowane. To zdanie mniej efektowne, za to nie da się go podważyć.

Zamiast „aplikacja przetestowana, brak błędów” piszcie „wykonano 412 z 430 zaplanowanych przypadków, 3 defekty otwarte, w tym 0 krytycznych, nie testowano płatności kartą firmową”. Dla osoby decydującej o wydaniu to dużo lepsza informacja, bo widzi, gdzie kończy się wiedza zespołu.

Zasada 2: co testować, skoro wszystkiego się nie da?

To, co najbardziej boli, gdy zawiedzie. Sylabus zaleca zamiast testowania gruntownego trzy narzędzia: techniki projektowania testów, ustalanie priorytetów przypadków testowych i testowanie oparte na ryzyku. Prosty formularz z pięcioma polami po dziesięć wartości to już 100 000 kombinacji, a prawdziwy system ma setki formularzy, integracje i konfiguracje przeglądarek. Kto obiecuje przetestować wszystko, zwykle obiecuje też, że ten sprint na pewno skończy się w piątek.

U naszych klientów z branży wynajmu samochodów kryterium ryzyka było oczywiste: sezon wakacyjny i proces rezerwacji. W projekcie dla Autono liczyły się dwa obszary, proces rezerwacji i obciążenie w sezonie, a efekt potwierdzony przez klienta to system stabilny przy ruchu większym o 120 procent w sezonie i o 55 procent mniej błędów krytycznych w procesach rezerwacji. Nikt nie testował wszystkiego. Testowano właściwe rzeczy, mocniej niż resztę.

Jak ustalić, co jest „właściwe”, rozpisujemy w artykule o ryzyku projektowym w testowaniu i zasadzie Pareto. Najprostsza wersja to macierz: prawdopodobieństwo awarii razy skutek dla użytkownika i biznesu, oceniane razem przez testera, programistę i product ownera.

Zasada 3: ile naprawdę oszczędza wczesne testowanie?

Sylabus nie podaje jednej liczby i dobrze, bo popularne „błąd na produkcji kosztuje 100 razy więcej” trudno dziś udokumentować. Podaje mechanizm, za Boehmem z 1981 roku: defekt usunięty wcześnie nie powoduje kolejnych defektów w produktach pochodnych, więc spada koszt jakości. Błąd w wymaganiu, który przeżyje do kodu, rodzi błędny kod, błędne testy i błędną dokumentację naraz.

Skalę problemu pokazują dwa raporty. Według badania NIST z 2002 roku roczny koszt niedostatecznej infrastruktury testowania oprogramowania w gospodarce USA wynosił 59,5 miliarda dolarów, a realnie możliwe usprawnienia mogły obniżyć go o 22,2 miliarda. Raport CISQ z 2022 roku szacuje łączny koszt złej jakości oprogramowania w USA na co najmniej 2,41 biliona dolarów.

Wczesne testowanie to najczęściej testowanie statyczne: przegląd wymagań, kryteriów akceptacji i projektu, zanim ktokolwiek otworzy IDE. Najtańsze pytanie testera brzmi „co ma się stać, jeśli użytkownik zrobi to dwa razy?”, zadane na refinemencie. Przy audytach procesów, które prowadzimy w Quality Island, brak testera na etapie wymagań to jedno z pierwszych ustaleń, a plan testów spisany przed sprintem zwykle wystarcza, żeby to zmienić.

Zasada 4: jak znaleźć skupiska defektów we własnym trackerze?

Sylabus mówi, że zwykle większość wykrytych defektów albo awarii w eksploatacji pochodzi z niewielkiej liczby modułów, co jest ilustracją zasady Pareto, i powołuje się na badanie Endersa z 1975 roku. Dobra wiadomość: nie musicie zgadywać, gdzie są te moduły. Odpowiedź leży w Waszym trackerze. Wystarczy eksport zgłoszeń do CSV i kilkanaście linijek Pythona.

import csv
from collections import Counter

# Eksport z Jiry: wyszukiwanie zgłoszeń, Export, CSV (all fields).
# Przy kilku komponentach Jira tworzy kilka kolumn "Component/s",
# DictReader bierze wtedy ostatnią, więc do analizy wystarczy jedna na zgłoszenie.
with open("defekty.csv", newline="", encoding="utf-8") as plik:
    komponenty = Counter(
        wiersz.get("Component/s") or "bez komponentu"
        for wiersz in csv.DictReader(plik)
        if wiersz.get("Issue Type") == "Bug"
    )

suma = sum(komponenty.values())
narastajaco = 0
for komponent, liczba in komponenty.most_common():
    narastajaco += liczba
    print(f"{komponent:<30} {liczba:>5} {narastajaco / suma:>7.1%}")

Skrypt wypisuje komponenty od najbardziej zabugowanego, z udziałem narastającym. Interesuje Was moment, w którym kolumna procentów przekracza 70 do 80 procent: komponenty powyżej tej linii to Wasze skupiska. Jak przeczytać wynik i co z nim zrobić, pokazuje tabela.

Sylabus łączy tę zasadę z testowaniem opartym na ryzyku: przewidywane i zaobserwowane skupiska są wejściem do analizy ryzyka. Z naszego doświadczenia wynika jeszcze jedna rzecz: najciekawsze bywa skupisko, którego nikt się nie spodziewał, bo zwykle wskazuje moduł bez właściciela.

Zasada 5: paradoks pestycydów, czyli kiedy testy się zużywają?

Gdy te same testy, na tych samych danych, od miesięcy świecą na zielono. W sylabusie 4.0 zasada nazywa się „testy ulegają zużyciu” (Tests wear out), w starszych wersjach i w codziennym języku testerów funkcjonuje jako paradoks pestycydów: szkodniki uodparniają się na ten sam oprysk, a kod na ten sam zestaw scenariuszy. Sylabus powołuje się tu na Beizera z 1990 roku i zaleca modyfikowanie testów i danych testowych oraz pisanie nowych.

Ważny niuans, który często umyka: sylabus sam zaznacza, że powtarzanie tych samych testów bywa korzystne, a przykładem jest automatyczne testowanie regresji. Regresja nie ma szukać nowych błędów, ma pilnować, żeby stare nie wróciły. U klienta Argos z branży e-commerce automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin, a liczba awarii w okresach szczytowych spadła o 72 procent. Paradoks pestycydów dotyczy więc testów, od których oczekujecie odkryć, nie siatki bezpieczeństwa.

Praktyczny podział, który stosujemy: zestaw regresji automatycznej zostaje stabilny, a odkrywanie przenosicie do testów eksploracyjnych z nowymi celami co sprint. Jak to zrobić krok po kroku, opisujemy w artykule jak skrócić testy regresyjne z 5 dni do 10 godzin, a szersze tło daje tekst o testowaniu manualnym i automatycznym.

Zasada 6: jak kontekst zmienia sposób testowania?

Sylabus ujmuje to w dwóch zdaniach: nie ma jednego uniwersalnego podejścia, a testowanie wykonuje się różnie w różnych kontekstach, za Kanerem i współautorami z 2011 roku. W praktyce kontekst to branża, regulacje, skala ruchu, sposób wydawania wersji i to, kto ponosi skutek błędu. Te same trzy pytania dają w różnych firmach zupełnie inne odpowiedzi.

W bankowości i medycynie dochodzi jeszcze wymóg testów niezależnych od producenta oprogramowania, czyli wprost kontekst prawny, nie techniczny. Jak to wygląda w praktyce, opisujemy na przykładzie audytu QA w sektorze regulowanym. Jeśli chcecie zaprojektować podejście pod własny produkt, punktem wyjścia jest strategia jakości oprogramowania.

Zasada 7: dlaczego brak defektów nie oznacza sukcesu?

Bo weryfikacja sprawdza, czy zbudowaliście system zgodnie ze specyfikacją, a nie czy specyfikacja była dobra. Sylabus mówi, że nawet dokładne przetestowanie wszystkich wymagań i usunięcie wszystkich defektów nie chroni przed systemem, który nie zaspokoi potrzeb użytkowników, nie pomoże w osiągnięciu celów biznesowych albo przegra z konkurencją. Dlatego obok weryfikacji potrzebna jest walidacja.

Najlepiej widać to na liczbach biznesowych. W przypadku Argos najważniejszym wynikiem dla zarządu nie był spadek liczby błędów, tylko wzrost konwersji o 12 procent dzięki stabilności checkoutu i płatności. Testy przestały być działem zgłoszeń, a stały się argumentem o przychodzie. Walidację z użytkownikami wspierają testy użyteczności, które sprawdzają, czy ludzie potrafią z produktu skorzystać, a nie tylko czy przycisk działa.

Jak wprowadzić 7 zasad testowania w zespole w jeden sprint?

Zasady same niczego nie poprawią. Poprawiają nawyki, które z nich wynikają. Poniżej cztery zmiany, które wprowadzicie w jednym sprincie, bez nowego narzędzia i bez budżetu. Konkretne zadania dla testera poza testami funkcjonalnymi, od badania użyteczności po analizę błędów z produkcji, zebraliśmy w tekście rola testera w projekcie: 6 sposobów na wartość poza testami.

Jeśli wolicie zacząć od diagnozy, sprawdzamy dojrzałość procesu w ramach audytu QA, a liderzy, którzy chcą układać strategię testów wokół ryzyka, znajdą to w szkoleniach z zarządzania testami. Antywzorce, które najczęściej łamią te zasady w zespołach, zebrała też Strefa QA w tekście o antywzorcach w testowaniu.

Powiązane na blogu Quality Island

• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Ryzyko projektowe w testowaniu oprogramowania i zasada Pareto
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• Certyfikat ISTQB: poziomy, koszt egzaminu i czy warto
• Top kursy Udemy z testowania manualnego i jak wybrać kurs

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level, sylabus v4.0.1, 2024, podrozdział 1.3 Testing Principles. Stąd brzmienie siedmiu zasad i źródła literaturowe (Buxton 1970, Manna 1978, Boehm 1981, Enders 1975, Beizer 1990, Kaner 2011).
• Stowarzyszenie Jakości Systemów Informatycznych, Certyfikowany Tester Poziom Podstawowy, sylabus w. 4.0, wersja pl 4.0.0.1, 2025. Stąd polskie nazwy zasad.
• J. N. Buxton, B. Randell (red.), Software Engineering Techniques, raport z konferencji NATO, Rzym 1969, 1970. Stąd zdanie Dijkstry o obecności i braku błędów.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Stąd 59,5 mld dolarów rocznie, 22,2 mld możliwej redukcji i podział kosztu 60 do 40 między użytkowników i producentów.
• CISQ, The Cost of Poor Quality Software in the US: A 2022 Report, 2022. Stąd 2,41 biliona i 1,52 biliona dolarów.
• Quality Island, case studies Argos, Autono, PKO BP i ChaosGears, dane własne 2026, liczby potwierdzone przez klientów.