Czy kontrola jakości powinna znaleźć powtarzalne scenariusze?

10

Czasami mój zespół kontroli jakości zgłasza błędy, ale ani ja, ani oni nie mamy pojęcia, jak je odtworzyć. Prowadzi to do bardzo długich i frustrujących sesji debugowania, które czasem nawet nie przynoszą rezultatów.

Moje oprogramowanie jest mocno powiązane z zastrzeżonym sprzętem, więc błędy mogą pochodzić z wielu kierunków jednocześnie.

Czy powinienem oczekiwać od nich więcej niż „Twoje oprogramowanie uległo awarii po naciśnięciu przycisku”, czy powinienem sam sobie wyobrazić, co się stało?

EDYTOWAĆ:

Jeden z moich współpracowników zauważył, że prawdopodobnie wszyscy jesteśmy tutaj programistami, więc wyniki mogą być nieco niepoprawne

Eric
źródło
1
To naprawdę nie jest odpowiedź, ale warto zauważyć, że umieszczając (więcej) logowanie w aplikacji, możesz nieco zmniejszyć ten problem. Być może twoja wersja testowa mogłaby być ustawiona na tryb pełnego rejestrowania, który dałby ci niejasne kroki odtwarzania, aby pomóc ci w sesjach debugowania?
ChrisFletcher
Nie bardzo, Testowanie powinno to robić. Kontrola jakości powinna polegać na kontroli jakości.
mattnz
1
Zastanów się nad dodaniem do produktu logiki, która pomoże ci odtworzyć kroki podjęte przez użytkownika, i mieć przycisk kontroli jakości, który pozwala zgłaszającemu błąd na łatwe wydobycie wspomnianych informacji z twojego produktu i dodanie ich do raportu o błędzie.
Przynajmniej zrzut ekranu z rzeczywistej sytuacji pomógłby w większości przypadków odtworzyć błąd. (patrz komentarz dotyczący logowania powyżej). Usersnap to narzędzie do lepszego zgłaszania błędów i oszczędzania czasu komunikacji.
Gregor

Odpowiedzi:

31

Kontrola jakości powinna zawsze starać się, aby błędy były jak najłatwiejsze do odtworzenia, a opis błędu powinien zawierać podjęte kroki.

Jeśli jednak nie mogą łatwo odtworzyć błędów, nadal powinni wejść do bazy danych błędów z odpowiednim tytułem / nagłówkami i pełnym opisem tego, co zrobili, aby spowodować błąd. Opis błędu powinien jasno stwierdzać, że nie mogą go odtworzyć (być może z komentarzem w stylu „wypróbowałem to pięć razy, zdarzyło się to raz”). W ten sposób, jeśli ktoś inny zobaczy ten sam błąd, może dodać do bazy danych błędów wraz ze swoimi odkryciami, a także uzyskać jak najwięcej informacji, które w dalszej części linii mogą być niezbędne w oszczędzaniu czasu na śledzenie problemu.

Ponadto możesz filtrować informacje - może istnieć wiele błędów w różnych systemach, o których wiesz, że wszystkie są powiązane z (np.) Jednym obszarem kodu - jeśli QA nic nie zgłasza (ponieważ nie mogą ich odtworzyć) ), to ta informacja nie dotrze do Ciebie.

PhillC
źródło
... a full description of what they did to cause the bug. Czym to się różni od repo?
Steven Evers
13
@SnOrfus: Repozytoria są z definicji odtwarzalne. Jeśli znajdziesz błąd, ale nie będziesz mógł go później odtworzyć, nadal warto wiedzieć, co robiłeś w tym czasie, aby pomóc nam ustalić, co go spowodowało.
BlueRaja - Danny Pflughoeft
3
@SnOrfus: The software crashedvs The software crashed editing foowidgetsvs The software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached). Ostatni szczegół może nie być oczywisty, ale z pewnością pomocny jest drugi opis zamiast pierwszego.
Daenyth
@Daenyth: Wystarczająco sprawiedliwe. Może wchodzę zbyt daleko w semantykę pełnego opisu.
Steven Evers
Upewnij się, że „Closed Did / Could not reprodukcji” jest dostępne (tam i dopuszczalne) do użycia w twoim narzędziu do śledzenia defektów.
mattnz
13

Wygląda na to, że Twój dział kontroli jakości przeprowadza zbyt wiele badań eksploracyjnych (tj. Nie ma dobrego planu testów).

Testy eksploracyjne są dobre i identyfikują obszary problemowe, ale stamtąd powinny definiować odtwarzalne przypadki testowe (tj. Plan testów) do wykonania, które ujawnią określone błędy.

