W poprzedniej lekcji ustaliliśmy, dlaczego testowanie jest konieczne – głównie dlatego, że ludzie popełniają błędy.

W tej lekcji przyjrzymy się bliżej terminologii związanej z tymi niedoskonałościami: błędom (pomyłkom), defektom (usterkom) i awariom.

Zrozumienie precyzyjnych definicji tych pojęć oraz ich wzajemnych powiązań jest absolutnie kluczowe dla każdego testera i stanowi fundament komunikacji w zespole projektowym.

Omówimy również typowe przyczyny powstawania defektów oraz koncepcję przyczyny źródłowej (root cause).

Rozróżnienie: Błąd (Pomyłka), Defekt (Usterka), Awaria

Jak już wspomnieliśmy, u podstaw problemów z jakością oprogramowania leży błąd (ang. *error* lub *mistake*).

Jest to działanie człowieka, które prowadzi do powstania nieprawidłowego rezultatu.

Błędy są nieuniknione i mogą wystąpić na każdym etapie tworzenia oprogramowania.

Programista może źle zinterpretować wymaganie, analityk może nieprecyzyjnie opisać funkcjonalność, projektant może wybrać nieoptymalny algorytm, tester może błędnie zaprojektować przypadek testowy, a administrator może źle skonfigurować środowisko.

Przyczyny błędów ludzkich są różnorodne: presja czasu, brak doświadczenia, niedostateczna wiedza, złożoność problemu, niejasna komunikacja, zmęczenie czy po prostu nieuwaga.

Kiedy błąd ludzki zostaje wprowadzony do produktu pracy – czy to do kodu źródłowego, specyfikacji wymagań, dokumentacji projektowej, danych testowych czy jakiegokolwiek innego artefaktu – powstaje defekt (ang. *defect*, *fault*, *bug*).

Defekt to niedoskonałość lub brak w komponencie lub systemie, który może spowodować, że komponent lub system nie wykona wymaganej funkcji.

Innymi słowy, jest to fizyczna manifestacja błędu w produkcie pracy.

Przykłady defektów to: nieprawidłowa instrukcja w kodzie, brakująca obsługa warunku brzegowego, błąd logiczny w algorytmie, nieścisłość w specyfikacji wymagań, błąd w projekcie interfejsu użytkownika, niepoprawny wpis w dokumentacji.

Defekty mogą pozostawać ukryte w systemie przez długi czas.

Dopiero gdy kod zawierający defekt zostanie wykonany w określonych warunkach, może (ale nie musi) dojść do awarii (ang. *failure*).

Awaria to zewnętrznie obserwowalne zdarzenie, w którym komponent lub system nie wykonuje wymaganej funkcji w ramach określonych limitów.

Jest to manifestacja defektu podczas działania programu.

Użytkownik lub tester obserwuje awarię jako nieoczekiwane lub niepoprawne zachowanie systemu, np. wyświetlenie błędnego wyniku, zawieszenie się aplikacji, nieoczekiwane zakończenie działania, komunikat o błędzie, problemy z wydajnością, naruszenie bezpieczeństwa.

To właśnie awarie są tym, co najczęściej zauważają użytkownicy końcowi i co skłania do zgłaszania problemów.

Podsumowując łańcuch przyczynowo-skutkowy: Błąd (pomyłka) ludzka prowadzi do powstania Defektu (usterki) w produkcie pracy, a wykonanie tego defektu może spowodować Awarię systemu.

Zrozumienie tej sekwencji jest kluczowe: testerzy dynamiczni obserwują awarie, aby wnioskować o istnieniu defektów, które z kolei wynikają z wcześniejszych błędów ludzkich.

Testerzy statyczni starają się wykrywać defekty bezpośrednio w produktach pracy, zanim doprowadzą one do awarii.

Gdzie Mogą Występować Defekty?

Defekty nie ograniczają się jedynie do kodu źródłowego. Mogą one występować w każdym produkcie pracy tworzonym w trakcie cyklu życia oprogramowania.

