Jak utworzyć szablon śledzenia błędów w Jira

Szablon śledzenia błędów to predefiniowany format dokumentowania i zgłaszania błędów w procesie tworzenia oprogramowania. Korzystanie z szablonu gwarantuje spójne uwzględnianie kluczowych szczegółów, co ułatwia śledzenie błędów, ustalanie ich priorytetów i komunikację w zespole.

Jira to narzędzie do śledzenia problemów firmy Atlassian i prawdopodobnie jedno z najpopularniejszych narzędzi do śledzenia błędów wykorzystywanych do zarządzania projektami programistycznymi (szczególnie w środowiskach zwinnych). W ciągu ostatnich kilku lat korzystałem z niego przy wielu projektach, zarówno w metodyce Scrum, jak i Kanban, i uważam je za bardzo wszechstronne.

W tym artykule omówię wszechstronność Jiry w zakresie śledzenia błędów, dostosowywania i zarządzania przepływem pracy, a także usprawniania raportowania błędów za pomocą Jiry.

Niezależnie od tego, czy odpowiadasz za konfigurację przepływów pracy w Jira, czy zgłaszasz za jej pomocą usterki, warto wiedzieć, jak ona działa. Jira to coś więcej niż tylko narzędzie do raportowania błędów, ale w tym artykule skupimy się bardziej na śledzeniu błędów niż na zarządzaniu innymi typami problemów.

Konfigurowanie nowego projektu za pomocą Jira Software

Jeśli projekt jest nowy, pierwszą rzeczą, którą należy zrobić, jest skonfigurowanie projektu w Jira. Zwykle zajmuje się tym mistrz Scruma lub kierownik projektu, ale jeśli Twoja rola w zakresie zapewniania jakości pokrywa się z jedną z tych ról, zadanie to może przypaść Tobie. Nie jest to skomplikowane, a w każdym razie powinno być jednorazowym zadaniem!

Rejestracja jest bezpłatna, a w przypadku małych projektów z udziałem mniej niż dziesięciu użytkowników można korzystać z bezpłatnego planu. Jeśli masz większy zespół lub potrzebujesz zaawansowanych funkcji, wybierz jeden z płatnych planów. Nie będę omawiać szczegółów, ale jeśli Cię to interesuje, możesz sprawdzić stronę z cennikiem Jiry.

Tworzyłem nowe projekty wyłącznie na potrzeby prowadzenia zajęć, ale proces jest dość intuicyjny. Będziesz mieć możliwość wyboru spośród różnych typów projektów związanych z tworzeniem oprogramowania:

Typy projektów

• Projekt Kanban umożliwia tworzenie tablic Kanban. Możesz użyć klasycznego szablonu z klasycznymi etapami: Do zrobienia, W toku i Gotowe.
• Scrum — ten szablon pozwala zespołowi zarządzać sprintami i rejestrem prac z wykorzystaniem metodyki Scrum.
• Śledzenie błędów – prosty szablon umożliwiający śledzenie problemów bez korzystania z żadnej metodyki zwinnej.

Wszystkie projekty można dostosować tak, aby uwzględniały potrzebne etapy, przejścia i statusy.

Na potrzeby tego poradnika użyję szablonu projektu Scrum, aby można było śledzić historyjki i błędy w ramach tego samego projektu, ale nie martw się — wszystko, co pokażę, można zastosować również do innych typów projektów!

Typy problemów

Domyślne typy problemów dostępne w Jira to:

• Epik: w metodykach zwinnych epik to wysokopoziomowy zbiór historyjek użytkownika i zadań.
• Błąd: typ problemu używany w Jira do śledzenia znalezionych błędów i usterek. Na nich skupimy się w dalszej części artykułu.
• Historyjka: historyjka użytkownika w metodyce zwinnej (opis funkcji lub działania, które mają zostać opracowane i przetestowane).
• Zadanie: zwykle używane do śledzenia pojedynczych problemów lub elementów do wykonania, na przykład zbadania nowego narzędzia do automatyzacji testów albo zaktualizowania dokumentacji.
• Podzadanie: pojedyncze zadanie przypisane członkowi zespołu, będące podrzędnym problemem wobec wspomnianego wyżej problemu typu „Zadanie”.

Jak już wspomniałem, Jira jest bardzo wszechstronna, a jeśli potrzebujesz utworzyć własny typ problemu, możesz to zrobić w dowolnym momencie w ramach projektu. 

Na przykład pracowałem kiedyś nad projektem, w którym mieliśmy osobny typ problemu dla usprawnień. Były one podobne do historyjek użytkownika, ale dotyczyły głównie rozszerzeń istniejących funkcji aplikacji.

Możesz też utworzyć typ zgłoszenia dla przypadków testowych, ale zajmiemy się tym nieco później, omawiając dostępne wtyczki i narzędzia do integracji z Jira.

Śledzenie błędów za pomocą Jira

