Jak radzić sobie z błędami, które, jak sądzę, naprawiłem, ale nie jestem do końca pewien

13

Istnieje kilka rodzajów błędów, które są bardzo trudne do odtworzenia, zdarzają się bardzo rzadko i na pozór losowo. Może się zdarzyć, że znajdę możliwą przyczynę, naprawię ją, przetestuję program i nie będę mógł odtworzyć błędu. Ponieważ jednak niemożliwe było wiarygodne odtworzenie błędu i zdarzało się to tak rzadko, jak mogę to wskazać w programie do śledzenia błędów? Jaki jest typowy sposób to zrobić?

Gdybym ustawił na statusnaprawiony, a na solutionnaprawiony, oznaczałoby to coś całkowicie naprawionego, prawda?

Czy powszechną praktyką jest ustawianie na statusnaprawione i solutionotwieranie, aby wskazać testerom, że „prawdopodobnie jest naprawiony, ale wymaga więcej uwagi, aby się upewnić”?

Edycja: większość (jeśli nie wszystkie) tropicieli błędów ma dwie właściwości statusu błędu, być może nazwy nie są takie same. statusRozumiem przez to nowy, przypisany, naprawiony, zamknięty itp. , solutionI mam na myśli otwarty (nowy), naprawiony, nierozwiązywalny, nieodtwarzalny, duplikat, nie błąd itp.

testing issue-tracking vsz
źródło
3
Jest to nieco specyficzne dla twojego narzędzia do śledzenia błędów. Jakie inne wartości możesz przypisać do statusu i rozwiązania ?
scarfridge
W niektórych modułach do śledzenia błędów występuje status rozwiązany, a inny status zamknięty. Tylko osoby odpowiedzialne za kontrolę jakości mogą ustawić status na zamknięty, ale programiści mogą ustawić status na rozstrzygnięty.
Brian

Odpowiedzi:

8

Czy powszechną praktyką jest ustawianie statusu na naprawiony i otwieranie rozwiązania, aby wskazać testerom, że „prawdopodobnie jest naprawiony, ale wymaga więcej uwagi, aby się upewnić”?

Zwykle czy nie, tak i tak należy to zrobić, a ty wyjaśniłeś, dlaczego sam: nie ważne jak, jest to dobre podejście do

wskaż testerom, że „prawdopodobnie został naprawiony, ale wymaga więcej uwagi, aby się upewnić”

Uwaga dodatkowa, nawet jeśli określony moduł śledzenia błędów nie ma pola takiego jak opisywane jako solution, programista może przynajmniej dodać komentarz w dowolnej formie wyjaśniający powyżej.

... a jeśli narzędzie do śledzenia błędów nie pozwala na dodawanie komentarzy do problemu, należy je zastąpić takim, który to robi. Możliwość dodawania wyjaśnień w dowolnej formie jest niezwykle ważna, ponieważ problemy różnią się zbyt mocno, aby zmieściły się w określonej z góry formie.

komar
źródło
6

Zespół testowy zdecyduje, czy problem został rozwiązany i czy można go zamknąć. Jeśli wystąpią jakiekolwiek regresje, skutki uboczne poprawki lub jeśli sama poprawka nie działa w innym scenariuszu, problem zostanie ponownie otwarty. Ale jeśli wykonałeś wystarczająco dużo testów dla programistów, lepiej oznaczyć to jako naprawione.

eminemence
źródło
+1 - to najprostsza odpowiedź. Jeśli starałeś się jak najlepiej, a pakiet testowy zespołów testowych jest wystarczająco silny, co więcej możesz zrobić?
ozz
3

Istnieją rodzaje błędów, które są bardzo trudne do odtworzenia, zdarzają się bardzo rzadko i wydają się przypadkowe. Może się zdarzyć, że znajdę możliwą przyczynę, naprawię ją, przetestuję program i nie będę mógł odtworzyć błędu.

W rzeczywistości, jeśli nie ma powtarzalnego scenariusza testowego, nie próbowałbym nawet wcześniej naprawić takiego błędu. Jeśli chcesz, aby tester zwrócił na to większą uwagę, daj im szansę na stworzenie powtarzalnego scenariusza.

Załóżmy na przykład, że zmieniłeś program, a tester poświęca 1 godzinę na próbę odtworzenia błędu, a błąd nie pojawia się - czy wystarczyła jedna godzina? A może dalsze testowanie jest stratą czasu, ponieważ błąd został już naprawiony?

