Skłanianie użytkowników do pisania przyzwoitych i przydatnych raportów o błędach

32

Czy ktoś zna dobry sposób na nakłonienie użytkowników do napisania pół przyzwoitego (czytaj: przydatnego ) raportu o błędzie ?

Chcieliśmy stworzyć coś, co miałoby sens dla większości użytkowników (aby było łatwe do odczytania i zrozumienia), a jednocześnie dawało przydatne informacje również programistom.

To nie działa, kiedy kliknę niebieski przycisk! Ahhh, właśnie straciłem tydzień pracy ... spraw, żeby działała.

nie jest bardzo przydatne, ponieważ jest.

Zacząłem naprawiać listę, ale zastanawiałem się, czy podobna metoda już istnieje.

client-relations bug-report

— Wieża
źródło

2

Mogłem zrozumieć głosowanie za zamknięciem programistów, ale nie na temat? Zgłoszenia błędów na stronie programisty ?!

— Rook

1

Czy to ma znaczenie? I tak będą pisać złe raporty o błędach. Zwykle musisz jakoś komunikować się z użytkownikami.

— David Thornley,

@DavidThornley - Jesteśmy w specyficznej branży. Z większością użytkowników nigdy się nie komunikuję ani nie otrzymuję tych raportów kilka miesięcy później. Nie pytaj

— Wież

3

Zbuduj mechanizm raportowania w swojej aplikacji, aby użytkownik mógł kliknąć przycisk, dodać komentarz i przypisać odpowiedni stan aplikacji. „Teraz kliknij lokalizację na ekranie, w której jest ona niepoprawna” ...

3

Daj mi znać, jeśli znajdziesz odpowiedź. Mam dość problemów z otrzymywaniem przydatnych raportów o błędach od testerów, nie wspominając o użytkownikach.

— Kristof Provost

16

Najbardziej skutecznym sposobem na zachęcenie użytkowników do pisania przyzwoitych i przydatnych raportów o błędach jest

aby mogli zobaczyć swoje raporty online ...
^{[System] Dziękujemy za zgłoszenie, możesz znaleźć status swojego żądania tutaj: ...}
... wraz z oceną i komentarzami przypisanego inżyniera ...
^{[Inżynier] Żądanie odrzucone, ponieważ brakuje następujących szczegółów: ...}
... z opcją edycji / ulepszenia raportu.
^{[Użytkownik] Żądane szczegóły zostały dodane, proszę ponownie ocenić: ...}

Posunąłbym się nawet do stwierdzenia, że jest to jedyny skuteczny sposób.

Spójrzmy prawdzie w oczy, umiejętność skutecznego pisania raportów o błędach pochodzi tylko z doświadczeniem. Trzeba nauczyć się zdobywać doświadczenie. Uczenie się polega na ćwiczeniu, uzyskiwaniu informacji zwrotnych i doskonaleniu.

Raporty o błędach online, które można edytować przez użytkownika, są najbardziej wydajnym sposobem na nauczenie użytkowników, jak poprawić .

^{Alternatywnymi opcjami powyżej są 1), aby zorganizować sesje uczenia się twarzą w twarz z użytkownikami (tak, szczególnie, gdy na całym świecie są ich tysiące). Lub 2) wyjaśnij im rzeczy przez telefon („spójrz, jeśli zobaczysz tylko bzdury, które napisałeś na linii 225 ...”). Co jeszcze? Och 3) przez e-mail, pewnie "w mailu, który przesłałeś nam dwa miesiące temu, wspomniałeś ... nie, nie ten e-mail, wysłałeś nam pięć e-maili tego dnia, trzy z nich dotyczyły tematu Re: kliknij niebieski przycisk , spójrz na drugi, ten z dołączonym zrzutem ekranu 10 Mb ... czego? nie możesz go znaleźć? "}

— komar
źródło

27

Moim zdaniem, ważniejsze jest użycie błędu w celu ustalenia sensownego kontaktu z użytkownikiem. Pisanie i rozumienie zgłoszeń błędów to umiejętność, a moją radą powinno być ułatwienie użytkownikowi pierwszego kontaktu, a następnie stopniowe przekazywanie opinii o większej wartości w razie potrzeby.

Na przykład, po prostu pobierz adres e-mail użytkownika i podaj mu zwykły tekst z następującym tekstem do wypełnienia:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Po otrzymaniu wiadomości e-mail wykonaj automatyczną odpowiedź, aby uzyskać podwójne potwierdzenie, że przesłali błąd, otrzymałeś go, a dalsze działania w sprawie błędu są w porządku.

— błędy
źródło

2

Świetna odpowiedź. Zwięzły i komunikatywny. Zamierzam to przekierować, aby wyjaśnić ludziom.

