Dlaczego nie zaleca się zamieszczania kilku wad tego samego problemu / biletu?

Nie jestem pewien, czy jest to miejsce, w którym można zadać następujące pytanie koncepcyjne (Stackoverflow zdecydowanie nie jest).

Widziałem to pytanie na egzaminie wielokrotnego wyboru (jedna odpowiedź), podobnym do egzaminów ISTQB :

Dlaczego nie zaleca się zgłaszania kilku wad tego samego problemu / zgłoszenia?

za. Aby raport był zwięzły i jasny.

b. Ponieważ programiści mogą naprawić tylko jeden błąd.

do. Ponieważ testerzy grupy testowej są oceniani na podstawie liczby znalezionych błędów.

re. Systemy zarządzania błędami nie obsługują tej funkcji wielu błędów.

Moim jedynym zdaniem jest ato poprawna odpowiedź.

b- nie może być tak, ponieważ poprawiona informacja zwrotna rozwiązana-zamknięta powinna tego uniknąć. c- Oczywiście źle.

d - Wtyczki Redmine / Trac obsługują wiele pól.

Odpowiedź zgodnie z arkuszem odpowiedzi to b.

Czy ktoś może wyjaśnić, dlaczego? Komentarze z opiniami na temat odpowiedzi są mile widziane.

Wyobraź sobie, że stos przepełnienia stosował się do wytycznych: zamiast zadawać jedno pytanie, przychodzisz i zadajesz, w tym samym pytaniu, cokolwiek przyjdzie ci do głowy, wszystkie problemy, które miałeś przez ostatnie dwa tygodnie. Co znaczyłyby głosowanie w górę i w dół? Jakie byłyby tytuły pytań? Jak zaakceptować najlepszą odpowiedź? Jak oznaczyć pytanie?

System śledzenia błędów służy do ... śledzenia błędów. Śledzenie błędu oznacza:

1. Utworzenie rekordu informującego o istnieniu błędu zawierającego informacje o sposobie jego odtworzenia,

2. Potwierdzając, że rzeczywiście, błąd istnieje i jest błędem, a nie czymś z założenia,

3. Zapewniając, że błąd został już rozwiązany,

4. Potwierdzenie, że błąd został rozwiązany.

W bardzo uproszczonym modelu 1 i 4 zostaną wykonane przez klienta, a 2 i 3 przez dewelopera.

Wyobraź sobie następujący dziennik:

• Dzień 1 [Klient] Po naciśnięciu przycisku „Usuń” w oknie „Szczegóły produktu” aplikacja zawiesza się. Ponowne uruchomienie aplikacji pokazuje, że produkt nie został usunięty. Oczekiwanym zachowaniem jest usunięcie produktu.

• Dzień 4 [Deweloper] <Wydano problem>

• Dzień 5 [Deweloper] <Problem rozwiązany w wersji 5031>

• Dzień 12 [Klient] <Bilet zamknięty: problem rozwiązany>

Dziennik jest prosty i przejrzysty . Możesz łatwo śledzić, co zostało zrobione i kiedy , która wersja rozwiązała dany błąd itp. Na przykład, jeśli system śledzenia błędów jest zintegrowany z kontrolą wersji, podczas przeglądania konkretnej wersji możesz sprawdzić, jakie błędy zostały w niej rozwiązane.

Łatwo jest znaleźć informacje . Łatwo jest zobaczyć jego stan (czy jest reprodukowany? Jeśli bilet został zamknięty, dlaczego?). Łatwo jest filtrować bilety (chcę wyświetlać bilety, które dotyczą tylko interfejsu użytkownika wtyczek, biorąc pod uwagę, że chcę tylko bilety, które są otwarte, starsze niż tydzień i przypisane mi przez naszego projektanta interakcji i mają średni lub wysoki priorytet).

Łatwo jest ponownie przypisać bilet lub pierwotnie ustalić, która osoba powinna być odpowiedzialna za błąd.

Teraz wyobraź sobie następujący dziennik:

• Dzień 1 [Klient] Aplikacja zawiesza się po naciśnięciu przycisku „Usuń” w oknie „Szczegóły produktu”. Ponadto kolor tła lewego panelu jest ciemnoniebieski, podczas gdy powinien być fioletowy. Zauważyłem również, że tekst okna „Szczegóły produktu” nie jest dobrze przetłumaczony na niemiecki; czy jest oczekiwany? Kiedy będzie dostępne ostateczne tłumaczenie? BTW, czy otrzymałeś nową ikonę, którą wysłałem do akcji „Publikuj produkt”? Nie widzę tego w oknie „Synchronizuj dane”.

• Dzień 6 [Developer] Zmieniłem kolor na fioletowy.

• Dzień 7 [Developer] Tak, to normalne, że tłumaczenie na niemiecki jest niekompletne.

