Jak napisać raport o błędzie z przykładami

Co to jest raport o błędzie? Dlaczego potrzebujesz dobrego raportu o błędach?

Raport o błędach to ważny dokument w STLC, który oferuje zespołowi testującemu różne korzyści. Śledzi wszystkie defekty, liczne błędy, błędy i inne rozbieżności wykryte podczas testowania oprogramowania i raportuje je.

Celem tej dokumentacji potestowej jest dostarczenie zainteresowanemu zespołowi specjalistów informacji na temat poziomu błędów napotkanych podczas procesu testowania.

Twoje inżynier rozwoju oprogramowania Dzięki tego typu raportom można uzyskać informacje o wszystkich defektach i problemach występujących w oprogramowaniu. Pozwala także dowiedzieć się, co jest nie tak z błędem, dzięki czemu możesz zastosować najlepszą metodę jego naprawienia. Pomaga także zaoszczędzić czas i pieniądze, pomagając wychwytywać błędy i problemy.

Dlaczego warto dbać o dobre wyjaśnienia błędów?

Oto kwestia, którą należy wziąć pod uwagę, pisząc dobry, szczegółowy raport o błędach oprogramowania:

• Działa jako przewodnik pomagający uniknąć tego samego błędu w przyszłych wydaniach.
• Oszczędź czas na komunikację (e-maile, połączenia telefoniczne).
• Less pracuj dla programistów (zrobią dokładnie to, czego chcesz).
• Będziesz mieć mniej wąskich gardeł w projekcie; błędy będą naprawiane szybciej i skuteczniej.

Jak napisać raport o błędzie (szablon raportu o błędzie)

Nie ma dokładnego szablonu raportu o błędzie, ponieważ zależy to od systemu śledzenia błędów. Twój szablon może być inny.

Jednakże zawsze, gdy chcesz napisać raport o błędzie, potrzebne są następujące wspólne pola:

• Identyfikator błędu/tytuł.
• Ważność i priorytet.
• Opis
• Środowisko
• Kroki ku reprodukcji.
• Spodziewany wynik.
• Aktualny rezultat.
• Załączniki (zrzuty ekranu, filmy, tekst)

Przyjrzyjmy się po kolei wszystkim komponentom usuwającym błędy:

1) Tytuł/identyfikator błędu:

Każdy błąd powinien mieć unikalny numer identyfikacyjny. Narzędzia do zgłaszania błędów powinny mieć unikalne numery dla nowo zgłoszonych błędów, abyśmy mogli łatwo zidentyfikować błąd.

Przykłady:

❌ Źle: „Ponownie nie widzę produktu, piszę, że nie.”

• Niejasny
• Agresywny
• Zbyt rozwlekłe

zwraca się z prośbą o wdrożenie rozwiązania.

✅ Dobrze: „KOSZYK – Nowe pozycje dodane do koszyka, które się nie pojawiają”.

• Ten rodzaj tytułu natychmiast lokalizuje problem (KOSZYK)
• Koncentruje się na rzeczywistym problemie technicznym.

2) Waga błędu:

Ważność błędu jest bardzo ważnym czynnikiem w raporcie o błędzie. Opisuje wpływ defektu na działanie aplikacji.

• Blokery: Ten błąd powoduje awarię aplikacji.
• Kierunek: Błąd krytyczny wskazuje na poważną zmianę w logice biznesowej.
• Mniejszy: Problem, który nie wpływa na funkcjonalność aplikacji, ale wpływa na oczekiwane rezultaty.
• Trywialny: Nie wpływa to na funkcjonalność ani działanie aplikacji. Może to być błąd typograficzny.

3) Priorytet błędu:

Poniżej przedstawiono ogólną gradację służącą do określania priorytetu błędów:

• Wysoka: Obejmuje wszystko, co wpływa na przepływ lub blokuje korzystanie z aplikacji.
• Medium: Wpływa to niekorzystnie na doświadczenie użytkownika.
• Mniejszy: Wszystkie inne błędy, takie jak (literówki, brakujące ikony, problemy z układem itp.).

4) Środowisko:

Błąd może pojawić się w określonym środowisku, a nie w innym. Na przykład czasami pojawia się błąd podczas uruchamiania strony internetowej Firefoxlub nieprawidłowe działanie aplikacji tylko podczas pracy na komputerze Android urządzenie i działa dobrze na iPhonie.

