Как заставить пользователей писать достойные и полезные отчеты об ошибках

Кто-нибудь знает хороший способ заставить пользователей написать полуприличный (читай: полезный ) отчет об ошибке ?

Мы хотели придумать что-то, что имело бы смысл для большинства пользователей (было бы легко читать и понять), но также дало бы полезную информацию для разработчиков.

Это не работает, когда я нажимаю синюю кнопку! Аааа, я только что потерял неделю работы ... заставить ее работать.

не очень полезно, как есть.

Я начал исправлять список, но подумал, чтобы проверить, ребята, существует ли подобный метод.

Самый эффективный способ заставить пользователей писать достойные и полезные отчеты об ошибках -

1. чтобы они могли видеть свои отчеты в Интернете ...
   ^{[Система] Спасибо за сообщение, вы можете найти статус вашего запроса здесь: ...}
2. ... вместе с оценкой и комментариями назначенного инженера ...
   ^{[Инженер] Запрос отклонен, поскольку отсутствуют следующие детали: ...}
3. ... с возможностью редактировать / улучшать свой отчет.
   ^{[Пользователь] Добавлена ​​запрашиваемая информация, пожалуйста, переоцените: ...}

Я бы сказал, что это единственный эффективный путь.

Посмотрим правде в глаза, умение эффективно писать отчеты об ошибках приходит только с опытом. Нужно учиться, чтобы получить опыт. Обучение включает в себя практику, получение обратной связи и улучшение.

Редактируемые пользователем онлайн-отчеты об ошибках - самый эффективный способ научить пользователей совершенствоваться .

• ^{Альтернативными вариантами, описанными выше, являются: 1) организация очных учебных сессий с пользователями (да, конечно, особенно когда их тысячи разбросаны по всему миру). Или 2) объясните эти вещи по телефону («посмотрите, если бы вы могли видеть только дерьмо, которое вы написали в строке 225 ...»). Что-то еще? Ах, 3) по электронной почте, конечно "в письме, которое вы отправили нам два месяца назад, вы упомянули ... нет, не то письмо, вы отправили нам пять писем в этот день, три из них были с темой Re: нажатие синей кнопки , посмотрите на второй, с прикрепленным снимком экрана размером 10 Мб ... что? вы не можете его найти? "}

На мой взгляд, что более важно, так это использование ошибки для установления значимого контакта с пользователем. Написание и понимание отчетов об ошибках - это навык, и я бы посоветовал сделать так, чтобы пользователь как можно проще установил первый контакт, а затем постепенно делал свои отзывы более значимыми по мере необходимости.

Например, просто получите электронную почту пользователя и введите в него текстовое поле со следующим текстом:

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

После того, как вы получите электронное письмо, сделайте автоответчик, чтобы получить двойной ответ, чтобы подтвердить, что они отправили сообщение об ошибке, вы его получили, и продолжение исправления ошибки в порядке.

Вы можете рассмотреть некоторые идеи Mozilla и Sun по этой теме:

• Рекомендации по написанию ошибок - статья в Mozilla MDN
• Как написать правильную ошибку - статья о Mozilla QMO
• Как написать полезный отчет об ошибке - Sun SDN article

В частности (со страницы Mozilla "Как написать правильную ошибку"):

Общее описание сообщения об ошибке

Резюме : Как бы вы описали ошибку менее чем в 60 символах? Он должен быстро и однозначно идентифицировать отчет об ошибке, а также объяснить проблему, а не предлагаемое решение.

Хорошо : «Отмена диалога копирования файла приводит к сбою файлового менеджера»

Плохо : «сбой программного обеспечения»

Плохо : «Браузер должен работать с моим веб-сайтом»

Компонент : в какой части программного обеспечения оно существует? Это поле является обязательным для отправки любого сообщения об ошибке. Нажмите на слово «Компонент», чтобы увидеть описание каждого компонента. Если ни один из них не подходит, выделите компонент «Общие».

ОС : В какой операционной системе (ОС) вы ее нашли? (Например, Linux, Windows XP, Mac OS X.) Пример: «Если вы знаете, что ошибка возникает в более чем одном типе операционной системы, выберите« Все ». Если вашей ОС нет в списке, выберите «Другие».

Описание : подробности вашего отчета о проблеме, в том числе:

- Обзор : это более подробное изложение резюме. Примером может быть: «При перетаскивании любой страницы происходит сбой сборки Mac в функции NSGetFactory».

- Build Id : чтобы найти это, либо перейдите на страницу «about:» с помощью адресной строки, либо, если у вас есть расширение MozQA для Nightly Tester Tools, затем перейдите в Tools | Инструменты Nightly Tester и выберите параметр, который содержит выходные данные идентификатора сборки. Это должно выглядеть примерно так: «Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Дополнительные сборки и платформы : имеет ли место ошибка на других платформах (или браузерах, если применимо). Это должно выглядеть примерно так: «Не происходит в Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Шаги для воспроизведения : минимизированные, простые в выполнении шаги, которые вызовут ошибку. Если они необходимы, обязательно включите в них какие-либо специальные шаги установки. Хороший пример этого будет выглядеть следующим образом: 1) Просмотрите любую веб-страницу. (Я использовал образец страницы по умолчанию, http://www.google.com/ ). 2) Перетащите-выберите страницу. В частности, удерживая кнопку мыши, перетащите указатель мыши вниз из любой точки в области содержимого браузера до нижней части области содержимого браузера.

Фактические результаты : то, что приложение сделало после выполнения вышеуказанных шагов. Примером может быть: Приложение упало.

Ожидаемые результаты : что приложение должно было сделать, если бы ошибки не было. Например: окно должно прокручиваться вниз. Прокручиваемый контент должен быть выбран. Или, по крайней мере, приложение не должно падать.

Саймон Тэтхэм : Как эффективно сообщать об ошибках Это действительно объясняет вещи, чтобы было легче понять их менее опытным пользователям. Однако недостатком является то, что это довольно много текста. Когда пользователь пытается сообщить о проблеме, но не может объяснить ее, вы обычно не сможете убедить его прочитать все это.

Вы можете задавать понятные и легко отвечающие вопросы пользователям, ожидающим полезных отчетов.

Например, «Каким было ваше последнее действие перед этой ошибкой?», «Вы пытались ... как раз перед этой ошибкой?».

Ни один пользователь не написал бы сообщение об ошибке, например: «Мой видеодрайвер не обновлен. Ваша графическая библиотека может быть несовместима со старыми графическими драйверами».

Предполагая, что база пользователей - это конечные пользователи, у которых были проблемы с программным обеспечением, которое вы написали ....

Стать опытным инженером-программистом или специалистом по тестированию не ваша работа, и вы не должны этого ожидать. Ваши пользователи - обычные люди, которые справедливо ожидают, что программное обеспечение будет «просто работать». Когда этого не произойдет, они сообщат обо всем, на что, по их мнению, они обращают внимание, чтобы привлечь ваше внимание. Вы не можете изменить это, и не должны пытаться. Любая попытка настаивать на том, какие отчеты должен сделать профессионал, приведет к потере отчета об ошибке, а клиент - «У меня возникла проблема с этим программным обеспечением, но вместо того, чтобы помочь мне, он должен был заполнить все». виды бесполезных форм, которые ничего не значат и не имеют для меня значения. Я пойду найду какое-нибудь программное обеспечение, которое действительно работает ».

т.е. это не их работа .....

Если вы хотите иметь хорошие отчеты об ошибках, наймите профессионалов, чтобы найти ваши ошибки. Если вы, как разработчик программного обеспечения, не можете иметь дело с клиентами, наймите кого-нибудь, кто может.