Jak zamknąć błąd, który nie jest już istotny

Obecnie pracuję w średnim zespole programistów. Używamy Jira do śledzenia błędów.

Pracujemy nad produktem z częstymi zmianami układu. Wiele razy zgłaszane są błędy dotyczące błędu w układzie w niektórych przeglądarkach. Czasami, zanim zajmiemy się błędem o niskim priorytecie, układ już się zmienił i nie jest już istotny.

• Jak powinniśmy to zamknąć?
  Mam na myśli to, jak powinniśmy traktować te problemy? Chociaż Jira jest oprogramowaniem do śledzenia błędów, którego używamy, bardziej interesuje mnie, jak ogólnie radzić sobie z tego rodzaju problemami.
• Czy to w ogóle ma znaczenie? (My może powrócić do układu później, ale jest to bardzo mało prawdopodobne)

Niuanse takie mają znaczenie, jeśli traktujesz narzędzie do śledzenia problemów jako sposób komunikowania stanu problemów zgłoszonych w projekcie. W tym celu warto poświęcić trochę wysiłku, aby raport o błędzie był łatwy do odczytania i zrozumienia.

Ta sytuacja staje się znacznie mniej myląca, jeśli spojrzysz na nią z perspektywy testera. Jeśli twój zespół nie ma testera, wyobraź go sobie (lub jeszcze lepiej, zatrudnij ^{1 , 2 , 3} ).

Okej, więc dawno temu pojawił się błąd, tester może go odtworzyć przy użyciu starszych wersji aplikacji (uwaga dodatkowa w mało prawdopodobnym przypadku, gdy nie przechowujesz kopii starszych wersji, wtedy masz o wiele trudniejsze problemy) zespół niż przestarzałe błędy). Tester może to zobaczyć i stwierdzić, co jest nie tak, co powoduje, że jest to błąd.

Teraz mówicie: „układ już się zmienił i nie jest już istotny” - wysoki brew nie ma już znaczenia, zamienia się w umyśle testera w znacznie prostsze stwierdzenie: problem zniknął .

• Należy tutaj zauważyć, że profesjonalny tester powinien swobodnie myśleć o systemie jako czarnej skrzynce . Z tej perspektywy nie ma znaczenia, jak dokładnie zdarzyło się, że problem zniknął, może to być zmiana układu, czarna magia lub całkowite przeprojektowanie lub konkretna zmiana kodu, cokolwiek.

Z perspektywy czarnej skrzynki twoja sytuacja jest dość prosta. Wystąpił problem, nadal jest odtwarzalny w starszej wersji, teraz twierdzisz, że w nowszej wersji nie ma już takiego problemu. Dla testera sprowadza się to do twierdzenia, że ​​błąd został naprawiony i, odpowiednio, do potrzeby sprawdzenia, czy twierdzenie jest prawdziwe.

Profesjonalny tester weźmie starszą wersję, sprawdzi, w jaki sposób występuje tam problem, a następnie weź nowszą wersję i sprawdzi, czy już jej nie ma.

Z góry najdokładniejszym sposobem radzenia sobie z błędami, które opisujesz, byłoby zamknięcie ich jako rozwiązane, naprawione . Oczywiście nie zaszkodzi, jeśli wyjaśnisz w komentarzach, że poprawka pojawiła się jako niezamierzony efekt uboczny zmiany układu.

Jedna ze zindywidualizowanych JIRA, z którymi pracowałem w poprzednim projekcie, miała rozdzielczość „Naprawiono według projektu”, aby komunikować dość głębokie zmiany mające wiele konsekwencji, niektóre celowe, inne nie. W takim przypadku, który opisujesz, można to również rozważyć zamiast zwykłego „Naprawionego”, ponieważ sugeruje to czytnikowi biletów, że jest to raczej efekt uboczny niż celowa zmiana kodu.

Rozwiązujemy takie problemy, jak „Przestarzałe”. Nie jest to domyślna opcja rozdzielczości w JIRA, ale można ją łatwo dodać.

JIRA (i jestem pewien, że inne narzędzia do śledzenia błędów) pozwala określić niestandardowe rozdzielczości, więc powinieneś być w stanie ustawić rozdzielczość „Overtaken By Events” lub „Irrelavant”, lub podobną, aby umożliwić Ci wyrażenie zamknięcia, jak chcesz

Czy to ma znaczenie? to zależy, dla nas powiedziałbym tak, ponieważ nasz klient jest nadmiernie zaniepokojony liczbą otwartych problemów w naszym module do śledzenia, więc dla nas warto powiedzieć, że są one zamknięte, ponieważ nie są już istotne bez całkowitego usunięcia problemu .

Nawet jeśli klient nie jest zainteresowany numerami problemów, przycinanie starych otwartych problemów, które nie są już istotne, jest zdecydowanie przydatne tylko w celu zmniejszenia bałaganu w przeglądarce.

Używamy FogBugz, ale jestem pewien, że to samo (lub podobne) dotyczy tutaj:

Używamy po prostu „Rozwiązane (naprawione)” i komentujemy w rozdzielczości coś w stylu „Naprawiono przez przypadek 12345”.

FogBugz pasuje do „case \ d +” i łączy je ze sobą w obszarze Powiązane przypadki, ale jeśli Jira tego nie zrobi, wystarczy dodać link.

Jest to IMO lepsze niż wariant „Zbyt zlokalizowane”, ponieważ był to prawdziwy błąd, i lepsze niż tylko „Przestarzały”, ponieważ został naprawiony, ta funkcja nie została po prostu usunięta.