Мы пишем настольное приложение Windows, которое установлено на нескольких тысячах компьютеров, к которым у нас нет доступа. Когда один из этих пользователей сообщает об ошибке, даже если описание довольно полно, существует другая информация, которая может быть полезной.
Мы в настоящее время работаем над автоматизированным агентом обратной связи, что означает, что у нас будет доступ к очень подробной информации. Но как ребенок в кондитерской, мы не уверены, где запустить. Какую информацию Вы включали бы в свой пакет обратной связи в том же случае? Что полезно, чтобы помочь нам воспроизвести там ошибку?
Что мы имеем, до сих пор:
Обратите внимание, что это подобно этому вопросу, однако мы так не интересуемся получением информации, когда программа отказывает, как мы - то, как тогда, когда пользователь испытывает ошибку.
Править: Разъяснение: не просьба о том, что информация пользователь должна дать в случае ошибки, а скорее какую информацию мы должны собрать программно?
Даже если у вас есть вся эта информация, воспроизвести проблему может быть сложно. Когда пользователи описывают, как они создали ошибку, они часто ошибаются относительно ключевых шагов - им трудно понять, какие области являются критическими, когда они не знают внутренней работы приложения. Возможно, вы захотите реализовать способ отслеживания действий пользователя, например, обработку событий на корневом уровне или другие способы - если у вас есть функции отмены/повтора, то я уверен, что этого будет достаточно. Затем вы можете включить последние (x) шаги цепочки действий в отчет об ошибке.
Изменить: Думаю, я неправильно понял ваш вопрос. Я думал, что вы говорите о том, какую информацию можно получить от клиента, сообщающего об ошибке, вместо того, чтобы уже планировать то, что я здесь описываю. Я все равно оставлю это для справки.
В аналогичной ситуации, несмотря на меньшее количество пользователей, наше приложение получило кнопку «Упаковать журналы для поддержки», которая создаст zip-файл со всеми файлами журналов и текущим открытым файлом проекта, если таковой имеется. Вся остальная информация, которую вы описали, уже является частью одного из файлов журнала. Таким образом, клиент может удобно отправить нам ZIP-файл, что можно сделать из главного окна приложения, не открывая файл проекта или не подключаясь к сетевому интерфейсу, что является двумя основными моментами, когда что-то может пойти не так. Это намного проще, чем полагаться на пользовательскую обратную связь «вручную».
Кроме этого, должны быть доступны точные шаги для воспроизведения проблемы. Большая часть этого обычно находится в самом файле проекта (который находится в полученном нами ZIP-файле), за исключением нескольких шагов.
Вещи, которые казались важными для этого, помимо того, что вы уже указали:
Помимо основного состояния приложения (версия, конфигурация и т.д.), наиболее важной информацией, которую необходимо получить, является:
Этой информации будет достаточно для решения 99,9% проблем. В остальных случаях, следуйте дальше и получайте любую подробную информацию, которая, по вашему мнению, поможет решить проблему (которая, надеюсь, к этому моменту будет гораздо лучше понятна).