Jak napisać raport o błędzie z przykładami
Lucasa Bennetta
⚡ Inteligentne podsumowanie
Pisanie raportów o błędach to podstawowa umiejętność testera, która pozwala na jasne dokumentowanie usterek, przyspiesza proces ich usuwania i poprawia jakość oprogramowania, zapewniając programistom powtarzalne kroki, informacje o stopniu ważności, priorytetach, szczegółach środowiska i załącznikach pomocniczych przez cały cykl życia testów oprogramowania.
Co to jest raport o błędzie? Dlaczego potrzebujesz dobrego raportu o błędach?
Raport o błędzie to ważny dokument w STLC, który oferuje zespołowi testującemu szereg korzyści. track wszystkich defektów, błędów, pomyłek i innych niezgodności wykrytych 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 temu raportowi możesz dowiedzieć się o wszystkich defektach i problemach występujących w oprogramowaniu. Pozwala on również ustalić przyczynę błędu i zastosować najlepszą metodę jego rozwiązania. Pomaga również zaoszczędzić czas i pieniądze.ping wyłapujesz 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.
- Nowoczesne zespoły korzystające z Jira, Linear lub Azure DevOps może również łączyć raporty o błędach ze zgłoszeniami sprintu i procesami wydawniczymi, zapewniając tracmożliwość realizacji przepływów pracy w działach QA i DevOps.
Jak napisać raport o błędzie (szablon raportu o błędzie)
Nie ma konkretnego szablonu zgłaszania błędów, ponieważ zależy to od Twojego błędu.tracsystem królewski. 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ę wszystkim tym błędom-trackrólewskie komponenty jeden po drugim:
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 w zgłoszeniu błędu nie spełnia swojego celu. Jeśli więc sam tytuł nie wystarczy, możesz dodać krótkie podsumowanie zgłoszenia.
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 sklepuping „dodałem produkt do koszyka, ale nic się nie działo, gdy kliknąłem przycisk „Dodaj” na stronie z przeglądem konkretnego produktu.”
6) Kroki do odtworzenia:
Zgłaszając błąd, ważne jest, aby określić kroki niezbędne do jego odtworzenia. Należy również uwzględnić działania, które mogą spowodować błąd. Nie należy tutaj stosować żadnych ogólnych stwierdzeń.
Określ szczegółowo kroki, jakie należy wykonać:
Oto przykład dobrze napisanej procedury:
Kroki:
- Wybierz produkt X1.
- Kliknij Dodaj do koszyka.
- 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 jest opisać błąd słowami, dlatego lepiej nagrać film, tak aby programista mógł usunąć wadę 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ź precyzyjny, tworząc zgłoszenia błędów. Upewnij się, że nie zawierasz żadnych bezużytecznych ani 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.
- Skorzystaj z funkcji triażu wspomaganych przez sztuczną inteligencję w Jira lub Linear, aby automatycznie klasyfikować poziom ważności, sugerować duplikaty i kierować raport do właściwego właściciela komponentu.
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
- Liniowy
- Azure DevOps
- Błąd Zoho Tracker
- 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 opisuj tylko tego, co jest nie tak |
| Na przykład: Aby to zrobić, musisz otworzyć przeglądarkę i wpisać adres witryny URL. Pierwsze pole „nazwa użytkownika” będzie zawierało błąd. |
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 uważam, że projekt strony głównej UL jest dobry. | Nie kieruj się własnym osądem. |
| 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 omawiaj swoich osobistych odczuć.
- 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.
