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 a
to 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.
Odpowiedzi:
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:
Utworzenie rekordu informującego o istnieniu błędu zawierającego informacje o sposobie jego odtworzenia,
Potwierdzając, że rzeczywiście, błąd istnieje i jest błędem, a nie czymś z założenia,
Zapewniając, że błąd został już rozwiązany,
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:
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:
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.
źródło
Aby skomentować twoje oświadczenie:
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:
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.
źródło
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:
Robiąc to, powinien zmaksymalizować następujące pożądane cechy:
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:
Każda ważna wada może zostać rozwiązana lub nierozwiązana bez dwuznaczności.
Niezależnie odtwarzalne wady należy śledzić niezależnie.
źródło
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.”)
źródło
B
wtedy?