Istnieje wiele powodów, dla których konieczne jest poprawne repro (nie tylko dobre, ale konieczne):

  1. Musisz wykonać repro, aby móc debugować / wyśledzić przyczynę.
  2. Kontrola jakości będzie musiała być w stanie zweryfikować poprawkę po zakończeniu.
  3. Dalsze testy będą wymagały regresji poprzednich błędów.
  4. Znane błędy można odrzucić, jeśli narażenie jest zbyt małe lub jest zbyt mało prawdopodobne.

Tak więc, jak zauważa SteveCzetty: Zamknij go bez repozytorium i wróć do pracy.

Steven Evers
źródło
3
Problem z krokami do odtworzenia polega na tym, że zwykle w przypadku błędów Crash nie są one spodziewane ani oczekiwane i zwykle zdarzają się w trakcie planu testowego. Powinni spróbować go odtworzyć, ale wiele razy jest to niedoskonałe. Do ręcznego testowania dobre oprogramowanie do nagrywania ekranu pulpitu podczas testów może rejestrować każdy krok i znacznik czasu, który doprowadził do awarii, a także rejestrować wszelkie proste błędy lub pozornie nieistotne szczegóły, które osoba kontroli jakości mogła pominąć w swoich krokach do odtworzenia. Dzięki temu i dziennikom testów programista powinien mieć wyraźniejszy obraz.
wałek klonowy
3
@maple_shaft To jest rzeczywiście prawda - nie oczekuję, że każdy błąd z kontroli jakości będzie w 100% odtwarzalny. Nagrywanie ekranu jest interesującą opcją i zdecydowanie wymaga większej uwagi, ponieważ pozwala na większą elastyczność bez rezygnacji z możliwości obserwowania przez ramię testera.
Michael K
2
@maple_shaft: Zgadzam się, a MTM ma to wbudowane. Jednak w tym przypadku istnieje znacząca różnica między tym, co dostaje Eric („Nastąpiła awaria”), a najlepszym scenariuszem (Dzienniki zdarzeń + Dzienniki aplikacji + Wideo + Nagrywanie akcji + Intellitrace + Repozytorium szczegółowe). Zadanie IMO / E QA nie kończy się, gdy pojawia się niebieski ekran - a repro to pierwsza rzecz, którą powinni spróbować wyprodukować, nawet jeśli nie zawsze jest to wykonalne.
Steven Evers
@SnOrfus Mógłbym tylko marzyć o pracy z tak profesjonalnym zespołem ds. Kontroli jakości. W większości organizacji, w których pracowałem, byli oni oszołomami, którzy byli zbyt niekompetentni lub leniwi, aby wyciąć je jako twórcy oprogramowania. Zaskakująco najlepszy zespół ds. Kontroli jakości, z którym współpracowałem, był całkowicie offshorowany, prawdopodobnie dlatego, że tak naprawdę chce przeprowadzać testy jakości.
wałek klonowy
@maple_shaft: Tam, gdzie pracuję, zanim przeniosłem się z QA do Dev, robiliśmy już większość tego (wideo zajmuje crapload miejsca na dysku twardym, gdy masz 400000 przypadków testowych).
Steven Evers
7

Jeśli błędu nie da się konsekwentnie odtworzyć, to jak QA kiedykolwiek dowie się, czy został naprawiony?

Kyralessa
źródło
Tak, to kolejny problem, o którym nie wspomniałem, ale często go spotkałem. Otrzymuję raport o błędzie, dokonuję zmian, a następnie zamykam błąd. Kontrola jakości zatwierdza zakończenie. Kilka tygodni później problem zostanie ponownie otwarty, ponieważ nie został rozwiązany. Mam też wiele problemów, ponieważ „oprogramowanie uległo awarii”, które stają się wielką tyglą każdego możliwego błędu
Eric
6

Tak, powinieneś oczekiwać od nich więcej. Powinni umieć powiedzieć:

1. Uruchomiono nową instancję programu
2. Nacisnąłem przycisk A
3. Wprowadzono „tekst testowy” w polu NAZWA TESTU na formularzu nr 1
4. Wciśnięty przycisk B
5. Zauważył, że program zawiesił się z tym komunikatem (patrz załączony zrzut ekranu).

Jeśli wszystko, co mówią, to „rozbił się”, nie są zbyt dobrzy. Nawet jeśli powyższe kroki nie są w 100% odtwarzalne, wystarczająco duża próbka tych awarii może pomóc w zawężeniu przyczyny, po wykryciu wzorca.

FrustratedWithFormsDesigner
źródło
5

Radzę przeczytać te błędy i dać im dobrą starą myśl. Jeśli nie możesz znaleźć potencjalnej przyczyny, na razie zapomnij o nich.

