Definicje błędu

Błąd, pojęcie z którym tester spotyka się codziennie, jest bardzo ciekawym terminem posiadającym definicję teoretyczną – sprecyzowaną przez ISTQB oraz potoczną, którą posługujemy się na co dzień. Analizując obie interpretacje zauważamy pewne różnice, które przedstawię w poniższym artykule.

W celu wyjaśnienia różnych aspektów definicji załóżmy, że naszym zadaniem jest przetestowanie formularza bankowej aplikacji, której zadaniem jest wysłanie przelewu.

Błąd – interpretacja potoczna

Błąd, w interpretacji potocznej, może wystąpić w trzech przypadkach:

• gdy system nie robi czegoś co zostało wymienione w specyfikacji,
• gdy system wykonuje czynność, która nie została opisana w specyfikacji,
• gdy system robi coś, czego według specyfikacji nie powinien robić.

Przypadek pierwszy

W specyfikacji oprogramowania zostało sprecyzowane, że w formularzu powinno pojawić się pole Odbiorca, gdzie możemy wprowadzić nazwę odbiorcy przelewu. Jednak testując nasz system widzimy, że takiego pola nie ma. Mamy tu do czynienia z błędem, który polega na tym, że oprogramowanie wysyła przelew, w którym brakuje informacji o odbiorcy. W specyfikacji natomiast wspomniane jest, że przelew powinien posiadać tę informację.

Przypadek drugi

W specyfikacji oprogramowania możemy przeczytać, że formularz powinien składać się z następujących pól:

1. Pole typu drop-down list o nazwie Z rachunku,
2. W sekcji ODBIORCY, pola: ODBIORCA, NA RACHUNEK, ADRES,
3. W sekcji DANE PRZELEWU, pola: KWOTA, TYTUŁ.

Jednak w trakcie testów zauważamy dodatkowe pole, które nie jest wymienione w specyfikacji (pole Data wykonania)

W tym przypadku mamy do czynienia z błędem, gdy oprogramowanie robi coś czego wg specyfikacji nie powinno robić. W naszym przypadku wysyła przelew z dodatkową informacją, którą możemy wprowadzić w pole Data wykonania.

Przypadek trzeci

Testując formularz bankowej aplikacji tym razem zauważyliśmy, że w Polu Na rachunek możemy wpisywać znaki alfanumeryczne, nie tylko cyfry. W naszej sytuacji w specyfikacji sprecyzowane jest, że można w tym polu wpisywać tylko cyfry. W tym przypadku mamy sytuację, gdy system robi coś, co w specyfikacji  sprecyzowane jest, ze nie powinien robić. 

Interpretacja ISTQB

W sylabusie ISTQB rozróżniamy trzy pojęcia: błąd, usterkę i awarię. Z mojego doświadczenia terminologia ISTQB w tym przypadku nie przyjęła się w projektach i najczęściej używana jest przy teoretycznych dyskusjach. W interpretacji ISTQB za błąd odpowiedzialny jest człowiek, defekt jest wynikiem tego błędu, a ostatnim etapem jest awaria.

Błąd (interpretacja IStQB)

Błąd powstaje na skutek działania człowieka i powoduje powstanie nieprawidłowego rezultatu. Analizując tą definicję, widzimy, że w świetle ISTQB potoczna definicja błędu (która jest również najczęściej spotykana w codziennej pracy) jest nieprawidłowa. Bardzo popularne stwierdzenie “błąd oprogramowania”, jest nieprawidłowe, gdyż oprogramowanie nie może popełniać błędów. Błędy (pomyłki) może popełniać natomiast człowiek. 

Usterka (interpretacja ISTqB)

Usterka, nazywana również defektem, jest wynikiem błędu, który został popełniony przez człowieka. 

Awaria ( interpretacja ISTQB)

Ostatnim elementem łańcucha wydarzeń przedstawionym na wykresie jest Awaria. Pojawia się ona wtedy, gdy uruchamiamy oprogramowanie, które zawierało defekty lub gdy zaszły szkodliwe czynniki zewnętrzne (np. promieniowanie, pole magnetyczne lub elektryczne itd.).

Czym jest debugowanie?

W trakcie pracy możemy się również spotkać z pojęciem debugowanie, które również związane jest z szeroko pojętym terminem błędu. Debugowanie to programistyczna czynność , która może umożliwić zlokalizowanie problemu odpowiedzialnego za defekt. Do przeprowadzenia debugowania używamy debugera. Pozwala on sprawdzić krok po kroku co dzieje się w kodzie, co pomaga programiście znaleźć usterkę.