Błąd, defekt czy awaria?

Cześć Słońce!

W tym poście chcę poruszyć temat, który nie jednemu spędza sen z powiek. Dzieje się tak, gdyż pojęcia te są często mylnie używane zamiennie. A to błąd!

Co jest czym? A może jednak te słowa określają to samo?

Zacznijmy od definicji ISTQB

Dlaczego te definicje? Ponieważ są najczęściej używane na rozmowach rekrutacyjnych, więc…

awaria – zdarzenie, w którym moduł lub system nie wykonuje wymaganej funkcji w określonym zakresie;

defekt (pluskwa, usterka) – niedoskonałość lub wada produktu, polegająca na niespełnieniu wymagań;

pomyłka (błąd) – działanie człowieka powodujące powstanie nieprawidłowego rezultatu.

Odczarujmy to!

Pomyłka/błąd to z reguły złe zaimplementowanie funkcjonalności przez programistę, np. pominięcie jednej walidacji podczas tworzenia formularza kontaktowego. Uruchomienie tego fragmentu może spowodować powstanie defektu/pluskwy/usterki czyli przytoczony formularz kontaktowy może nie spełniać wyznaczonych wymagań dotyczących działania.

Uruchomienie kodu z błędem NIE MUSI spowodować awarii. 😉

Ale może, awarię mamy jeśli skompilowany kod nie wykonuje wymaganej funkcji, czyli w naszym przypadku – nie sprawdza poprawności wszystkich pól formularza.

Skąd się pojawiają błędy?

Przyczyn może być wiele. Najczęściej występujące to presja czasu i bycie człowiekiem :). Chodzi tu głównie o omylność naszych ludzkich istnień. W wielu przypadkach może ona iść w parze z niewielkim doświadczeniem, bądź umiejętnościami w zakresie używanych technologii. Wiele niejasności wynika również ze zbyt skomplikowanych wymagań, lub niejasnej dokumentacji projektowej. Wiadomo.. im bardziej złożony system z innych systemów, tym łatwiej o niewielki błąd skutkujący sporymi konsekwencjami.

Warto również dodać, że awarie mogą powstać poprzez czynniki środowiskowe, które mogą powodować awarię w oprogramowaniu wbudowanym lub zmieniać działanie sprzętu.

Z perspektywy testera pragnę dodać, że nie wszystkie nieoczekiwane wyniki testów oznaczają awarię. Co to znaczy? Wykonywanie testów też może nieść błędy. Wyniki fałszywie pozytywne lub fałszywie negatywne są często raportowane jako defekty, a mogą one być zafałszowane poprzez nieaktualne dane testowe, nieprzebudowane środowisko testowe lub zaniedbaniu innych testaliów.

Wynik fałszywie pozytywny – Test, w którym zaraportowano defekt, który nie występuje.

Wynik fałszywie negatywny – Test, w którym nie zidentyfikowano obecności usterki występującej w testowanym obiekcie.

Słownik ISTQB

Dlatego ważne jest by przez zgłoszeniem defektu prześledzić ponownie, jak on powstał i sprawdzić go na innych przykładach. Należy się upewnić, że błąd faktycznie występuje i jest reprodukowalny. Oczywiście można spotkać awarie, które pojawiły się tylko raz i jedynym śladem jaki tester ma, są logi. Wtedy najlepiej zgłosić defekt w celu zbadania go przez programistę (można też samemu, ale to już zależy od dostępów, które posiada tester na projekcie).

Reasumując..

Przenosząc przykład z formularzem kontaktowym na przebieg powstawania produktu, to błąd pojawia się podczas tworzenia programowania. Defekt można znaleźć podczas testowania produktu oprogramowania (czyli jest to odstępstwo od wymaganego działania, niepoprawne działanie względem oczekiwanego). Zaś awarię może dostrzec użytkownik podczas korzystania z udostępnionego mu programu, gdy np. każdy wpisany adres email jest oznaczony jako błędny i nie można przesłać formularza dalej.