Kontrola jakości powinna dokumentować każdy znaleziony problem, nawet jeśli nie mają pojęcia, jak to się stało. Zadaniem QA jest próba odtworzenia problemów, ale realistycznie nie zawsze będzie to możliwe. Czasami nie ma to nic wspólnego z tym, co zrobili w ciągu ostatnich 10 minut. Coś wpadło w stan nieprawidłowy dzień temu, a stało się to widoczne z powodu jednego z ostatnich 10 kroków.

W przypadku tych błędów „1 na 1000” QA powinna spróbować je trochę odtworzyć. Jeśli nie odniosą sukcesu, powinni udokumentować błąd, a następnie spróbować trochę więcej.

Powodem, dla którego powinni wprowadzić błąd dość wcześnie, jest to, że programista zna kod znacznie lepiej niż QA i może natychmiast znać problem. Może to być kod, który zmienili. Może to być funkcja, którą w połowie zaimplementowali, a następnie zapomnieli. Mogą nie mieć pojęcia, ale tester nie ma sensu tracić kilku godzin na próbę odtworzenia problemu oczywistego dla osoby, która go kodowała. Tester zawsze może później dodać więcej szczegółów do błędu.

Błąd powinien zawierać jak najwięcej informacji. Wszystko, co tester pamięta o wstępie do problemu, należy zapisać w bolesny sposób. Należy także dołączyć wszelkie dzienniki awarii, migawki bazy danych lub odpowiednie zrzuty ekranu.

Jeśli błąd nigdy nie zostanie odtworzony, świetnie! Nie zaszkodzi mieć go w bazie danych. Jeśli program zostanie wydany, a użytkownik zgłosi podobny błąd później, możesz porównać jego wrażenia z treścią raportu i poszukać podobieństw.

Z mojego doświadczenia wynika, że ​​najbardziej soczyste błędy nie zostały znalezione na podstawie planów testowych. Czasami musisz pozwolić, by wszystko dusiło się przez kilka tygodni, aby księżyc i gwiazdy zrównały się, co spowodowało paskudny błąd. Jeśli QA może wykonać jakąś pracę detektywistyczną i znaleźć jakieś możliwe przyczyny, poklep ich po plecach. Ale czasami kto wie, co się stało?

Dziekan
źródło
+1 za „Nie szkodzi, że ma się to w bazie danych”
PhillC
4

Wiele błędów nie jest powtarzalnych, dopóki nie wiesz, jak je naprawić. To nie znaczy, że nie trzeba ich naprawiać. W zeszłym roku naprawiłem błąd, który wciąż nie wiem, jak się rozmnażać. Wymaga to dziwnej kombinacji błędu transmisji o ściśle określonym czasie z bardzo konkretnymi danymi śmieci w pewnej lokalizacji pamięci na stosie. Niestety, jeden z naszych klientów ma „szczęście”, aby cały czas znaleźć się w tym stanie.

Tak więc zdecydowanie zachęcaj QA do uwzględnienia etapów odtwarzalności tam, gdzie to możliwe, ale nie obwiniaj ich, jeśli nie mogą. Czasami pomoże ci wiedzieć, gdzie dodać rejestrowanie. Czasami wszystko, co robi, to mówienie, co nie powoduje błędu, ale raport o błędzie jest zawsze przydatny.

Karl Bielefeldt
źródło
2

Jeśli masz na myśli, czy kontrola jakości powinna zawierać kroki, aby odtworzyć błąd, jeśli mogą, to odpowiedź brzmi tak. Jeśli masz na myśli, że powinni rejestrować tylko błędy, które są w stanie odtworzyć, to absolutnie nie. Błędy to błędy, niezależnie od tego, czy zdarzają się tylko o północy w pełni księżyca, czy za każdym razem, gdy na nie patrzysz. Niektóre błędy są niedeterministyczne (klasyczny przykład to niezainicjowana zmienna, w której pobrana wartość jest częściowo losowa), co nie oznacza, że ​​nie powinny być rejestrowane, badane, a jeśli to możliwe, naprawione.

Niepowtarzalne błędy powinny mieć ogólnie niski priorytet, ale zdecydowanie powinny zostać zarejestrowane.

jmoreno
źródło
1

IMO, powinieneś. QA nie wykonują swojej pracy, jeśli nie mogą dać ci żadnych kroków reprodukcyjnych. Nie marnuj czasu na próby odtworzenia czegoś, czego nie możesz, po prostu zamknij go jako „Nie można odtworzyć” i przejdź dalej.

Twój czas jest o wiele cenniejszy.

Steve Czetty
źródło
1

