Błąd, defekt, awaria i siedem zasad testowania

Po tej lekcji odróżnisz pomyłkę, defekt i awarię, wyjaśnisz, czym testowanie różni się od debugowania, i zastosujesz siedem zasad testowania do decyzji, co sprawdzić najpierw.

Czym jest testowanie, a czym nie jest

Testowanie to zestaw czynności, które mają znaleźć defekty i ocenić jakość produktu, zanim zrobi to klient. Według sylabusa ISTQB na poziomie podstawowym (CTFL v4.0.1) testowanie obejmuje nie tylko uruchamianie programu (testowanie dynamiczne), ale też przegląd wymagań, projektu i kodu bez uruchamiania (testowanie statyczne). Wiele defektów da się złapać, zanim powstanie choćby linijka kodu, czytając uważnie specyfikację.

Testowanie to też nie to samo co debugowanie. Tester pokazuje, że coś działa źle, i opisuje to tak, żeby dało się to powtórzyć. Programista w trakcie debugowania szuka przyczyny, poprawia kod i sprawdza poprawkę. Potem tester wykonuje test potwierdzający (czy poprawka działa) i test regresji (czy poprawka nie zepsuła czegoś innego).

Przez cały kurs pracujesz na jednym przykładzie: Rowerownia, fikcyjna wypożyczalnia rowerów miejskich i elektrycznych z Poznania. Klient sprawdza cenę w aplikacji, rezerwuje rower, płaci i odbiera go przy Starym Rynku. Specyfikację z regułami cenowymi znajdziesz w materiałach do modułu 1, a w kolejnych modułach uruchomisz jej lokalne API.

Pomyłka, defekt, awaria

Te trzy słowa brzmią podobnie, ale w zgłoszeniu i na egzaminie ISTQB znaczą co innego:

• Pomyłka (error, mistake): działanie człowieka, które daje zły wynik. Analityczka wpisuje do specyfikacji limit dzienny 60 zł dla obu typów roweru, choć dla elektrycznego miało być 110 zł.
• Defekt (defect, bug, fault): wada w produkcie pracy, czyli w kodzie, ale też w wymaganiu czy w projekcie. Kod Rowerowni obcina cenę roweru elektrycznego do 60 zł.
• Awaria (failure): zdarzenie, w którym system nie robi tego, co powinien. Klient płaci 60 zł za 8 godzin roweru elektrycznego zamiast 110 zł, a firma traci pieniądze na każdej takiej rezerwacji.

Defekt nie zawsze wywołuje awarię. Jeśli nikt nie wypożycza roweru elektrycznego na dłużej niż 7 godzin, błędny limit przez długi czas „śpi”. Awarię może też wywołać coś, co nie jest defektem kodu, na przykład zła konfiguracja serwera albo warunki środowiska.

Pojęcia według sylabusa ISTQB CTFL v4.0.1 i słownika ISTQB (stan na październik 2026).

Ostatni krok, przyczyna źródłowa, jest najcenniejszy. Poprawienie jednej liczby w kodzie usuwa defekt. Wprowadzenie przeglądu specyfikacji przez testera usuwa całą klasę podobnych defektów w przyszłości.

Siedem zasad testowania

Sylabus ISTQB opisuje siedem zasad, które od lat porządkują myślenie o testach. Poniżej z przykładem z Rowerowni:

1. Testowanie pokazuje obecność defektów, nie ich brak. Sto zaliczonych testów nie dowodzi, że błędów nie ma. Dowodzi, że nie znalazłeś ich tymi testami.
2. Testowanie gruntowne jest niemożliwe. Sama wycena ma 24 długości wypożyczenia, 2 typy roweru i 4 kombinacje rabatów, czyli 192 kombinacje. Doliczając wiek, zgodę opiekuna, NIP i godzinę startu, liczba rośnie tak szybko, że trzeba wybierać. Uczą tego techniki z modułu 2.
3. Wczesne testowanie oszczędza czas i pieniądze. Błąd w specyfikacji poprawiony na przeglądzie kosztuje edycję dokumentu. Ten sam błąd po wydaniu to poprawka kodu, nowe wydanie i reklamacje.
4. Defekty się kumulują. Zwykle kilka modułów zawiera większość problemów. W Rowerowni będą to najpewniej rabaty i anulowanie, bo mają najwięcej warunków.
5. Testy się zużywają. Ten sam zestaw testów powtarzany bez zmian przestaje znajdować nowe defekty. Trzeba go przeglądać i uzupełniać.
6. Testowanie zależy od kontekstu. Aplikacja bankowa, gra mobilna i formularz zapisu na zajęcia wymagają innego podejścia i innej głębokości.
7. Brak defektów to złudzenie sukcesu. Aplikacja bez znanych błędów, która nie odpowiada na potrzeby klienta, nadal jest porażką. Dlatego obok weryfikacji (czy zgodnie ze specyfikacją) potrzebna jest walidacja (czy to rozwiązuje problem użytkownika).

Jakość to więcej niż „działa”

Pytanie „czy działa?” dotyczy funkcjonalności. Norma ISO/IEC 25010:2023 opisuje jakość produktu szerzej, w dziewięciu cechach: obok przydatności funkcjonalnej wymienia między innymi wydajność, kompatybilność, bezpieczeństwo, niezawodność i łatwość utrzymania. W tym kursie dotkniesz większości z nich: funkcjonalności w modułach 2 i 3, API w module 4, automatyzacji w module 5, wydajności, dostępności i bezpieczeństwa w module 6.

Najważniejsze w 3 punktach

1. Pomyłka człowieka prowadzi do defektu w produkcie, a defekt może (nie musi) wywołać awarię widoczną dla użytkownika.
2. Testowanie obejmuje przeglądy bez uruchamiania programu, a im wcześniej znajdziesz defekt, tym taniej go usunąć.
3. Siedem zasad ISTQB przypomina, że testy pokazują obecność defektów, nie gwarantują ich braku, i trzeba je dobierać do kontekstu.

Źródła

• ISTQB, Certified Tester Foundation Level, sylabus v4.0.1: https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/ (dostęp: październik 2026)
• Słownik terminów ISTQB: https://glossary.istqb.org (hasła: error, defect, failure, root cause)
• ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE), Product quality model: https://www.iso.org/standard/78176.html