Co zrobić z błędami, które nie powodują repro?

Mam testera, który podczas testowania wystąpi błąd (do tej pory ok), ale potem często go zgłasza. My (programiści) stwierdzamy później, że tester nie próbował odtworzyć problemu i (gdy zostanie o to poproszony) nie może znaleźć sposobu, aby to się powtórzyło.

Teraz są to nadal błędy, nie chcę ich ignorować. Ale bez kroków repro utknąłem. Czasami występuje ślad stosu (choć często nie jest to użyteczne, ponieważ jest to zwarta struktura i nie ma numerów linii). Ale kiedy już istnieje, mogę pobrać ślad stosu i otworzyć kod i zacząć zgadywać, ale to nie prowadzi do testowalnych „poprawek”.

Co robisz w takich scenariuszach?

Błąd bez kontekstu nie jest błędem, to fart. Problemem może być twój kod, może to być biblioteka innej firmy, może to być sprzęt lub promieniowanie słoneczne powodujące, że jeden bit sam się odwróci. Jeśli nie możesz odtworzyć go przynajmniej z pewną regularnością (nawet jeśli tylko „zdarza się to raz na 10 lub 20 razy robię X”), nie jest to dużo lepsze niż tester mówiący ci „Coś poszło nie tak - napraw to” .

Być może będziesz musiał wyjaśnić swojemu testerowi, że jego zadaniem nie jest po prostu generowanie danych wejściowych, dopóki coś się nie zepsuje. Gdyby tak było, możesz zastąpić go generatorem liczb losowych. Częścią jego pracy jest identyfikacja błędów, co pociąga za sobą identyfikację sposobu ich zgłaszania.

Ostatecznie, jeśli ani programista, ani tester nie mogą odtworzyć błędu, powinien zostać zamknięty, ale oznaczony jako taki.

Jednak ile czasu zajmuje ci dotarcie do tego punktu, jest dyskusyjne.

Niektórzy twierdzą, że jeśli nie jest to natychmiast powtarzalne, należy je natychmiast zamknąć.

Zwykle staram się uzyskać więcej informacji od autora problemu. Może być coś, o czym zapomnieli w oryginalnym raporcie. Rozmowa na temat wymaganych kroków może często ujawnić brakujące informacje.

Ostatnia myśl - zamknięta jako „no-repro” nie oznacza naprawionej. Jeśli istnieje prawdziwy problem, ujawni się prędzej czy później, a posiadanie wszystkich informacji, które możesz pomóc, pomoże w ostatecznym odtworzeniu problemu.

Kilka innych sugestii:

1. Dodaj rejestrowanie (a nie tylko keylogger:}) do kodu produktu. Błędy „Brak repro” mogą być błędami, ale mogą być uszkodzeniem pamięci lub stanu, które występuje tylko w brudnym systemie używanym w nieoczekiwany sposób (np. Jak komputer klienta). Rejestrowanie lub śledzenie informacji może pomóc w wykryciu, co mogło być nie tak, gdy tester znalazł błąd.

2. Przeskanuj resztę błędów „brak repro” w bazie danych (lub cokolwiek, czego używasz do śledzenia błędów). Często przywry zlepiają się w jednym obszarze produktu. Jeśli wygląda na to, że jeden z komponentów jest uszkodzony, kod przejrzyj ten komponent pod kątem możliwej niestabilności, dodaj dodatkowe rejestrowanie do tego komponentu - lub obu.

3. Poświęć około pół godziny i obejrzyj test testera. Ich podejście może dać ci wyobrażenie o tym, co poszło nie tak (np. „Ciekawe - nie wiedziałem, że możesz przejść do tego dialogu”). Może się również okazać, że przypadkowo pomijają okno dialogowe lub krok konfiguracji. Warto zainwestować trochę czasu w głowę.

Robię kontrolę jakości dużego komercyjnego kodu, ten irytujący scenariusz pojawia się zbyt często. Zazwyczaj oznacza to, że nie ma żadnych żelaznych dochodów na budowę pliku binarnego na wszystkich obsługiwanych przez nas platformach. Więc jeśli programista zbuduje swój własny kod (który musi zrobić, aby debugować i naprawić) i nie wykona tej samej procedury kompilacji do litery, istnieje szansa, że ​​błędy zależne od systemu pojawią się magicznie (lub pojawią się) . Oczywiście te rzeczy zwykle zamykają się z „działa dla mnie” w bazie danych błędów, a jeśli zawiodą przy następnym uruchomieniu problemu, błąd można ponownie otworzyć. Ilekroć podejrzewam, że błąd może zależeć od systemu, próbuję go przetestować na różnych platformach i zgłosić, w jakich warunkach to się dzieje. Często problem uszkodzenia pamięci pojawia się tylko wtedy, gdy uszkodzone dane są wystarczająco duże, aby spowodować awarię. Niektóre platformy (kombinacje HW i OS) mogą upaść bliżej rzeczywistego źródła uszkodzenia, a to może być bardzo cenne dla biednego faceta, który musi go debugować.

Tester musi osiągnąć pewną wartość dodaną, wykraczającą poza zwykłe zgłaszanie awarii w swoim systemie. Spędzam dużo czasu szukając fałszywych alarmów - być może platforma, o której mowa, jest przeciążona lub sieć ma usterkę. I tak, czasami można uzyskać coś, na co naprawdę wpływają losowe zdarzenia czasowe, błędy sprzętowe mogą często przypominać proto przykład: jeśli dwa żądania danych powrócą dokładnie w tym samym okresie zegara, a logika sprzętowa do obsługi potencjalnego konfliktu jest wadliwa, wtedy błąd będzie pojawiał się tylko sporadycznie. Podobnie w przypadku przetwarzania równoległego, chyba że przez staranne zaprojektowanie rozwiązania będziesz niezależny od tego, który procesor okazał się szybszy, możesz dostać błędy, które zdarzają się tylko raz na niebieskim księżycu, a ich statystyczna nieporozumliwość czyni debugowanie koszmarem.