Raport o błędzie powinien zawierać:

  • kroki ku reprodukcji
  • Rzeczywiste zachowanie
  • Oczekiwane zachowanie

Na przykład:

  • Usunąłem wszystkich dostawców z bazy danych (za pomocą DELETE * FROM tSuppliers), otworzyłem okno dialogowe dostawcy i kliknąłem listę rozwijaną Dostawca.
  • Wykaz zawarty jest następujący komunikat: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Po kliknięciu wiadomości aplikacja zniknęła z ekranu i Menedżera zadań.
  • Spodziewałem się zobaczyć pustą listę lub (najlepiej) komunikat typu „Nie znaleziono dostawców”. Kliknięcie pustej listy lub wiadomości nie powinno mieć żadnego efektu. Aplikacja oczywiście nie powinna zniknąć bez ostrzeżenia w żadnych okolicznościach.

Tak, tak - powinien zawierać kroki do odtworzenia. Fakt, że nie czują potrzeby uwzględnienia tego, zdaje się wskazywać, że ich zdaniem ich zadaniem jest „złamanie oprogramowania”, a nie identyfikacja błędów.

gkrogers
źródło
0

Kontrola jakości powinna być w stanie odtworzyć błędy na podstawie wprowadzonych kroków. Jeśli bardzo się starali, nadal nie byli w stanie się odtworzyć, powinni nadal wprowadzać błędy z taką samą liczbą szczegółów, jakie mają ze znacznikiem czasu, aby programiści mogli zapoznać się z aplikacją i dziennikami debugowania, aby uzyskać więcej szczegółów.

java_mouse
źródło
0

Stawką są tutaj pieniądze. Dlaczego którykolwiek członek zespołu powinien być w stanie stworzyć źle zdefiniowane, mało prawdopodobne, zadanie, które obciąża (miejmy nadzieję) wysoko opłacanego programistę?

Tu nie chodzi o porządkowanie dziobania, hierarchię, arogancję, nas kontra im, ani nic podobnego. Chodzi tylko o inwestowanie w działania, które zwiększają wartość produktu.

Kiedy można wykazać, że problem negatywnie i mierzalnie wpływa na wartość produktu, należy go zbadać, powielić i naprawić. Napraw rurociąg wadliwych produktów, aby odfiltrować hałas.

szczerze
źródło
-1

Twój zespół kontroli jakości jest do bani

Idź do nich i powiedz im, aby przeczytali dokument, który każdy profesjonalny tester musi wydrukować bezpośrednio w ich mózgach (byłem kiedyś testerem i nadal mam go tam w głowie): Jak skutecznie zgłaszać błędy .

W szczególności skieruj je do sekcji „Pokaż, jak się pokazać” :

To era Internetu. To era globalnej komunikacji. To era, w której mogę wysłać moje oprogramowanie do kogoś w Rosji za naciśnięciem jednego przycisku, a on może mi równie łatwo przesłać mi uwagi na jego temat. Ale jeśli ma problem z moim programem, nie może sprawić, żebym stał przed nim, dopóki się nie powiedzie. „Pokaż” jest dobre, kiedy możesz, ale często nie możesz.

Jeśli musisz zgłosić błąd programistowi, który nie może być obecny osobiście, celem tego ćwiczenia jest umożliwienie mu odtworzenia problemu. Chcesz, aby programista uruchomił własną kopię programu, zrobił to samo i sprawił, że zawiódł w ten sam sposób. Kiedy widzą problem na ich oczach, mogą sobie z tym poradzić ...


Jeśli zaczną krzyczeć na ciebie narzekając, że „robaki mogą pochodzić z wielu kierunków jednocześnie” , powiedz im, że ssą nawet więcej niż myślałeś wcześniej. Powiedz im, że Testowalność jest cechą, którą powinni ocenić pośród innych cech projektu i powinni włożyć wysiłki w poprawienie tej funkcji.

  • Ulepszenia testowalności, które można uzyskać, gdy skupi się na tym profesjonalny tester, mogą przypominać magię. Nauczyłem się tego kilka miesięcy temu. Inżynier ds. Kontroli jakości współpracujący z naszym zespołem dał mi garść próśb dotyczących testowania, które należało opracować dla niektórych komponentów naszej aplikacji. Rzeczy, o które pytał, nie miały dla mnie większego sensu, ale dałem mu to, zakładając, że wie lepiej jako profesjonalista. Wkrótce po tym, jak skończyłem, wymyślił narzędzie, które zmniejszało wysiłki testowe o rząd wielkości . Powiedział, że większość z nich była oparta na tych tajemniczych żądaniach, które zrealizowałem.
komar
źródło