Teoretycznie o Jira miałem nic już nie pisać, temat wydawał mi się wyczerpany i cykl zamknąłem wpisem o wyszukiwaniu zgłoszeń. Tymczasem podczas niedawnych korepetycji z testowania, w których trakcie ćwiczyliśmy użycie tego narzędzia, dostałem super pytanie! Brzmiało ono „Co jest Twoim zdaniem lepsze? Komentarze pod zgłoszeniami i Re-openowanie? Czy też Tworzenie nowych Sub-bugów pod taskami?”. Chodziło o sytuację, gdy retestowany błąd nadal występuje. I tak powstał temat na kolejny wpis o Jira.
Co robimy w Jira, w sytuacji, gdy retestowany błąd nadal występuje?
Pewnie nie uwierzysz, jak powiem, że odpowiedź na pytanie zależy przede wszystkim od wielkości projektu. Jeżeli będzie to mały projekt, to w prosty sposób możemy to obsłużyć zmianą statusu zgłoszenia i dodaniem odpowiedniego komentarza w zgłoszeniu. Dzięki temu zachowamy czytelność w projekcie i dostęp do potrzebnych informacji, które są zwyczajnie dla nas potrzebne.
Cykl życia błędu w Jira na przykładzie małego projektu
Na obrazku powyżej możesz zobaczyć, jak komentarzami dodawanymi do zgłoszenia, można obsłużyć cykl życia błędu w Jira. Na zrzucie tego nie widać, ale każdorazowo po dodaniu komentarza tester zmieniał również statusu zgłoszenia. Ważne by komentarze informowały i nie wymagały wyjaśnienia. Oszczędzisz dzięki temu czas swój i kolegów.
W przypadku, gdy zgłoszenie jest ponownie otworzone, warto dodać komentarz informujący o tym, przykładowo „Zadanie zostało otworzone ponownie (ja dodaję datę i godzinę do tego komentarza, ponieważ Jira nie wyświetla tych danych najlepiej)”. Tester zmienia również status zgłoszenia na „Backlog”. Developer, który błąd poprawi, doda komentarz „Zadanie naprawione” i zmieni jego status na „Do testów”. Następnie tester zmienia status błędu na „W testach”, po reteście dodaje komentarz „Zretestowane i zamknięte [data]” i ustawia status zgłoszenia na „Gotowe/Zamknięte”.
Jak widzisz w przypadku małych projektów, informacja o kolejnych statusach przechowywana może być w komentarzach. Zmiana statusu zgłoszenia powoduje, że zostaje on automatycznie przeniesiony do właściwej kolumny w tablicy. Odpowiednia osoba zajmie się nim.
Obsługa zgłoszeń w Jira w dużych projektach
Przy projektach dużych dany błąd może wystąpić na przestrzeni lat parokrotnie. Obsługa błędów poprzez dodawanie komentarzy z czasem powodowałaby problemy z czytelnością. Jira od pewnej ilości komentarzy zaczyna nam je zawijać. Co za tym idzie w celu sprawdzenia kontekstu i tego, co ze zgłoszeniem się działo, konieczne byłoby rozwijanie sekcji komentarzy, przewijanie jej i czytanie kolejnych wpisów w celu zrozumienia kontekstu. Przy kilkunastu komentarzach, konieczne ich przewijanie i czytanie, powoduje, że tracimy dużo czasu na zapoznanie się z tym, co się działo ze zgłoszeniem od momentu jego utworzenia.
Komentarze w Jira powinny być bardzo czytelne. Moim zdaniem ich czytelność powinna być tak dobra, jak czytelność kroków do odtworzenia błędu.
Tworzenie SUB-BUGA
Na czym polega zatem podejście z SUB-bugami? Sprawa ta jest stosunkowo prosta. Zaczynamy od budowy projektu, który składa się z przeróżnych modułów takich jak Rejestracja, Logowanie i wielu innych w zależności co aplikacja robi. Każdy z tych modułów jest dodany do Jira jako osobny task np.: Stworzenie formularz Logowania. Każdy błąd od tej pory znaleziony w ramach formularza Logowania powinien zostać założony pod tym konkretnym taskiem (zlinkowany).
Co więcej, jeżeli przykładowo w maju zgłosimy, a następnie po retestach zamknęliśmy błąd do tego modułu np. „Pole login jest za małe”, to przy kolejnym znalezieniu tego samego błędu w grudniu, nie powinniśmy go reopenować tylko zgłosić kolejny błąd „Pole login jest za małe”. Dlaczego tak?
Mam na to dwa powody:
Czytelność
Dzięki tego typu podejściu po wejściu do Jira wiemy, co jest źle, jeżeli chodzi o naszą aplikację. Dużo zgłoszeń zlinkowanych z danym taskiem może dać nam informacje, jaki obszar powinniśmy jako zespół wziąć pod lupę i rozważyć jego naprawę lub przepisanie (ponieważ jakiegoś powodu bugi wracają jak bumerang).
Unikanie duplikatów
Jeśli mamy podpięte Sub-bugi pod taska z Logowaniem, to widzimy wszystkie zgłoszenia, jakie są dodane do tego konkretnego zadania. Dzięki temu dobierając innych testerów do projektów, nie musimy aż tak bać się o duplikaty błędów. Zgłoszenia dotyczące konkretnego niedziałającego modułu znajdują się w jednym konkretnym miejscu. Tester, zanim zgłosi błąd, ma obowiązek przeszukać listę już zgłoszonych błędów do danego modułu. Jeśli ten, który chce zgłosić, jest na liście ze statusem zamknięty, to tester tworzy sub-buga do taska o logowaniu, równocześnie linkuje go również z błędem już zamkniętym.
Teraz zapewne część z was się trochę obruszyła, bo przecież mogę wrzucać w przestrzeń projektową moje zgłoszenia i łączyć je za pomocą tego pola:
Zgadza się, mogę. Pod takim zgłoszeniem będę miał link do zgłoszenia powiązanego z tym, które zgłaszam. Tylko właśnie powoduje to, że muszę przez to poruszać się linkami, które z kolei mogą mnie zaprowadzić w odmęty projektu Jira. Tu dużo zależy już od naszej własnej umiejętności korzystania w pracy z wielu zakładek i poruszania się w przeglądarce – chyba najlepiej to określić jako organizację własnej pracy.