Również nasz kod jest aktualizowany, zwykle wiele razy dziennie, śledząc dokładny numer wersji kodu źródłowego, ponieważ kiedy poszedł na południe, może być bardzo użyteczną informacją do debugowania. Tester nie powinien pozostawać w kontrowersyjnej relacji z debuggerami i programistami, ponieważ jest częścią zespołu, który poprawia jakość produktu.

Istnieją dwa rodzaje błędów, których nie można odtworzyć:

1) Te, które tester (lub użytkownik) widział raz, ale albo nie był w stanie, ani nie próbował się odtworzyć.

W takich sytuacjach powinieneś:

• Bardzo krótko sprawdź podstawowy przebieg działań, które wykazały wadę, aby upewnić się, że nie jest odtwarzalna.

• Porozmawiaj z testerem / użytkownikiem, aby sprawdzić, czy są jakieś inne informacje, które mogą pomóc.

• Porównaj je z wszelkimi innymi defektami, które mogą być powiązane, aby sprawdzić, czy masz wystarczającą ilość informacji, aby je przejrzeć na podstawie wielu instancji. Może się okazać, że ten jeden problem nie zapewnia wystarczającej ilości informacji, ale w połączeniu z wieloma innymi zagadnieniami może sugerować coś niewłaściwego, co warto zbadać.

• Jeśli nadal nie masz dość, musisz wyjaśnić użytkownikowi / testerowi, że nie masz wystarczającej ilości informacji. Nakreśl im grzecznie, jak powinna wyglądać wystarczająca ilość informacji i dlaczego jest potrzebna.

2) Te, w których nie można ich w wiarygodny sposób odtworzyć, jednak istnieje wystarczający dowód (pod względem powtarzających się przypadków), aby zasugerować, że wada istnieje, to widzę, że są to problemy dewelopera i deweloper - wspierany przez testera / user - musi zbadać.

To może być powolne i bolesne, prawdopodobnie będziesz musiał przejść kod, dodać więcej rejestrowania, spojrzeć na dane i porozmawiać z testerami / użytkownikami dogłębnie, ale jeśli istnieje wystarczająca ilość dowodów, które sugerują, że istnieje to problem, który musisz przejąć na własność i zrobić wszystko, co trzeba, aby to naprawić.

Wygląda na to, że zdarza się to stosunkowo często - co mnie zastanawia, czy to dlatego, że większość błędów jest naprawdę trudna do naprawienia, czy też z jakiegoś innego powodu nie próbuje? Czy wiesz, dlaczego nie próbuje odtworzyć problemu? Czy to dlatego, że nie zdaje sobie sprawy, jak ważne jest to dla ciebie? A może jest tak, że wywiera on inne naciski - na przykład kierownik testów, który chce tylko, aby szybko przeszedł przez przydzielone testy i wyrzucił błędy na ścianę? A może po prostu nie jest pewien, jak sobie z tym poradzić?

Zgadzam się z innymi, że praca nad lepszym logowaniem jest priorytetem. W międzyczasie, jeśli podejrzewasz, że problemem może być brak umiejętności / pewności siebie testera, naprawdę podoba mi się ten artykuł Danny'ego Faught'a na temat izolowania błędów - na początek możesz go na to wskazać.

Jeśli problem wynika z presji kierownictwa - masz moje sympatie, ponieważ jest to trudne do złamania, zwłaszcza jeśli testerzy i programiści zgłaszają się do różnych menedżerów, a menedżerowie nie są skłonni „pomagać” innemu zespołowi.

Zazwyczaj zauważam, że nie jest to powtarzalne, ale pozostaw to otwarte, dopóki partia testów lub iteracja nie zostanie zakończona.

Jeśli do tego momentu nie został odtworzony, jest zamknięty, ale można go ponownie otworzyć, jeśli zostanie ponownie napotkany.

naklej keylogger na stację roboczą testera!

Cóż, pierwszym zadaniem jest mieć powtarzalny system testowy. Twój tester musi mieć dobrze zdefiniowany proces - w miarę możliwości automatyczny.

Spełnij te trzy warunki:

• Ten sam plik binarny
• Te same kroki
• Ta sama maszyna

Jeśli błąd pojawia się sporadycznie przy powyższych 3 warunkach, zacznij się dalej izolować. Rozważ każdy poziom stosu systemu i jego konfigurację.

Jednym ze sposobów wykrycia błędów zarządzania pamięcią jest uruchomienie programu na wielu systemach operacyjnych z wieloma kompilatorami. Valgrind może również pomóc.

Jednak zwykle systemy równoległe mogą powodować błędy niezwiązane z repro. Rzeczy takie jak rozmiary buforów i prędkości przetwarzania, asynchronizacja, blokady bazy danych, przeplatanie zapisu zmiennej pamięci; wszystkie z nich mogą generować problemy. I tak dalej i tak dalej.

Przede wszystkim powinieneś przejść rygorystyczną procedurę testową (ale rozumiem cię, w mojej firmie to, co opisałeś, zdarza się często).

W zależności od powagi błędu możesz poświęcić mu trochę czasu lub (lepiej) zignorować go, dopóki nie zostaną wykonane kroki repro.