• Dzień 8 [Klient] Ok dla niemieckiego. Co z włoskim? Lucia przesłała ci plik XML dwa dni temu.

• Dzień 9 [Deweloper] Teraz jest w porządku.

• Dzień 10 [Klient] Ok, dla przycisku „Usuń”? Dziwne, na moim komputerze nadal się zawiesza.

• Dzień 11 [Deweloper] Nie, chciałem powiedzieć, że jest w porządku dla tłumaczenia na włoski.

• Dzień 12 [Klient] Rozumiem. Dziękuję Ci. Ale jest problem z kolorem. Zmieniłeś go na ciemnofioletowy, ale powinien on być jasnofioletowy, podobnie jak górny panel w głównym oknie.

• Dzień 13 [Deweloper] Zaktualizowałem ikonę.

• Dzień 14 [klient] Ikona? Jaka ikona

• Dzień 15 [Deweloper] Ikona, którą poprosiłeś mnie o aktualizację.

• Dzień 16 [Klient] Nigdy nie prosiłem cię o aktualizację żadnej ikony.

• Dzień 17 [Developer] Oczywiście, że pytałeś. Zobacz ten bilet. Napisałeś, że ikona publikowania produktu powinna zostać zaktualizowana. Zrobiłem to.

  ⁞

• Dzień 100 [Klient] A co z wpisami do dziennika?

• Dzień 101 [Deweloper] Nie mam pojęcia o czym mówisz. Nie ma go nawet w tym bilecie, ale w 6199. Zamykam ten jako rozwiązany. <Bilet zamknięty: problem rozwiązany>

• Dzień 102 [Klient] Przykro mi, że ponownie go otworzyłem, ale problem nie został rozwiązany. Mówię o wpisach w dzienniku: W zeszłym tygodniu powiedziałem, że tekst jest czasem nieprawidłowy, gdy zawiera znaki Unicode. Pamiętasz? <Bilet ponownie otwarty>

• Dzień 103 [Deweloper] Niejasno pamiętam coś takiego, ale po przeszukaniu trzech ostatnich stron tego biletu nie mogę znaleźć żadnego śladu. Czy możesz napisać jeszcze raz, na czym polegał problem?

  ⁞

• Dzień 460 [Developer] Spędziłem dwie godziny, szukając śladu tego, co powiedziałeś o plikach wysłanych zaszyfrowanych przez sieć. Nie jestem pewien, czy mogę znaleźć dokładną prośbę.

• Dzień 460 [Klient] Powinniście być bardziej zorganizowani. W ciągu ostatnich dwóch tygodni powiadomiłem Cię cztery razy o tym problemie. Dlaczego wszystko zapominacie?

  ⁞

O czym jest ten dziennik? Został rozwiązany 43 razy i ponownie otwarty 43 razy. Czy to oznacza, że ​​deweloper jest tak głupi, że nie może rozwiązać tego samego problemu przez 460 dni? Ach, nie, czekaj, ten bilet został w międzyczasie przydzielony 11 programistom. O co chodzi? Jak wyszukać konkretny problem? W rzeczywistości jest przypisany do Vanessy, ale jej pięciu kolegom również niepokoi siedem z jedenastu problemów zawartych w tym bilecie. Kiedy bilet powinien być zamknięty? Czy to wtedy, gdy połowa problemów zostanie rozwiązana? A może dziesięć na jedenaście?

Uwaga: możesz wierzyć, że takie dzienniki nie istnieją. Uwierz mi, widziałem te więcej niż jeden raz.

Aby skomentować twoje oświadczenie:

nie może być tak, ponieważ poprawiona informacja zwrotna rozwiązana-zamknięta powinna tego uniknąć

Zakłada się, że wszystkie zgłoszone błędy zostaną naprawione w tym samym czasie. Wyobraź sobie scenariusz, w którym bilet jest wystawiany w stosunku do wersji 1 produktu z dwoma problemami:

1. Przycisk resetowania formularza faktycznie wysyła formularz, zamiast kasować wartości
2. Rozmiar czcionki na przycisku wynosi 110%, kiedy powinien wynosić 115%.

Oba są poprawne dla testera do podniesienia, ponieważ oba są błędami w implementacji. Powiedzmy jednak, że właściciel produktu decyduje, że pierwsze podzadanie jest blokerem do zwolnienia (tj. Musi zostać naprawione, zanim produkt będzie mógł zostać uruchomiony), ale drugie zadanie jest drobnym problemem (tj. Można je naprawić w wersji 1). 1 wydanie).

W takim przypadku nie mamy innego wyboru, jak podzielić numer 2 na własny bilet (lub ryzykować zapomnienie o nim). Jeśli możemy to zrobić, oznacza to, że można je wdrażać, testować i wdrażać niezależnie od siebie, w takim przypadku sensowne są indywidualne problemy od samego początku.

Zakres:

Ta odpowiedź (i pytanie) wydaje się mieć zastosowanie tylko do śledzenia defektów kodu, gdy kod źródłowy nie działa zgodnie ze specyfikacją lub intencjami programistów.

Przeciwnie, bilety defektu GUI często zawierają wiele specyfikacji, ponieważ każdy bilet GUI jest w rzeczywistości „przeprojektowaniem” (defektem projektu), „poprawioną specyfikacją” lub „żądaniem funkcji” (brak funkcji).

Jednym z ważnych celów śledzenia defektów jest komunikacja i koordynacja wielu ról (programistów, testerów, klientów i menedżerów).

W projektach, w których jakość kodu ma duże znaczenie (na przykład w porównaniu z przyjaznością dla użytkownika), śledzenie defektów może składać się z wielu aspektów, z których jeden koncentrowałby się na śledzeniu defektów kodu , osobno od śledzenia ulepszeń i żądań obsługi klienta.

System śledzenia defektów ma na celu:

• Aby umożliwić niezależne i jednoznaczne śledzenie niezależnie odtwarzalnych defektów, oraz
• W celu zapewnienia najlepszego przybliżenia (korespondencji jeden do jednego) pierwotnej przyczyny każdej wady.

Robiąc to, powinien zmaksymalizować następujące pożądane cechy:

• Skaluj efektywnie wraz ze wzrostem liczby wad.
• Zapobiegaj syndromowi ruchomego celu.

Uwaga: ta fraza pochodzi z mojego osobistego doświadczenia. Może być niewystarczający lub niepoprawny do celów egzaminu certyfikacyjnego.

Niezależne i jednoznaczne śledzenie oznacza, że:

1. Każda ważna wada może zostać rozwiązana lub nierozwiązana bez dwuznaczności.

   • Powód 1: aby uprościć zarządzanie,
     • Przykład: umożliwia użycie „liczby nierozstrzygniętych zgłoszeń” jako miary.
   • Powód 2: przełożyć na przedmiot możliwy do wykonania
     • Przykład: jeśli nie zostanie rozwiązany, odpowiedzialność spoczywa na przypisanym programatorze. Jeśli zostanie rozwiązany, ale nie zamknięty, odpowiedzialność spoczywa na przypisanym testerze (weryfikatorze).
   • Konsekwencja: W tej metodologii częściowo rozwiązana wada zasługuje na rozbicie na kilka wad zależnych.

2. Niezależnie odtwarzalne wady należy śledzić niezależnie.

   • „Niezależnie odtwarzalne” oznacza, że ​​mogą mieć różne stany. Jeden może wydawać się naprawiony, podczas gdy drugi pozostaje zepsuty.
   • Powód: aby zminimalizować niedopasowanie między śledzeniem defektów a analizą przyczyn źródłowych.
     • Uważa się, że każda przyczyna pierwotna, którą można przypisać do defektu kodu, wymaga co najmniej jednej zmiany kodu.
     • Jeśli dwie wady są niezależnie odtwarzalne, konieczne będą liczne zmiany kodu.
     • Jeśli dwie wady są niezależnie odtwarzalne, oba muszą zostać przetestowane (zweryfikowane), ponieważ zdanie jednego testu nie oznacza, że ​​drugi test przejdzie pomyślnie.
   • Przykład 2: jeśli początkowo przypuszczano, że dwa objawy mają tę samą przyczynę, a tym samym zostały zaklasyfikowane do tego samego zgłoszenia, a później wykazano, że są one niezależnie odtwarzalne, należy je podzielić na dwa zgłoszenia.

Spójrz na to z perspektywy innej osoby korzystającej z systemu, która pojawi się kilka miesięcy później. Znajdują błąd w programie. Szukają w Google i widzą, że istnieje bilet pomocy technicznej, który pasuje do problemu, który mają. I hej, jest zamknięty! Niesamowite! Zostało to naprawione w najnowszej wersji! Więc aktualizują ... a błąd nadal tam jest? Co jest nie tak z tymi głupimi programistami?!?

Właściwie nic. Okazuje się, że coś złego dzieje się z osobą zgłaszającą błąd. Zgłoszono dwa błędy w tym samym bilecie. Jedno było łatwe do naprawienia, a szybko naprawione, a drugie nie. Nawet jeśli użyjesz czegoś takiego jak fix-feedback-resolved-closed, nadal może być mniej niż jasne, co się dzieje, szczególnie dla obserwatora zewnętrznego.

O wiele lepiej jest nadać każdemu błędowi własny bilet, a jeśli masz wiele błędów, które są ze sobą powiązane, ale pozornie różne, większość systemów śledzenia błędów ma funkcję, która pozwala połączyć jeden błąd z drugim. (A jeśli nie, możesz po prostu umieścić go w raporcie. „Zobacz także błąd # 12345.”)