Te raporty o błędach można zidentyfikować jedynie podczas testów w różnych przeglądarkach lub na różnych urządzeniach. Dlatego zgłaszając błąd, osoby odpowiedzialne za kontrolę jakości powinny być w stanie określić, czy błąd powinien zostać zaobserwowany w jednym, czy w większej liczbie określonych środowisk.

5) Podsumowanie:

Jednak dodanie samego tytułu do raportu o błędzie nie służy temu celowi. Jeśli więc tytuł nie wystarczy, możesz dodać krótkie podsumowanie raportu.

Twoje podsumowanie w jak najmniejszej liczbie słów, zawierające informację o tym, kiedy i jak wystąpił błąd. Twój tytuł i opis błędu powinny być również używane podczas wyszukiwania, dlatego musisz upewnić się, że uwzględniłeś ważne słowa kluczowe.

Przykłady:

• Źle: „Próbowałem dodać coś do testu, ale nic się nie pojawiło, gdy to zrobiłem lub kliknąłem przycisk”.
• Dobry: „Kiedy próbowałem dodać [PRODUKT] do koszyka, ale nic się nie stało, gdy kliknąłem przycisk „dodaj” na stronie przeglądu konkretnego produktu.”

6) Kroki do odtworzenia:

Zgłaszając błąd, ważne jest określenie kroków prowadzących do jego odtworzenia. Powinieneś także uwzględnić działania, które mogą powodować błąd. Nie formułuj tutaj żadnych ogólnych stwierdzeń.

Określ szczegółowo kroki, jakie należy wykonać:

Oto przykład dobrze napisanej procedury:

Kroki:

1. Wybierz produkt X1.
2. Kliknij Dodaj do koszyka.
3. Kliknij Usuń, aby usunąć produkt z koszyka.

7) Oczekiwany wynik:

W raportach błędów ważne jest opisanie oczekiwanego wyniku według zadania technicznego, projektu wyników przypadku testowego lub zgodnie z opinią testera. Wszystko to pomaga programistom skoncentrować się na szybkim znalezieniu potrzebnych informacji.

Na przykład:

Wymagane pola powinny zostać podświetlone na czerwono po kliknięciu przycisku „Prześlij”.

8) Rzeczywisty wynik:

Jak sama nazwa wskazuje, to pole opisuje rzeczywisty efekt błędu. Bardzo ważne jest, aby napisać jasny opis rzeczywistego wyniku.

Na przykład:

Pola wymagane są podświetlane na zielono po kliknięciu przycisku „Wyślij”.

9) Załączniki (zrzuty ekranu i filmy):

W przypadku raportów o błędach najlepszą praktyką jest załączanie plików do raportów o błędach, co ułatwia dostrzeżenie informacji, gdy trzeba je wyświetlić wizualnie:

Na przykład:

• Screenshot: Zrzuty ekranu pozwalają łatwo skorygować błędy w programie; jest to wygodne, gdy błąd jest wyróżniony określoną adnotacją, okręgiem lub obrazem strzałki).
• Wideo: Czasami trudno opisać błąd słowami, dlatego lepiej nagrać film, aby programista mógł naprawić usterkę w programie).

10) Wersja, której dotyczy problem:

Jest to wersja oprogramowania, której dotyczy problem, w której zgłaszany jest błąd.

11) Napraw wersję:

Jest to wersja oprogramowania, w której usunięto błąd. Kiedy więc osoba przeprowadzająca kontrolę jakości, która zgłosiła błąd, sprawdza, czy została naprawiona, używa właściwej wersji oprogramowania.

12) Target wersja:

Wersja docelowa, w której błąd powinien zostać naprawiony. Dlatego też, gdy zespół programistów pracuje nad naprawieniem błędu, jego celem jest głównie konkretna wersja aplikacji.

13) Data zamknięcia:

Jest to data zamknięcia błędu przez zespół testujący oprogramowanie. Zamykanie błędu jest istotną i integralną częścią testowania oprogramowania.

14) Stan:

Kiedy zostanie utworzony nowy błąd, jego status powinien być otwarty. Następnie przechodzi przez etapy takie jak W toku, Naprawiono, Działa, Ponownie otwiera itp.

Wskazówki dotyczące pisania raportów o błędach

Oto kilka ważnych wskazówek, o których warto pamiętać podczas pisania skutecznego raportu o błędzie:

