Nomenklatura raportu z testów, kiedy błędy są błędami, a kiedy to tylko uwagi.

Każdy programista współpracuje w taki czy inny sposób z testerami, bardzo dobrze gdy to jest rzeczywiście jest współpraca i zrozumienie, a nie przepychanki i walka. Nawet gdy współpraca jest dobra, produkty tej współpracy mogą być mylnie interpretowane. Gdy testy są wewnętrzną częścią zespołu projektowego i komunikacja nie wykracza poza ten zespół, to nomenklatura nie ma znaczenia. Natomiast kiedy wkraczamy w sferę kontaktów z działem QA u klienta, to co jest błędem i a co nim nie jest zaczyna nabierać znaczenia politycznego, wpływa na wizerunek zespołu i jakości pracy wykonywanych przez dostawcę.

Według słownika testerskiego przygotowanego przez członków SJSIbłąd” to odpowiednik angielskiego „bug„. W języku polskim słowo „błąd” może oznaczać wiele różnych rzeczy i które mogą wynikać z wielu różnych czynników, jednak w połączeniu z oprogramowaniem jest zawsze kojarzony z jednym, tak jak „bug” wskazuje, że oprogramowanie ma wadę za którą winę ponosi jego twórca. Niestety określenie błąd jest często nadużywane, często tam gdzie powinna pojawiać się np. pomyłka (ang. error) czy usterka (ang. fault).

Usterka, pomyłka, uwaga, poprawność

Określenie błąd prawie zawsze obarcza winą programistów, a ma potocznie dużo szersze w znaczenie, może oznaczać np. nieprawidłowe działanie oprogramowania wynikające z nieprawidłowej akcji użytkownika lub wykrycie przez oprogramowanie nieprawidłowego stanu (np. poprzez asercje). Dlatego lepszą nazwą dla wszelkiego rodzaju uchybień w oprogramowaniu jest „usterka” czy „wada„, ale też tylko w znaczeniu uszkodzenia lub gdy jest to niezgodność z wymaganiami, czyli gdy stopień „poprawności” jest niedopuszczalny.

Jako producenci oprogramowania sami jesteśmy sobie winni, gdy ktoś zarzuca naszym produktom dużą liczbę błędów. Na co dzień korzystamy z ubogiego słownika, podobnie opisując każdą błędną sytuację, wszytko nazywając potocznie „błędem”. Z lenistwa i przyzwyczajenia w ten sam sposób określamy wszystkie błędne sytuacje bez uwagi na ich tło, także w raportach z testów i innych formach komunikacji. W wyniku osoby postronne kojarzą wszystkie te „błędy” z „bugami” w oprogramowaniu, podczas gdy nie wszystkie z nich są faktycznie usterkami.

Czasem jest to wina przyjętych szablonów i procedur które nie przewidują że etapie testów można wprowadzać nowe wymagania lub uwagi do przyszłych wersji oprogramowania (np. poprzez brak odpowiednio szerokiego słownika statusów). Stosując właściwie dobrany słownik, dbamy o wizerunek zespołu projektowego, a nadużywając słowa „błąd” sugerujemy gorszą, w stosunku do stanu faktycznego, jakość produktów swojej pracy. Umiejętnie separując usterki od pomyłek, nowych wymagań i uwag, podnosimy jakość informacji jakie docierają do zainteresowanych i zapobiegamy mylnego postrzegania produktów naszej pracy jako wadliwych.

Słaba ocena jakości czasem wynika z błędnej interpretacji

An ‘error‚ is a deviation from accuracy or correctness. A ‘mistake’ is an error caused by a fault: the fault being misjudgment, carelessness, or forgetfulness.

Jak długo raporty z testów krążą wśród osób ze znajomością tematu, nomenklatura zazwyczaj nie sprawia problemów, bo zazwyczaj odbiorcy zdają sobie sprawę co leży u źródła tego czy innego „błędu”. Potrafią odseparować poważne uchybienia i wady od uwag, które niestety zostały wyartykułowane dopiero w przy okazji testów, czyli zbyt późno dla testowanej wersji oprogramowania.