— Erik Dietrich,

Powinien to być również szablon, od którego zaczynają się pytania SO.

— Cody Piersall,

5

Zrobiłem Naciśnij niebieski przycisk , a oczekiwano rzeczy do pracy , ale nic się zamiast. : D

— Songo,

„Zrobiłem _____ i spodziewałem się ______, ale zamiast tego ______.” Korzystałem z oprogramowania ______ wersja _____ w środowisku produkcyjnym / qa / testowym.

— kubańczyk

10

Możesz rozważyć skorzystanie z pomysłów Mozilli i Sun na ten temat:

Wskazówki dotyczące pisania błędów - artykuł Mozilla MDN
Jak napisać odpowiedni błąd - artykuł Mozilla QMO
Jak napisać pomocny raport o błędzie - artykuł Sun SDN

W szczególności (ze strony Mozilli „Jak napisać poprawny błąd”):

Ogólny zarys raportu o błędzie

Podsumowanie : Jak opisałbyś błąd w mniej niż 60 znakach? Powinien szybko i jednoznacznie zidentyfikować raport o błędzie, a także wyjaśnić problem, a nie sugerowane rozwiązanie.

Dobrze : „Anulowanie okna dialogowego kopiowania pliku powoduje awarię Menedżera plików”

Źle : „Awarie oprogramowania”

Źle : „Przeglądarka powinna działać z moją witryną”

Składnik : w której części oprogramowania istnieje? To pole jest wymagane do przesłania raportu o błędzie. Kliknij słowo „Komponent”, aby zobaczyć opis każdego komponentu. Jeśli żadne nie wydaje się odpowiednie, zaznacz element „Ogólne”.

System operacyjny : w którym systemie operacyjnym (OS) go znalazłeś? (np. Linux, Windows XP, Mac OS X.) Przykład: „Jeśli wiesz, że błąd występuje w więcej niż jednym typie systemu operacyjnego, wybierz„ Wszystkie ”. Jeśli twojego systemu operacyjnego nie ma na liście, wybierz Inne ”.

Opis : szczegóły raportu o problemie, w tym:

- Przegląd : Jest to bardziej szczegółowe przekształcenie podsumowania. Przykładem może być: „Przeciągnięcie zaznaczenia dowolnej strony powoduje awarię kompilacji Maca w funkcji NSGetFactory”.

- Identyfikator kompilacji : Aby to znaleźć, przejdź do strony „about:” za pomocą paska lokalizacji lub, jeśli masz rozszerzenie Nightly Tester Tools MozQA, przejdź do Narzędzia | Nightly Tester Tools i wybierz opcję zawierającą dane wyjściowe identyfikatora kompilacji. Powinno to wyglądać mniej więcej tak: „Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Dodatkowe kompilacje i platformy : czy błąd występuje na innych platformach (lub przeglądarkach, jeśli dotyczy). Powinno to wyglądać mniej więcej tak: „Nie występuje w Mozilli / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Kroki do odtworzenia : zminimalizowane, łatwe do wykonania kroki, które spowodują błąd. Jeśli są konieczne, koniecznie dołącz specjalne kroki konfiguracji. Dobry przykład może wyglądać następująco: 1) Wyświetl dowolną stronę internetową. (Użyłem domyślnej przykładowej strony, http://www.google.com/ ). 2) Przeciągnij i wybierz stronę. W szczególności, przytrzymując przycisk myszy, przeciągnij wskaźnik myszy w dół z dowolnego punktu w obszarze zawartości przeglądarki na dół obszaru zawartości przeglądarki.

Rzeczywiste wyniki : Co zrobiła aplikacja po wykonaniu powyższych kroków. Przykładem może być: aplikacja uległa awarii.

Oczekiwane wyniki : To, co aplikacja powinna była zrobić, gdyby błąd nie był obecny. Przykładem może być: okno powinno przewijać się w dół. Należy przewijać zawartość. A przynajmniej aplikacja nie powinna ulec awarii.

— Brian Snow
źródło

10

Naprawdę nie rozumiem, dlaczego uzyskało tak wiele głosów. Pytanie nie brzmi „jak napisać porządny raport o błędzie?” ale „jak zachęcić użytkowników do napisania przyzwoitego raportu o błędzie”.

— Tamás Szelei

8

Zasoby te są w większości skierowane do osób technicznych. Również Mozilla jest organizacją, która przyniosła nam Bugzillę. Nie mówię, że Bugzilla jest zły, ale to zostało wykonane przez inżynierów dla inżynierów: To naprawdę nie jest narzędziem dla użytkowników końcowych w ogóle .

— Joachim Sauer

3

Muszę się zgodzić z @fish. Możemy przekazać naszym testerom wszystkie wytyczne na świecie - nie oznacza to, że faktycznie generują przydatne raporty o błędach. I mówię o ludziach, których zadaniem jest zgłaszanie błędów - jeśli nie możemy motywować ich wytycznymi, nie mamy żadnej nadziei z rzeczywistymi użytkownikami. Jedyne, co okazało się skuteczne, to aktywne zamykanie „bezużytecznych” raportów o błędach jako „niewystarczających informacji” - wtedy dostali wiadomość dość szybko. Nie polecam tego jednak użytkownikom zewnętrznym :-)

