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

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

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.

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.