Przejdźmy do tego, co interesuje nas jako testerów — zgłaszania i śledzenia błędów. Chociaż Jira jest narzędziem do zarządzania projektami, a nie narzędziem przeznaczonym konkretnie do śledzenia błędów, my, osoby zajmujące się zapewnianiem jakości, prawdopodobnie będziemy używać jej do zgłaszania wielu błędów 😁.

Przebieg pracy i cykl życia błędu

Domyślny przebieg pracy błędu (a właściwie wszystkich zgłoszeń) dostępny w Jira wygląda następująco:

Po otwarciu zgłoszenie jest tworzone ze statusem „Do zrobienia”. Następnie zgłoszenie lub błąd można przenieść do dowolnego innego statusu. 

Zespół zarządzania testami, scrum master lub kierownik projektu zwykle odpowiada za projektowanie niestandardowych przebiegów pracy.  

Przebieg pracy odzwierciedla cykl życia błędu, który chcesz mieć w projekcie. Możesz zachować domyślny, prosty przebieg albo utworzyć go tak złożonym, jak to konieczne. Szczerze mówiąc, nigdy nie pracowałem nad projektem, który nie miałby własnych, niestandardowych statusów i przejść.

Aby spersonalizować cykl życia, przejdź do ustawień projektu, wybierz typ zgłoszenia błędu i kliknij „Edytuj przebieg pracy”.

W tym miejscu możesz dodać dowolny nowy status i w razie potrzeby wybrać konkretne przejście. Oto przykład:

W tym przypadku po utworzeniu nowego zgłoszenia będzie ono miało status „Do zrobienia”, z którego można je przenieść wyłącznie do statusu „W toku”. Następnie, zanim błąd będzie można przetestować, kod musi zostać poddany przeglądowi. Zespół zapewniania jakości może zamknąć zgłoszenie po jego zweryfikowaniu w statusie „W QA”. Oczywiście przegląd kodu i procesy zapewniania jakości mogą zakończyć się niepowodzeniem, a w takim przypadku błąd zostanie przeniesiony z powrotem do statusu „W toku”.

Tworzenie przebiegu pracy krok po kroku

Omówię każdy krok, który należy wykonać, aby przejść od pierwszego przebiegu pracy do drugiego (lub dowolnego niestandardowego przebiegu odpowiedniego dla Twojego projektu):

1. Najpierw kliknij przycisk „Edytuj przebieg pracy”

2. Aby dodać nowy status, kliknij jeden z istniejących statusów — statusy są podzielone na trzy kategorie: „Do zrobienia”, „W toku” i „Gotowe”, a każdej z nich przypisano określony kolor. Możesz wybrać miejsce, do którego najlepiej pasuje Twój status. Uznałem, że statusy „W przeglądzie kodu” i „W QA” oznaczają, że zgłoszenie nadal jest w toku:

Możesz też mieć inne statusy „Do zrobienia”; na przykład status „W przeglądzie” może być używany, gdy otwarto zgłoszenie dotyczące nowej funkcji, a właściciel produktu lub analityk biznesowy musi jeszcze dodać informacje na jej temat albo zespół nie doprecyzował jeszcze jej zakresu i nie określił jej złożoności ani liczby punktów historyjki.

3. Po dodaniu nowego statusu możesz dodać do niego przejście. Domyślnie status można będzie zaktualizować z dowolnego innego statusu. Jeśli nie chcesz określać konkretnych reguł przejścia, nie ma problemu. Dobry przebieg pracy powinien jednak umożliwiać przenoszenie błędów i zgłoszeń do określonych statusów dopiero po przejściu przez nie pewnych etapów procesu. 

W powyższym przykładzie zespół zapewniania jakości nie może rozpocząć weryfikowania poprawki, zanim inny programista nie przejrzy kodu. Aby dodać to przejście, kliknij przycisk „Przejście” i wprowadź szczegóły:

4. Możesz także usunąć dowolne istniejące przejścia i statusy, jeśli chcesz w 100% dostosować wszystko do swoich potrzeb.

5. Bardzo przydatną funkcją jest automatyczne przypisywanie osób. Można je również skonfigurować w przebiegu pracy, ustawiając domyślnie przypisanego użytkownika, gdy w zgłoszeniu zostanie wykonane określone przejście (jest to również kluczowa korzyść z oprogramowania do śledzenia zgłoszeń).

Na przykład po tym, jak błąd zostanie przejrzany i przeniesiony do W QA, zostanie automatycznie przypisany do konkretnego testera lub kierownika testów, który zdecyduje, kto się nim zajmie. To samo dotyczy statusu W toku i zespołu programistycznego. Nowo utworzone zgłoszenia mogą być automatycznie przypisywane kierownikowi projektu lub właścicielowi produktu, który ustali ich priorytet w rejestrze zadań. Funkcja ta jest wysoce konfigurowalna, dzięki czemu można ją dostosować do potrzeb zespołu. 

Nawet jeśli nie odpowiadasz za konfigurowanie cykli życia zgłoszeń lub nie masz dostępu do ustawień projektu, możesz wyświetlić przepływ pracy dla każdego zgłoszenia Jira, rozwijając listę statusów:

Wyświetlanie zgłoszeń w Jira

Jeśli projekt nie służy do śledzenia błędów, bieżące zgłoszenia można wyświetlać na tablicach Kanban lub Scrum:

To tylko demonstracja; wątpię, czy kiedykolwiek będziesz mieć tyle szczęścia, aby mieć sprint z tylko jedną historyjką użytkownika i jednym błędem 😅.

Po kliknięciu dowolnego zgłoszenia zostaną wyświetlone jego szczegóły. Obejmują one między innymi identyfikator, który jest automatycznie tworzony przez Jira, tytuł, opis, osobę zgłaszającą, osobę przypisaną oraz wszelkie załączniki lub komentarze dodane przez członków zespołu.

Pola również można dostosowywać, co pokażę, gdy omówimy, co powinno znaleźć się w dobrym zgłoszeniu błędu.

Osoby przypisane

Każde zgłoszenie Jira można przypisać konkretnemu członkowi zespołu. Możesz oznaczać osoby w komentarzach lub opisie, używając znaku @ przed nazwą użytkownika. 

Otrzymasz powiadomienia, gdy ktoś Cię oznaczy oraz gdy zgłoszenie przypisane do Ciebie lub zgłoszone przez Ciebie zostanie zaktualizowane. Możesz także „obserwować” zgłoszenia. Otrzymasz powiadomienie o aktualizacji obserwowanych zgłoszeń niezależnie od osoby zgłaszającej lub przypisanej.

Zgłaszanie błędów w Jira

Aplikacja z niewielką liczbą błędów to cel, do którego wszyscy dążą, ale bądźmy szczerzy: testerzy zawsze cieszą się, gdy znajdziemy dobry błąd.

Dobry błąd jest jednak tak dobry, jak sposób, w jaki go zgłosimy — dobre zgłoszenie błędu sprawi, że zostanie on naprawiony przy jak najmniejszej liczbie dodatkowych ustaleń między zespołami testowym i programistycznym. Jira to świetne narzędzie do śledzenia błędów. Czy już o tym wspominałem? Zapewnia dużą elastyczność.

Aby utworzyć nowe zgłoszenie, kliknij duży przycisk „Utwórz”, a otworzy się okno dialogowe. Wybierz w nim typ zgłoszenia Błąd:

Dobre zgłoszenie błędu powinno zawierać dobry opis (lub pole „Podsumowanie” w Jira). Powinien być zwięzły, ale zawierać wystarczająco dużo szczegółów, aby jasno wyjaśniać, czego dotyczy problem. 

Następnie w opisie dodaj wszystkie istotne szczegóły. Możesz uporządkować je w klasyczny sposób: 

• Kroki umożliwiające odtworzenie
• Oczekiwany rezultat
• Rzeczywisty rezultat

Następnie dodaj wszelkie inne szczegóły istotne dla wady. Zrzuty ekranu lub nagrania są zawsze dobrym pomysłem, podobnie jak dzienniki lub konkretne pliki używane podczas wykonywania operacji.

Jira umożliwia dodawanie niestandardowych pól do zgłoszeń. Lubię oddzielać Ważność od Priorytetu. Chociaż Priorytet jest domyślnym polem dodawanym przez Jira, możesz dodać własne pole dla Ważności.

Inne niestandardowe pola, które warto dodać, mogą dotyczyć systemu operacyjnego — może to być pole tekstowe lub lista rozwijana ze zdefiniowanymi wartościami, takimi jak wersje systemów Android i iOS używane podczas testów, przeglądarka, numer kompilacji lub dowolne inne informacje, które mogą być istotne podczas śledzenia błędów.

Aby dodać nowe pola, przejdź do ustawień projektu, wybierz typ Błąd i wybierz potrzebny typ pola: 

Przypadki testowe w Jira

Ostatnią rzeczą, o której chcę wspomnieć, są przypadki testowe. Oprogramowanie Jira można zintegrować z różnymi narzędziami do zarządzania testami albo dodać rozszerzenia i dodatki Atlassian, takie jak Zephyr (który kiedyś był moim ulubionym narzędziem) lub Xray. Gdy utworzysz błąd w wyniku nieudanego przypadku testowego, test można połączyć z błędem, co może być bardzo pomocne w zarządzaniu błędami, testami i wykonywaniem przypadków testowych.

Chcesz wiedzieć więcej?

Jira może być świetnym narzędziem do śledzenia defektów i usprawnić proces tworzenia oprogramowania, ponieważ pozwala na szerokie dostosowanie. Jeśli chodzi o błędy, jest naprawdę przydatna, ponieważ możesz dostosować przepływ pracy do cyklu życia, który chcesz mieć w swoim projekcie. Możesz łączyć błędy z przypadkami testowymi i dodawać pola niestandardowe w sposób najlepiej dopasowany do konkretnego projektu.

Aby uzyskać więcej podobnych poradników, zasubskrybuj biuletyn The QA Lead.