— HappyCat

3

W ogóle nie dyskutuję o przydatności tego wpisu (naprawdę dobre zasoby), ale to nie odpowiada na pytanie i myślę, że polityka głosowania opiera się na tym (mogę się mylić).

— Tamás Szelei

1

Jestem osobą, do której to było skierowane i nawet ja nie mogłem usiąść czytając tego wszystkiego. Co sprawia, że myślisz, że użytkownicy zamierzają?

— Tacroy

4

Jest Jak zgłaszać błędy Skutecznie Simon Tatham. To ładnie wyjaśnia rzeczy, aby ułatwić zrozumienie dla mniej doświadczonych użytkowników. Minusem jest jednak to, że jest to całkiem sporo tekstu. Gdy użytkownik próbuje zgłosić problem, ale go nie wyjaśnia, zazwyczaj nie będzie w stanie go przekonać do przeczytania tego wszystkiego.

— Władimir Palant
źródło

4

Możesz zadać użytkownikom łatwe do zrozumienia i odpowiedzi na pytania, oczekując użytecznych raportów.

Na przykład: „Jakie było Twoje ostatnie działanie przed tym błędem?”, „Czy próbowałeś ... tuż przed tym błędem?”.

Żaden użytkownik nie napisałby Ci raportu o błędzie, takiego jak: „Mój sterownik wideo nie jest zaktualizowany. Twoja biblioteka grafiki może nie być kompatybilna ze starymi sterownikami graficznymi”.

— Mert Akcakaya
źródło

3

Zakładając, że bazą użytkowników są użytkownicy końcowi, którzy mieli problem z oprogramowaniem, które napisaliście ....

Nie jest zadaniem twoich użytkowników stanie się biegłym inżynierem oprogramowania lub specjalistą ds. Testowania i nie powinieneś ich oczekiwać. Twoimi użytkownikami są przeciętni ludzie, którzy słusznie oczekują, że oprogramowanie „po prostu działa”. Kiedy tak się nie stanie, będą zgłaszać wszystko, co według nich będzie miało na celu zwrócić uwagę. Nie możesz tego zmienić i nie powinieneś tego robić. Każda próba nalegania na zgłoszenie, jakiego oczekuje się od specjalisty, spowoduje utratę raportu o błędzie, a klient - „Miałem problem z tym oprogramowaniem, ale zamiast mi pomóc, wypełniłem wszystko rodzaj bezużytecznych form, które nic nie znaczą i nie mają dla mnie żadnej wartości. Poszukam oprogramowania, które faktycznie działa. "

tzn. to nie jest ich praca .....

Jeśli chcesz mieć dobre raporty o błędach, zatrudnij specjalistów, aby znaleźć swoje błędy. Jeśli jako twórca oprogramowania nie przejmujesz się kontaktami z klientami, zatrudnij kogoś, kto może.

— mattnz
źródło

1

Nie sądzę, że OP mówi, że nie chce zajmować się użytkownikami. Myślę, że OP mówi, że tak naprawdę nie mogą naprawić niczego na podstawie raportu o błędzie „rozbił się”. OP chce sposobu na jak najlepsze wykorzystanie użytkowników, którzy narzekają, aby OP mógł faktycznie naprawić problem.

— Michael Kohne

1

Chodzi mi o to, że jeśli „rozbił się”, dzieje się to z perspektywy użytkownika. Gdy zabieram samochód do mechanika, nie oczekuje, że przekażę mu fachowo szczegółowy raport diagnostyczny o tym, co jest nie tak - zadaje mi pytania, które pomogą mu wykorzystać jego wiedzę specjalistyczną do zdiagnozowania problemu. Na przykład podczas jednej wizyty mój problem polegał na tym, że „przeciąga się, gdy jest zimno, ale jest w porządku, gdy jest gorąco”, kilka dobrze przemyślanych pytań (bez odpowiedzi tak) później był dość pewien (i okazał się poprawny), że był wadliwy termometr. Naszym zadaniem jest zadawanie pytań w ramce, aby dać odpowiedź tak, a nie odpowiedź.

— mattnz