Mogą znajdować się w:

• Specyfikacjach wymagań: Niejasne, niekompletne, sprzeczne lub niepoprawne wymagania są częstym źródłem problemów.
• Historyjkach użytkownika: Podobnie jak wymagania, mogą być źle sformułowane lub niekompletne.
• Dokumentacji projektowej: Błędy w architekturze systemu, projektach modułów czy schematach baz danych.
• Kodzie źródłowym: Błędy logiczne, składniowe, obliczeniowe, problemy z obsługą pamięci, wycieki zasobów itp.
• Skryptach testowych: Błędy w logice testu, niepoprawne dane testowe, błędne oczekiwane rezultaty.
• Danych: Niepoprawne lub niekompletne dane wejściowe, błędy w danych konfiguracyjnych lub danych używanych przez system.
• Dokumentacji użytkownika: Niepoprawne instrukcje, brakujące informacje, niejasne opisy.
• Plikach pomocniczych: Np. pliki konfiguracyjne, pliki budowania (build files).

Defekty wprowadzone we wczesnych produktach pracy (np. w wymaganiach) często prowadzą do powstania kolejnych defektów w późniejszych produktach (np. w kodzie implementującym te wymagania).

Dlatego tak ważne jest wczesne wykrywanie defektów za pomocą testowania statycznego (przeglądów).

Przyczyny Źródłowe Defektów (Root Causes)

Samo znalezienie i naprawienie defektu to często za mało.

Aby skutecznie poprawiać jakość i zapobiegać powstawaniu podobnych problemów w przyszłości, ważne jest zrozumienie przyczyny źródłowej (ang. *root cause*) defektu.

Przyczyna źródłowa to fundamentalny powód wystąpienia problemu. Jest to sytuacja lub czynnik, który doprowadził do błędu ludzkiego, który z kolei spowodował defekt.

Identyfikacja przyczyn źródłowych odbywa się zazwyczaj poprzez analizę przyczyn źródłowych (ang. *Root Cause Analysis*, RCA).

Jest to proces badania defektu w celu znalezienia jego podstawowej przyczyny, a nie tylko objawów.

Techniki RCA, takie jak metoda "5 Why" (pięciu pytań "dlaczego?") czy diagram Ishikawy (diagram rybiej ości), pomagają dotrzeć do sedna problemu.

Przykładowo, awaria polegająca na błędnym obliczeniu podatku (awaria) może być spowodowana defektem w kodzie funkcji obliczającej podatek (defekt). Ten defekt mógł powstać, ponieważ programista popełnił błąd, źle implementując wzór (błąd ludzki). Analizując dalej, dlaczego programista popełnił błąd, możemy odkryć, że specyfikacja wymagań była niejasna (przyczyna źródłowa) lub że programista nie miał wystarczającego szkolenia z zakresu przepisów podatkowych (inna potencjalna przyczyna źródłowa).

Znalezienie przyczyny źródłowej pozwala na wdrożenie działań korygujących i zapobiegawczych, które eliminują problem u jego podstaw, np. poprawienie procesu tworzenia specyfikacji, zorganizowanie dodatkowych szkoleń dla zespołu. To prowadzi do trwałej poprawy jakości i zmniejszenia liczby podobnych defektów w przyszłości.

Podsumowanie

Zrozumienie różnic między błędem ludzkim, defektem w produkcie pracy a awarią systemu jest kluczowe dla efektywnej komunikacji i pracy testera.

Pamiętajmy o łańcuchu: błąd -> defekt -> awaria.

Defekty mogą występować w różnych produktach pracy, nie tylko w kodzie.

Ważne jest nie tylko wykrywanie i naprawianie defektów, ale także analiza ich przyczyn źródłowych, aby zapobiegać ich powstawaniu w przyszłości i ciągle doskonalić procesy tworzenia oprogramowania.