Podziel się tym wpisem!

jak poprawnie zgłosić błąd
Błąd, bug, issue, defekt, usterka to to czego szukamy w aplikacjach w czasie testów.

Integralną częścią naszej pracy jest zgłaszanie błędów znalezionych w aplikacji. Ważne zatem byśmy wiedzieli jak to zrobić by nasza i całego zespołu praca stała się bardziej efektywna. Dobrze opisane zgłoszenie to też mniej problemów we współpracy testera z programistą. W tym artykule opowiem, jakie są kolejne pola w formularzu zgłaszania defektu. Na koniec umieściłem przykład zgłoszenia defektu dla hipotetycznego błędu logowania do aplikacji oraz edytowalny forlumarz zgłoszenia błędu w formacie pdf. Wychodzę z założenia, że jeśli chcesz się dowiedzieć jak poprawnie zgłosić błąd, to sama teoria nie wystarczy. Musisz poćwiczyć, a ten formularz mam nadzieję Ci w tym pomoże.

Czym jest błąd?

Jest to zdarzenie w systemie niezgodne z dokumentacją biznesową lub analityczną.

Przykładowo
W dokumentacji czytamy: A + B = 2.
W aplikacji widzimy: A + B = 3.

Jak widać, na powyższym przykładzie aplikacja nie jest spójna z dokumentacją. A to znaczy, że należy zgłosić defekt.

Elementy zgłoszenia defektu

Kategoria / Tagowanie

Kategoria dotyczy rodzaju zgłoszenia. Projekt nie tylko ma błędy, ale też np. pytania do analityka (questions), główne zadania tak zwane (story), pod zadania (subtask).

Powtarzalność

W tej formatce określamy na ile prób, błąd udaje się powtórzyć. Dzięki tej informacji programista wie, że powinien kilka razy podjąć próbę odtworzenia defektu, zanim przyjdzie do nas z pytaniami o to, jak to zrobić. Jest to również ważna informacja dla testerów podczas retestów błędów. 

Priorytet

Przeważnie mamy do dyspozycji sześć stopni ważności zgłoszenia. Wymieniając od najmniej ważnego będą to: Trywialny, Mniejszy, Normalny, Wysoki, Krytyczny oraz Blokujący. Szczegółowo na temat wartości pól Priorytet i Ważność napisałem w jednym z moich artykułów. Wartość w polu Priorytet ustalamy, odpowiadając sobie na następujące pytania.

  • Czy istnieje obejście problemu dzięki, któremu użytkownik może używać aplikacji?
  • Czy problem jest globalny i dotyczy całej aplikacji, czy też lokalny i dotyczy funkcjonalności w aplikacji?
  • Czy problem dotyczy nowej funkcjonalności, którą chcemy dodać do wersji produkcyjnej?
  • Czy trudno jest go powtórzyć i jak wielka jest szansa na to, że “normalny” użytkownik na niego trafi?
Temat / tytuł błędu

Krótki opis mówiący co nie działa w aplikacji. Tytuł powinien w sposób jasny i czytelny mówić co nie działa w aplikacji. 

Tytuł błędu podobnie jak pozostałe pola nie powinien posiadać literówek ani błędów ortograficznych. Literówki i błędy ortograficzne sprawią, że nie będzie możliwe wyszukanie błędu po słowie kluczowym na liście błędów zgłoszonych do systemu. Jest to szczególnie ważne, gdy system testowany jest duży, ilość błędów zarejestrowanych w bug tracker jest również duża oraz gdy aplikację testuje więcej niż jeden tester.

Opis

W tym polu wpisujemy dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć, np. jeśli błąd wystąpi tylko wtedy gdy użytkownik wyczyści cash przeglądarki.

Kroki testowe

Moim zdaniem najważniejsza część zgłoszenia błędu. W tym polu opisujemy krok po kroku, tak jakbyśmy tłumaczyli komuś, kto nigdy aplikacji na oczy nie widział, co trzeba zrobić, by błąd odtworzyć. Zasady, których warto się trzymać:

  • Każdy krok opisu umieść w nowej linijce.
  • Numeruj kolejne kroki.
  • Stosuj krótkie proste zdania (niezłożone).
  • Pisz w formie drugiej osoby.
  • Nazwy pól i przycisków umieść tak jak widnieją w aplikacji (nie odmieniaj) dodatkowo warto je umieścić w cudzysłów.

Najczęstszymi błędami testerów podczas opisania kroków testowych jest niedbałość o szczegóły. Mylne założenie, że przecież wiadomo co trzeba zrobić, by powtórzyć błąd. Podanie w krokach testowych linku do aplikacji i zrzutu ekranu nie sprawia, że każdy będzie w stanie odtworzyć kroki testowe.

Testerze zapamiętaj, programista bardzo często nie zna całej aplikacji. Im dokładniejszy opis błędu, tym mniejsze prawdopodobieństwo na stratę czasu przy próbie jego reprodukcji.

Przypisanie

Zazwyczaj jest to rozwijalna lista, na której wybieramy imię i nazwisko programisty, który powinien zająć się danym zgłoszeniem. Przeważnie nad aplikacją pracuje więcej niż jedna osoba, a sama aplikacja jest całkiem spora. Powoduje to konieczność rozłożenia tejże aplikacji na obszary, za które są odpowiedzialne konkretne osoby. Jeśli zgłaszamy błąd, to staramy się go przypisać do osoby, która odpowiada za dany obszar.

Środowisko

