Redakcja
Warto rozważyć następujące kwestie:
1) Czy to w ogóle jest defekt oprogramowania? A może jest to zdarzanie, które nie wynika z pomyłki programistycznej? Może to nasza pomyłka, albo pomyłka w teście, może to problem sprzętu? Warto sprawdzić przed raportem potencjalne źródło, by nie raportować zdarzeń, które zaangażują ludzi do analizy, która może zakończyć się wnioskiem: "błąd testera".
2) Czy to jest ważny defekt? Naszym celem jest raportowanie defektów, które zostaną naprawione. Skoro więc mamy poczucie lub wiedzę, że zostaną zamknięte bez naprawy (przez swoją trywialność lub niejednoznaczność wymagań) nie warto tracić czas na wypełnianie zgłoszenia. Teoretycy mówią "raportuj wszystko, może kiedyś ktoś naprawi". Jednak testowanie jest nieskończone. Po co marnować cenny czas na rzeczy błahe? W wielu narzędziach do raportowania defektów używa się statusu zgłoszenia "[naprawić] przy okazji". Proponujemy mało ważnym defektom nadać domyślny status "[zaraportować] przy okazji", kiedy już nie będzie ważniejszych zadań.
3) Czy ktoś już tego defektu nie znalazł wcześniej? Funkcją większości narzędzi do zarządzania defektami jest rozbudowane wyszukiwanie kontekstowe. Jego użycie pomaga wyeliminować zgłaszania tego samego błędu przez różnych testerów. Należy unikać marnowania czasu innych osób.
4) Czy można defekt zreprodukować? Na niewiele zda się raport, jeśli opisanego defektu nikt nie będzie w stanie powtórzyć. Zawsze warto mieć dowód, że defekt wystąpił (log, zrzut ekranu itd.). Zawsze warto sprawdzić, czy i jak często defekt można odtworzyć.
Jeśli już zebraliśmy ważne informacje, możemy przystąpić do raportowania: kroki odtworzenia, wersje, określenie krytyczności.
Znalazłem defekt i co dalej?
31 stycznia 2013
Dołącz do dyskusji
Kiedy w procesie testowania oprogramowania znajdziemy potencjalny defekt, zanim rozpoczniemy tworzenie raportu, czeka nas jeszcze kilka rzeczy do zrobienia.
