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

21

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)
Benjamin Gruenbaum
źródło
8
Too Localized;)
yannis 10.04.13
4
nie zgadzam się, że jest to zbyt zlokalizowane, może lepiej pasować do SO, chociaż może być specyficzne dla narzędzia
jk.
6
@jk. Heh, miałem na myśli „zbyt zlokalizowany” jako sugestię / odpowiedź na pytanie, a nie to, że samo pytanie jest „zbyt zlokalizowane”. Gdybym myślał to drugie, właśnie bym to zamknął.
yannis
2
@YannisRizos doh! być może powinna to być odpowiedź;)
jk.
6
@jk. Myślę, że drugie pytanie jest bardziej interesujące (czy to w ogóle ma znaczenie?), Ale nie mam teraz czasu, aby na nie odpowiedzieć (i nie jestem pewien, czy odpowiedź, która pojawia się w mojej głowie, jest dobra). Jeśli chodzi o pierwsze pytanie, jeśli wątek ten stanie się „sugestią słowa / wyrażenia”, może zostać zamknięty jako „niekonstruktywny”. Odpowiadajcie więc, proszę, nie ignorujcie drugiego pytania, to jest tematyczne i interesujące.
yannis

Odpowiedzi:

26

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.

komar
źródło
2
Naprawione przez Projekt oznaczałoby dla mnie kompletne przeciwieństwo tego. Moim zdaniem z założenia oznacza „celowe” (jest to przeciwieństwo „przez pomyłkę”).
TRiG
Zgadzam się, że „ustalony” jest wystarczający. W ogóle nie ma znaczenia, czy był to celowy, czy efekt uboczny innych zmian. Zgadzam się jednak z @TRiG, ​​że „Naprawione przez projekt” jest mylące.
1
@TRiG dobrze, dlatego wskazałem, że lepiej wyjaśnić dokładne szczegóły w komentarzach. Naprawiono według projektu jest nieco szeroki; w projekcie, który widziałem, wykorzystano go do komunikowania raczej głębokich zmian mających wiele konsekwencji, niektóre celowe, inne nie - w ten sposób obejmujące takie przypadki. Zauważ też, że ani tekst pytania, ani moja odpowiedź nie sugerują „napraw przez pomyłkę” (jaki błąd?) - tutaj „niezamierzone” jest o wiele lepiej dopasowane
gnat
1
Wszystkie odpowiedzi są dobre, ale wydaje się, że to trafia. Dziękuję wszystkim.
Benjamin Gruenbaum,
6
Co powiesz na „Naprawione przez przeprojektowanie”?
pingwin
47

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

Kris
źródło
+1, jeśli nie możesz go dodać, przynajmniej wybierz jako nie błąd i skomentuj dlaczego
tgkprog 17.04.2013
9

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.

jk.
źródło
1
„Przejęte przez zdarzenia” jest zbyt długie (imho), wybrałbym jedno słowo (nieistotne / nieaktualne) tylko dlatego, że łatwiej jest wyszukiwać i zajmuje mniej miejsca (w raportach itp.). Kiedyś wiedza o ilości naszych przestarzałych błędów była przydatna, gdy przychodziły masowo, co wskazywało na problem z komunikacją. Nasi testerzy nie byli na bieżąco z tym, nad czym pracowali nasi programiści, przeoczyli notatkę, że sprawy będą się kruszyły przez około tydzień i będą hałasować (bezużyteczne). Patrząc wstecz na naszą obs. Błędy pomogły nam znaleźć i naprawić dziurę w naszych procesach komunikacyjnych.
yannis
3
faktycznie używamy akronimu OBE, ale myślę, że użyte słowo jest najmniej interesującym punktem, chodzi o to, aby wybrać coś, co działa dla ciebie
jk.
3
@YannisRizos: Naprawianie meta-błędów za pomocą błędów. Jakie to jest świetne!
Jörg W Mittag
Wyszukiwanie @YannisRizos nie stanowi większego problemu, ponieważ i tak ważne rozdzielczości są wybierane z listy rozwijanej (w JIRA)
jk.
2
@Yannis. Przez to straciłbym sen: wyprzedzenie powinno być jednym słowem.
TRiG
5

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.

Izkata
źródło
3
Naprawiono przez wytrzeźwienie i ponowne sprawdzenie <- prawdziwa historia.
yannis
1
Jira również dopuszcza takie podejście. Wystarczy wspomnieć o numerze problemu w komentarzach do rozwiązania, a Jira zmieni go w hiperłącze.
Marjan Venema