Dla aplikacji WEB podajemy w tym polu nazwę przeglądarki, jej wersję oraz wersję aplikacji.
Jeśli defekt wystąpił w aplikacji mobilnej, to podajemy wersję aplikacji oraz wersję systemu Android/IOS a czasami też model telefonu.
W przypadku aplikacji na komputery podajemy system operacyjny oraz wersję aplikacji, na której znajduje się błąd.

Załączniki

Wszystkie dodatkowe informacje pomagające programiście namierzenie błędu, w szczególności są to: logi skopiowane z przeglądarki, zrzut ekranu (format .png), filmik (.mp4). 

Pamiętaj, że załącznik (zrzut, filmik) powinien pokazywać możliwie jak najwięcej by pomóc odnaleźć błąd. Dobrą praktyką jest zaznaczyć na zrzucie ekranu gdzie jest błąd (najprościej użyć w tym celu Paint i ramką czerwoną otoczyć właściwe miejsce na obrazku).

Jak poprawnie zgłosić błąd? Zgłaszanie błędu na przykładzie programu Mantis

Na prowadzonych przeze mnie szkoleniach testowania oprogramowania wiele uwagi poświęcam na ćwiczenia praktyczne. Mantis jest jednym z programów, na którym odbywają się takie właśnie ćwiczenia. Program jest na licencji GNU, co oznacza, że bez opłat możecie go pobrać i ćwiczyć na nim zgłaszanie błędów. 

Wracając do przykładu

Załóżmy, że masz do przetestowania ekran logowania do aplikacji. Po wpisaniu poprawnego loginu i hasła, kliknięciu zaloguj, otrzymałeś komunikat o błędzie jak na poniższym obrazku.

przykładowy komunikat o błędzie
Przykład - Komunikat o błędzie

Dla upewnienia sprawdzasz jeszcze dwa razy – błąd występuje za każdym razem. Przechodzisz zatem do jego opisu.

Mantis przykład zgłoszenia błędu
Mantis, zgłoszenie błędu, pola "Temat", "Opis" oraz "Kroki, by powtórzyć"

Pobierz edytowalny formularz zgłoszenia błędu w formacie .pdf

W artykule, który właśnie przeczytałeś opisałem dokładnie jak zgłosić błąd. Czas zatem by przejść od teorii do praktyki. Jeśli nie masz dostępu do oprogramowania takiego jak Mantis czy Jira, możesz skorzystać z mojego pliku. 

Po pobraniu pliku, możesz go wydrukować i uzupełniać w celu nauki. Plik jest edytowalny możesz zatem  wypełnić go na komputerze, kliknąć “zapisz jako” i zapisać sobie na dysku. Powodzenia!

Czy każdy znaleziony błąd powinien być zgłoszony?

Uważam, że nie. Przykładowo, załóżmy, że po wgraniu aplikacji na środowisko testowe i uruchomieniu jej od razu mamy błąd i nie możemy pracować. Myślę, że w tej sytuacji efektywniej będzie pójść do odpowiedniego programisty i poprosić go o rzucenie okiem na środowisko i jego naprawę. Ważne, aby pamiętać, że wszyscy mamy wspólny cel, czyli dobry produkt oddany do klienta w skończonym czasie. Nie ma więc sensu tracić siły czas i energię na zgłaszanie takiego błędu.

Co się dzieje z błędem po jego zgłoszeniu?

Po zapisaniu błędu w systemie otrzymuje on status “Otwarty”. Jeśli opisaliśmy zgłoszenie tak jak należy, czyli nie będzie wątpliwości gdzie jest błąd i na czym polega, to powinniśmy do niego wrócić, gdy otrzyma status “Do sprawdzenia”. Ale zanim go otrzyma, będzie on powtórzony przez programistę, następnie przez niego poprawiony. Kolejnym krokiem będzie review poprawki zrobiony przez innego programistę niż, ten który poprawił defekt. Więcej o cyklu życia defektu przeczytasz w jednym z moich artykułów.

Chcesz dowiedzieć się jak zgłosić błąd i przećwiczyć to ze mną?

W ofercie mojej firmy są korepetycje, w ramch ich możemy przećwiczyć wszystko to co opisałem w tym artykule.  Możemy połączyć się przy pomocy Skype, udostępnię Ci ekran mojego komputera w taki sposób byś mógł wykonywać wszystkie ćwiczenia na moim komputerze samodzielnie. 

 

 

Znalazłeś błąd na tej stronie? Zgłoś mi go.
Formularz zgłoszenia błędu

Jeśli znalazłeś błąd w tekście lub na stronie to proszę, zgłoś mi go. Większość pól tego formularza nie jest wymagana. Jeśli chcesz zgłosić błąd tak, jak powinno się to zrobić, wypełnij je wszystkie.

W formularzu brakuje pola „dodaj załącznik”, ponieważ użycie tej formatki jest płatne. Jeśli jednak chcesz wysłać mi załącznik, prześlij go na e-mail waldemar.szafraniec.szkolenia@gmail.com, w tytule wiadomości napisz, że jest to załącznik do zgłoszenia błędu.

Podany e-mail będzie wykorzystany tylko w celu obsługi tego zgłoszenia - zostaniesz poinformowany, gdy błąd zostanie poprawiony. Podanie e-mail nie jest równoznaczne z zapisem na newsletter.
Tytuł powinien w sposób jasny i czytelny mówić co nie działa na stronie.
Ile prób odtworzenia błędu udaje się odtworzyć.
Dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć.

Podziel się tym wpisem!

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz