Методология отслеживания ошибок

Question

Я работаю над программным обеспечением для компании, которая никогда не публикует отчеты об ошибках, единственная жалоба: «Так и так не работает». Иногда я могу понять, о чем они говорят, иногда нет. Мои просьбы о снимках экрана и более подробной информации остаются без внимания (как только они сделали снимок экрана, затем распечатали его, отсканировали его с помощью своего факсимильного аппарата и отправили по электронной почте моему боссу в формате TIFF).

У меня есть несколько методов для предоставления мне необходимых данных. Вот шаги, которые я предпринял:

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

Какие еще методы я могу использовать, чтобы позволить мне обнаруживать ошибки и собирать больше данных о них, чтобы я знал, как их воспроизводить?

Answer 1

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

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

Обучите их, и они будут следовать . Вместо того, чтобы быть «тем надоедливым разработчиком, который хочет, чтобы мы потратили часы на какую-то случайную часть программного обеспечения» , вы будете »тем разработчиком, который активно придумывает новые решения проблем и найденных и делать правильные шаги для исправления таких ситуаций ".

---

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

Answer 2

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

Answer 3

Используйте «супервизор», который контролирует приложение и записывает контекстную информацию о нем, например, объем используемой памяти, объем доступной памяти на хосте, количество открытых файлов и т. д.

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

Answer 4

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

Но более важный вопрос - в вашем программном обеспечении слишком много ошибок? Частично их недовольство может быть связано с качеством программного обеспечения! Ваше упоминание о том, что вы только что включили циклы try-catch, похоже, указывает на это.

Улучшение качества программного обеспечения.

1. Есть ли у вас среда тестирования, отдельная от среды разработки, в которой вы тщательно тестируете все программное обеспечение, сценарии, модульные тесты, автоматическое тестирование, ручное тестирование перед доставкой заказчику?

2. У вас есть тестеры, единственной целью которых является тестирование программного обеспечения?

3. У вас есть документированный набор тестов и планы тестирования для тестеров?

4. У вас есть автоматические юнит-тесты для всех ваших кодов?

5. Есть ли у вас соглашения и стандарты кодирования, требования / соглашения о разработке и стандарты, соглашения и стандарты плана испытаний / тестирования, процесс для SDLC, анализ первопричин?

6. Есть ли у вас рецензии?

7. Есть ли у вас проверки, чтобы убедиться, что все проблемы из рецензирования решены, прежде чем переходить в тестовую / производственную среду?

Все это может уменьшить количество дефектов программного обеспечения и сделать клиента счастливее, что на самом деле является главной целью.

---

Теперь о вашем первоначальном вопросе.

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

1. Улучшите ведение журнала, чтобы вы могли получать информацию после факта. Вы делаете это.

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

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

4. В идеале у вас может быть режим, в котором вы фиксируете действия пользователя и можете воспроизвести ошибку с помощью функции воспроизведения.

5. Вы можете установить видеокамеру и записать, что они делают, поэтому, если они сообщат об ошибке и смогут ее воспроизвести, вы сможете точно узнать, что они делают.

Answer 5

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

https://store.techsmith.com/order/snagit.asp

Наберитесь терпения и работайте с ними (индивидуально), чтобы улучшить связь.

Answer 6

Я бы пошел на шаг дальше от ответа DisgruntledGoat и сказал, что любой сотрудник компании, который общается с клиентом, должен быть осведомлен об инструменте отслеживания ошибок и должен сообщать о проблемах, о которых сообщают пользователи. Это означает, что торговые представители, менеджеры проектов, служба поддержки и т. Д ...

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

Answer 7

Мы использовали rt для сообщений об ошибках пользователей, я имею в виду, что пользователи сообщают об ошибках, которые они находят, конечно, не сообщая об ошибках пользователей. Отличительной особенностью rt является то, что он может быть представлен пользователям просто как адрес электронной почты. Инструкции очень просты: найдите ошибку, отправьте электронное письмо. По моему опыту, это гораздо проще продать, чем Trac, Bugzilla и все остальное. Они хороши по-разному, но для большинства пользователей все они похожи на компьютерное заполнение форм.

Answer 8

Следуйте за этим для регистрации исключений

1. Форма / Страница, на которой произошла ошибка
2. Событие / метод
3. дата / время
4. Трассировка стека
5. Сообщение об ошибке
6. Код ошибки
7. Пользователь
8. Номер строки, если это возможно

Answer 9

Существуют различные способы отслеживания сбоев вашего приложения (.Net Specific) Windows и веб-приложения 1. В своем файле Global.asax.cs в разделе «Метод Application_Error» запишите журнал в текстовый файл, чтобы вы могли все исключения исключать с помощью трассировки их стека и всего остального. 2. В обычном сценарии, отличном от .net Environment, вы можете создать общий метод, чтобы его можно было вызывать для записи журнала, когда у вас есть исключение, то есть при каждой попытке - поймать или если имеется какая-либо платформа для этого. *

Или, если вы не хотите писать логи и работаете в среде Windows, тогда вы можете перейти к средству просмотра событий и отфильтровать сбои ваших приложений по его дампам.

Также Nlog - это хороший способ входа.

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

Надеюсь, это поможет

Answer 10

Поместите кнопку на каждой форме / странице самого приложения. Это должно быть заметно где-то отображено. Когда они нажимают кнопку, попросите их заполнить текстовое поле, в котором говорится о проблеме.

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