Jednak gdy raporty z testów zaczynają trafiać do mniej świadomego kierownictwa czy przyszłych użytkowników oprogramowania, znaczenia nabiera właściwa konotacja przekazu, tacy odbiorcy nie będą świadomi, że być może to co widzą w raporcie to nie jest błędem/usterką, i nie należy winić za nią twórców. Czasem będzie to właściwość oprogramowania—często świadoma, być może niefortunna, taka którą w przyszłości można by usprawnić, choć nie wymaga ona naprawy.

„To nie błąd, to taki feature.”

Frustrujące jest gdy na testach QA u klienta, które powinny jedynie potwierdzić zgodność z wymaganiami i brak usterek, testerzy raportują swoje uwagi jako błędy oprogramowania. Szczególnie często zdarza się to w obszarze użyteczności oprogramowania, obszarze z reguły nie uwzględnianym w budżecie, wymaganiach i harmonogramie, obszarze o znikomym znaczeniu w porównaniu z krytycznymi funkcjami biznesowymi.

Sytuacja gdy zespół QA może wyrazić swoje uwagi i wymagania dopiero w formie raportu z testów jest frustrująca zarówno dla dostawcy jak i testerów. Niestety zwykle nikt za wczasu nie pyta testerów jakie są ich wymagania względem oprogramowania, a nawet jeśli ich wymagania nie są realizowane świadomie, to nikt ich o tym nie poinformuje przed testami. Z tego wynikają niepotrzebnie konflikty.

Zespół QA jednego z klientów mojej firmy, w raportach z testów uwzględnia zbyt lakoniczne komunikaty w aplikacjach np: „Nie można usunąć X”. Zgodzę się, że lepiej będzie jeśli użytkownik zostanie także poinformowany „dlaczego”. IMHO są to słuszne uwagi, ale nie są one usterkami. Ten konkretnie przypadek dotyczy sfery użyteczności oprogramowania, którą powinno się brać pod uwagę np. na przeglądach prototypów, wtedy kiedy można jeszcze wprowadzać zmiany. W trakcie końcowych testów QA pozostają tylko uwagami do przyszłych wersji.

Inne częste przypadki raportowania błędów które nie są błędami to pomyłki wynikające z niedostatecznych zabezpieczeń w oprogramowaniu. Chyba najczęstszym przypadkiem są komunikaty generowane przez bazę danych w przypadku próby naruszenia więzów integralności. Czasem zabezpieczania przed pomyłkami można wbudować stosunkowo niedrogim kosztem (czyt. za darmo dla klienta), jednak w dzisiejszych czasach, przy napiętych budżetach i harmonogramach trudno oczekiwać dostawca będzie dopieszczał obszary produktu które klient uznał (poprzez budżet, harmonogram i wymagania) za mało istotny.

Koncert życzeń

Klient często doznaje olśnienia dopiero na testach i zaczyna dostrzegać potrzeby wynikające z uwag działu QA. Ponieważ do innych wcześniej istotniejszych obszarów nie ma zastrzeżeń, nagle rośnie znaczenie obszarów wcześniej zmarginalizowanych, zaczyna się spóźniony koncert życzeń. IMHO gdy poziom poprawności oprogramowania jest zadowalający, klienta należy grzecznie poinformować:

Niestety, nie było takiego wymagania, oczywiście uwzględnimy zebrane uwagi przy wycenie następnej wersji oprogramowania, jednak w tej wersji wyczerpaliśmy już budżet na zmiany. Uwagi zebrane podczas testów nie mają wpływu na poprawne i zgodne z wymaganiami działanie oprogramowania. Jeśli te uwagi są istotne i niezbędne jest wprowadzenie zmian do bieżącej wersji oprogramowania, proszę o przesunięcie terminu wykonania prac i rozszerzenie budżetu.

Na koniec jeszcze mały wyciąg ze słownika testerskiego:

  • usterka – Skutek błędu twórcy programowania. Usterka może, ale nie musi powodować awarii.
  • fault – A manifestation of an error in software. A fault, if encountered may cause a failure.
  • bug – See fault.
  • błąd – Patrz: usterka.
  • pomyłka – Działanie człowieka powodujące powstanie nieprawidłowego wyniku.
  • error – A human action that produces an incorrect result
  • poprawność – Stopień zgodności programowania z wymaganiami zawartymi specyfikacji.
  • correctness – The degree to which software conforms to its specification.

Dodaj komentarz