Co zawrzeć w zgłoszeniu błędu?



Jak napisać dobry raport o błędzie

Pisanie dobrego raportu o defektach lub błędach znacznie ułatwia identyfikację i szybkie rozwiązywanie problemów. W tym poście wymieniamy typowe elementy, które zwykle są zawarte w zgłoszeniu błędu.

W przypadkowej kolejności:

Identyfikator wady, ID

Identyfikator jest bardzo ważny, aby móc odnieść się do usterki w raportach. Jeśli do rejestrowania defektów używane jest narzędzie do raportowania defektów, identyfikator jest zwykle generowanym przez program unikalnym numerem, który jest zwiększany w każdym dzienniku defektów.


streszczenie

Podsumowanie jest ogólnym, wysokopoziomowym opisem wady i zaobserwowanej awarii. To krótkie podsumowanie powinno być podkreśleniem wady, ponieważ to właśnie programiści lub recenzenci widzą jako pierwsi w zgłoszeniu błędu.

Opis

Charakter wady musi być jasno określony. Jeśli programista przeglądający defekt nie może zrozumieć i nie może śledzić szczegółów defektu, najprawdopodobniej raport zostanie odesłany do testera z prośbą o więcej wyjaśnień i więcej szczegółów, co powoduje opóźnienia w naprawie problemu.


Opis powinien dokładnie wyjaśniać kroki, jakie należy podjąć w celu odtworzenia wady, wraz z oczekiwanymi rezultatami i wynikiem etapu testowego. Raport powinien zawierać informację, na jakim etapie awaria została zaobserwowana.



Surowość

Stopień wady pokazuje, jak poważna jest wada pod względem szkód dla innych systemów, firm, środowiska i życia ludzi, w zależności od charakteru systemu aplikacji. Dotkliwości są zwykle uszeregowane i podzielone na 4 lub 5 poziomów, w zależności od definicji organizacji.

  • S1 - krytyczny: Oznacza to, że wada jest blokadą pokazową z dużymi potencjalnymi uszkodzeniami i nie ma obejścia, aby uniknąć wady. Przykładem może być aplikacja w ogóle się nie uruchamia i powoduje zamknięcie systemu operacyjnego. Wymaga to natychmiastowej uwagi, działania i naprawy.
  • S2 - Poważne: Oznacza to, że brakuje niektórych głównych funkcji aplikacji lub nie działają one i nie ma obejścia. Na przykład aplikacja do przeglądania obrazów nie może odczytać niektórych popularnych formatów obrazów.
  • S3 - normalny: Oznacza to, że niektóre główne funkcje nie działają, ale istnieje obejście, które można zastosować jako rozwiązanie tymczasowe.
  • S4 - Kosmetyczne / Ulepszenie: Oznacza to, że awaria powoduje niedogodności i irytację. Przykładem może być komunikat wyskakujący co 15 minut lub zawsze trzeba dwukrotnie kliknąć przycisk GUI, aby wykonać czynność.
  • S5 - Sugestia: Zwykle nie jest to usterka i sugestia poprawy funkcjonalności. Może to być graficzny interfejs użytkownika lub preferencje wyświetlania.

Priorytet

Po określeniu wagi, następnym krokiem jest sprawdzenie, jak ustalić priorytety rozdzielczości. Priorytet określa, jak szybko należy naprawić usterkę. Priorytet zwykle dotyczy znaczenia biznesowego, takiego jak wpływ na projekt i prawdopodobny sukces produktu na rynku. Podobnie jak dotkliwość, priorytet jest również podzielony na 4 lub 5 poziomów.

  • P1 - Pilne: Oznacza niezwykle pilne i wymaga natychmiastowego rozwiązania
  • P2 - wysoka: Wymagana rozdzielczość dla następnej wersji zewnętrznej
  • P3 - średni: Rozwiązanie wymagane przy pierwszym wdrożeniu (zamiast wszystkich wdrożeń)
  • P4 - Niski: Rozdzielczość wymagana dla pierwszego wdrożenia lub kolejnych przyszłych wersji

Przeczytaj więcej na temat wagi i priorytetu


Należy zauważyć, że wada o dużej wadze również ma wysoki priorytet, tj. Poważna wada będzie wymagała wysokiego priorytetu, aby rozwiązać problem tak szybko, jak to możliwe. Nigdy nie może być defektu o dużej wadze i niskim priorytecie. Jednak wada może mieć niewielką wagę, ale ma wysoki priorytet.

Przykładem może być błędna pisownia nazwy firmy na ekranie powitalnym podczas uruchamiania aplikacji. Nie powoduje to poważnych szkód dla środowiska ani życia ludzi, ale może mieć potencjalne szkody dla reputacji firmy i może zaszkodzić zyskom biznesowym.

Data i godzina

Ważna jest również data i godzina wystąpienia lub zgłoszenia wady. Zwykle jest to przydatne, gdy chcesz wyszukać defekty, które zostały zidentyfikowane dla określonej wersji oprogramowania lub od momentu rozpoczęcia fazy testowania.

Wersja i kompilacja testowanego oprogramowania

To też jest bardzo ważne. W większości przypadków istnieje wiele wersji oprogramowania; każda wersja zawiera wiele poprawek i więcej funkcji oraz ulepszeń w stosunku do poprzednich wersji. Dlatego ważne jest, aby zanotować, w której wersji oprogramowania wystąpiła zgłaszana przez nas awaria. Zawsze możemy odwołać się do tej wersji oprogramowania, aby odtworzyć błąd.


Zgłoszone przez

Jest to również ważne, ponieważ jeśli zajdzie potrzeba zwrócenia się do osoby, która zgłosiła usterkę, musimy wiedzieć, z kim się skontaktować.

Powiązane wymaganie

Zasadniczo wszystkie funkcje aplikacji można przypisać do odpowiednich wymagań. W związku z tym, gdy zostanie zaobserwowana awaria, możemy zobaczyć, na jakie wymagania wpłynęła.

Może to pomóc w zmniejszeniu liczby zduplikowanych raportów o defektach, ponieważ jeśli możemy zidentyfikować wymaganie źródłowe, to jeśli inna usterka zostanie zarejestrowana z tym samym numerem wymagania, może nie być konieczne ponowne jej zgłaszanie, jeśli defekty mają podobny charakter.

Załączniki / dowody

Wszelkie dowody awarii powinny zostać zebrane i dostarczone wraz z raportem o wadzie. Jest to wizualne wyjaśnienie opisu wady i pomaga recenzentowi, twórcy w lepszym zrozumieniu wady.


Wniosek

W tym artykule dowiedzieliśmy się, jakie informacje powinniśmy zazwyczaj umieszczać w zgłoszeniu błędu. Stworzenie dobrego raportu o błędzie przyspiesza analizę pierwotnej przyczyny i naprawę błędu.