O tym przeczytasz w tym wpisie
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 formularz 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 / defekt / usterka?
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.
- Jeśli w firmie wprowadzony jest słownik komponentów, czyli standaryzacja nazewnictwa elementów aplikacji jak widoki, okna, stany, to używaj ich podczas pisania kroków testowych.
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.
Dla upewnienia sprawdzasz jeszcze dwa razy – błąd występuje za każdym razem. Przechodzisz zatem do jego opisu.
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 ramach 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.