• Bądź konkretny podczas tworzenia raportów o błędach. Upewnij się, że nie podajesz żadnych bezużytecznych lub nieistotnych faktów.
• Musisz zgłosić błąd natychmiast po jego wykryciu.
• Przygotuj szczegółowy raport, aby umożliwić programiście wykorzystanie faktów i informacji do debugowania problemu.
• Powinieneś przetestować to samo wystąpienie błędu w innych podobnych modułach w celu sprawdzenia poprawności.
• Revprzejrzyj raport o błędzie przynajmniej raz przed jego przesłaniem.
• Należy upewnić się, że raport o błędzie zawiera opis tylko jednego błędu.
• Wreszcie, nie powinieneś bać się poprosić Menedżera Projektu o pomoc, jeśli czujesz się niejasny w jakiejś kwestii.

Narzędzia do raportowania błędów

Proces raportowania błędów, wykonywany ręcznie, jest obecnie realizowany za pomocą różnych narzędzi do raportowania błędów dostępnych na rynku.

• JIRA
• Śledzenie błędów Zoho
• Bugzilla

Możesz sprawdzić naszą szczegółową recenzję najlepsze narzędzie do zgłaszania błędów.

Typowy problem i rozwiązanie podczas pisania raportu o błędzie:

Oto kilka typowych problemów i ich rozwiązań podczas pisania raportu o błędzie:

Przykład raportu o błędzie	Problem
Przy mnożeniu 2 przez 3 odpowiedź będzie dodatnia.	Zgłoś wzór, a nie przykład.
Aby tego uniknąć, podczas dodawania nowego elementu lista zostanie uporządkowana alfabetycznie.	Nie tylko opisz, co jest nie tak
Na przykład: Aby być, musisz otworzyć przeglądarkę i wpisać adres URL witryny. Znajdziesz pierwsze pole, „nazwa użytkownika”, z błędną pisownią.	Zawsze bezpośrednio do rzeczy (Nigdy nie opowiadaj historii!).
Imię i nazwisko klienta w raporcie zostało błędnie zapisane. Priorytet: wysoki, ważność: wysoki	Nigdy nie mieszaj priorytetu i wagi.
Wzór obliczenia podatku jest NIEPRAWIDŁOWY !!??	Nie używa wielkich liter, czerwonych liter, czerwonych kółek, „!”,
Nie sądzę, że projekt strony głównej Ul jest dobry.	Nie używaj swojego osądu.
Przykład niejasnego opisu: W związku z naszą dzisiejszą dyskusją, wykonaj wymagane działania dla tej strony.	Spraw, aby Twój opis był zrozumiały dla każdego.
Tło strony powinno być niebieskie, pomarańczowe lub zielone. Możesz też ustawić je w kolorze czarnym lub białym. Nie jest to dobre rozwiązanie, ponieważ nie jest jasne, czego potrzebuje zespół zajmujący się tworzeniem i projektowaniem stron internetowych	Zminimalizuj opcje
Formuła obliczania podatku czasami nie działa zgodnie z oczekiwaniami.	Złota zasada: nie używaj słowa „czasami”.

Przykład raportu o błędzie

Oto mały przykład raportu o błędzie:

[MOJE KONTO] Podkreślenie jest wyświetlane po najechaniu myszką na przycisk Aktualizuj.

Descriptjon: Musimy usunąć podkreślenie po najechaniu myszką na przycisk Aktualizuj w sekcji Moje konto.

Połączyć: http://test.com/mv-account/

Przeglądarka/system operacyjny: Chrome 25. OSX Yosemite 10.10.2

Kroki ku reprodukcji:

1. Przejdź do www.test.com

2. Zaloguj się za pomocą danych logowania

3. Przejdź do Mojego konta

4. Najedź myszką na przycisk Aktualizuj

Aktualny rezultat: jest podkreślenie.

Spodziewany wynik: bez podkreślenia.

Dane logowania: test@test.com / mysecretpass12

Należy unikać błędów w pisaniu raportów o błędach

Oto kilka ważnych błędów, których należy unikać podczas pisania raportu o błędzie:

• Nie pisz o swoim niezadowoleniu i nigdy nie opowiadaj o swoich osobistych odczuciach.
• Irytuje to osoby, które chcą się skupić na zadaniu, gdy przeładowujesz swój post wieloma emotikonami.
• Nigdy nie przeciążaj swojego postu wykrzyknikami; nie przyspiesza to pracy.
• Nikt nie chce czuć się urażony. Niszczy motywację i spowalnia realizację problemu.