Каков ваш процесс управления ошибками?

Question

Каков жизненный цикл/процесс ошибки? Говоря вообще, есть ли какие-либо советы, подсказки, мудрый, что исправление ошибок должно идти?

Answer 1

Несколько вещей за пределами стандарта Find-> Fix-> цикл Test-релиз:

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

• Ваша система отслеживания ошибок должна отслеживать всю историю изменений.

• Следите за тем, какая версия была обнаружена, была исправлена, была протестирована, а затем выпущена. Все они разные и важные.

• Имейте возможность изменить проблему от ошибки до улучшения.

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

• Сохраните ошибку, ограниченную одной проблемой, чтобы вы могли проверить, действительно ли эта проблема исправлена. Итак, если на экране есть 3 вещи, запишите 3 ошибки, вместо этого один из «Проблемы на любом экране»; эти ошибки могут быть исправлены и выпущены отдельно, и вы должны иметь возможность отслеживать это.

Answer 2

Test (программное обеспечение) -> Log (эта ошибка) -> Fix -> Проверка -> Закрыть

Answer 3

1. пользователя сообщения об ошибке
2. QA воспроизводит ошибку
3. Dev triages ошибка проверить является ли это ошибка или новый запрос функции
4. Если это ошибка, это назначается разработчик
5. QA тестирует ошибку, исправить в следующей версии
6. Release

Answer 4

1. Обратите внимание на ошибку.
2. Найдите ошибку, сможете воспроизвести ее.
3. Решение для кода, исправить ошибку.
4. Тестирование. Убедитесь, что вы исправили ошибку и не вводили новые ошибки (функциональные и модульные тесты).
5. Восстановить или запланировать.

Простой вопрос, простой ответ. Надеюсь это поможет.

Answer 5

Хорошая книга на эту тему:

Debugging по Дэвиду J Аганс

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

Были случаи, когда я исправился (в коде обслуживания), чтобы обнаружить, что исправление сломало другие вещи. Прежде чем отметить ошибку как фиксированную, убедитесь, что исправление не сломает что-то еще.

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

Answer 6

Когда я нахожу ошибку, первое, что я делаю, это зарегистрировать ее в системе ошибок. Затем я пишу тест, чтобы проиллюстрировать ошибку, затем исправьте код, чтобы убедиться, что тест проходит. Это гарантирует, что вы можете: a) воспроизвести ошибку и b) исправить ошибку.

Периодически я буду анализировать базу данных ошибок, чтобы выяснить, почему возникают ошибки. Существуют ли ошибки в спецификации, логические ошибки в коде и т. Д.? И принять соответствующие меры, чтобы уменьшить количество ошибок.

Это подробное описание этого в моем блоге http://jeffastorey.blogspot.com/2010/02/what-to-do-when-you-find-bug.html здесь.

Answer 7

Мои организации следовали этой схеме:

инженер

1. Systems или QA замечает ошибку и вводит его в инструмент отслеживания ошибка.

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

3. PM или Dev Lead назначает ошибку разработчику.

4. Разработчик воспроизводит ошибку, любую необходимую помощь человеку в шаге 1.

5. разработчиков кодов решение и делает сборку (или имеет билд).

6. Тестер с шага 1 повторяет ошибку.

7. Если ошибка исправлена, перераспределите или заплатите. Повторите шаги 5 и 6 до тех пор, пока они не будут исправлены или приоритет будет иметь более насущная проблема.

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

Как правило, ошибки пройти через этот цикл назначения: Tester -> (PM/Свинец, то разработчик, или разработчик) -> Tester -> PM/Свинец -> Closed.

Answer 8

Я не могу помочь получить snarky здесь. Я попытался, но, наконец, сломался. Настоящий процесс ошибки:

Пользователь отправил электронное письмо разработчику, чтобы исправить ошибку. Разработчики электронной почты обратно и говорит, не может работать над ним, если не вступил в систему управления проектами. Все ненавидят систему PM, поэтому пользователь скулит о том, чтобы ее вводить. Дев твердо стоит, поскольку ему нужно где-то зарядить свое время. Ошибка, введенная в систему и назначенная разному разработчику.

Есть три ветви отсюда:

Branch 1, DEV смотрит на снимок экрана при условии и замечает, что пользователь ищет 2010 данных на 2009 странице отчетности. Пользователь сообщил об ошибке и ошибке закрыт.

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

Ой, действительно, есть настоящая ошибка, исправления и исправления для исправления ошибок для prod и закрывает ошибку.

Answer 9

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

Вещи рассмотреть:

• частота ошибок
• пользователи повлияли
• область кода
• VIP клиенты

вещи, которые могут помочь сделать приоритизации ошибки проще:

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

Вы можете найти более полезные предложения здесь: https://blog.bugsnag.com/bug-prioritization/