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
Odpowiedzi:
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.
źródło
... a full description of what they did to cause the bug
. Czym to się różni od repo?The software crashed
vsThe software crashed editing foowidgets
vsThe 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.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):
Tak więc, jak zauważa SteveCzetty: Zamknij go bez repozytorium i wróć do pracy.
źródło
Jeśli błędu nie da się konsekwentnie odtworzyć, to jak QA kiedykolwiek dowie się, czy został naprawiony?
źródło
Tak, powinieneś oczekiwać od nich więcej. Powinni umieć powiedzieć:
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.
źródło
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?
źródło
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.
źródło
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.
źródło
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.
źródło
Raport o błędzie powinien zawierać:
Na przykład:
DELETE * FROM tSuppliers
), otworzyłem okno dialogowe dostawcy i kliknąłem listę rozwijaną Dostawca.GUPOS ERROR #0000000: SOMETHING WENT WRONG!
. Po kliknięciu wiadomości aplikacja zniknęła z ekranu i Menedżera zadań.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.
źródło
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.
źródło
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.
źródło
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ć” :
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.
źródło