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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Есть ли у вас экспертные оценки?

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

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

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

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

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

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

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

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

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

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

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

Также Nlog является хорошим способом ведения лога.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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