Z drugiej strony, jeśli nie zmienisz programu, a błąd nie pojawi się w ciągu 1 godziny, najprawdopodobniej tester powinien zainwestować kolejną godzinę w wypróbowanie różnych rzeczy. A kiedy tester zainwestuje jeden dzień i nie będzie mógł już odtworzyć błędu - czy naprawdę warto wtedy go naprawić?

Powiedziawszy to, możesz pomyśleć o tym, jak modelujesz ten proces w systemie śledzenia błędów: brak próby naprawy i przekazanie go testerom może mieć status błędu „otwarty”. Jeśli testerzy nie mogą go odtworzyć, jest to oczywiście „nie do odtworzenia”. Mamy nadzieję, że tak się nie dzieje, znajdują powtarzalny scenariusz, możesz znaleźć podstawową przyczynę błędu, naprawić go i ustawić status na „naprawiony”. Staraj się unikać czegoś takiego jak „nie wiem, czy to naprawiono”.

Doktor Brown
źródło
4
W przypadku niektórych typów błędów powtarzalny scenariusz testowy po prostu nie istnieje. Na przykład błąd związany z czasem może zdarzyć się średnio 1 raz na milion - ale nie da się przewidzieć, czy nastąpi on na 3 czy 532454. biegu. Niemniej jednak takie błędy są błędami i muszą zostać naprawione.
Joonas Pulakka
3
@Joonas Pulakka: Zgadzam się. I takie błędy mogą zależeć od okoliczności zewnętrznych. W przypadku wbudowania mogą one zależeć od skoków mocy spowodowanych przez coś poza Twoją kontrolą. Nie próby naprawienia tego nie zawsze jest najlepszym rozwiązaniem, szczególnie jeśli zdarza mi się znaleźć zapach kodu, który, jak podejrzewam, może być przyczyną tego błędu. W takim przypadku dlaczego nie powinienem tego naprawić?
vsz
2
@JoonasPulakka: ku mojemu doświadczeniu na temat powtarzalnych scenariuszy, w większości przypadków, gdy ludzie mówią „nie jest to możliwe”, po prostu brakuje im właściwego pomysłu, aby wszystko było możliwe. W twoim przykładzie można skonfigurować scenariusz z pętlą „10 milionów uruchomień”, co sprawia, że ​​co najmniej bardzo prawdopodobne jest wyświetlenie błędu w rozsądnym czasie.
Dok. Brown
2
@vsz: oczywiście powinieneś to naprawić, ale sugeruję, aby najpierw stworzyć test (lub dać testerom podpowiedź, co przetestować), a następnie naprawić, a nie odwrotnie.
Dok. Brown
2
@DocBrown ma rację, innym sposobem na przemyślenie tego jest to, że czasem błędy wymagają statystycznego podejścia do ich „odtworzenia”. Może się zdarzyć, że istnieje bardzo specyficzny zestaw danych wejściowych / okoliczności, które odtwarzają błąd, ale możesz NIE mieć pojęcia, czym są te dane wejściowe, a zestaw możliwych danych wejściowych może być zbyt duży, aby je powtarzać. W takich przypadkach jednym podejściem jest zbieranie statystyk dotyczących występowania błędu za każdym razem, gdy próbujesz go rozwiązać. Może to zająć dużo czasu, a wyniki mogą nie dać 100% „pewności” w sensie statystycznym, ale czasami to wszystko, co masz.
Angelo
0

Czasami jedynym dowodem, który masz, są czysto statystyczne, np. Pojawia się raz lub dwa razy w miesiącu, ale poza tym pozornie nie ma z tym nic wspólnego. Są to najgorsze rodzaje błędów do zdiagnozowania i rozwiązania, jakie kiedykolwiek spotkałem, ponieważ nie można z całą pewnością stwierdzić, czy wprowadzone poprawki mają wpływ. Ostatni z nich, który musiałem rozwiązać, zakończył się poprawką statystyczną: częstotliwość objawów spadła do 10%, od której zaczęliśmy. Ostatni kawałek nigdy nie został znaleziony, a może był, ale nikt nie miał pojęcia, co powiedzieć.

Dwie porady, które mam (1) zakładają, że wiele przyczyn może obowiązywać, dopóki nie dowiesz się inaczej, oraz (2) hipotezę, w jaki sposób objawy mogą istnieć, a następnie rozerwij każdą linię logiki, która jest nawet zdalnie zaangażowana. Głębokie instrukcje są czasem jedynym sposobem na satysfakcjonujący koniec.

Chris Cochran
źródło