Tomasz Mielnik
Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.
Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.
W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.
Po znalezieniu defektu:
- Zapisz tę informację od razu, jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.
- Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.
- Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.
- Nie wyolbrzymiaj znaczenia błędu w opisie.
- Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.
Powyższy artykuł jest przedrukiem z wygasłego bloga testerskiego testowanie.net.
