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

Несколько вещей, выходящих за рамки стандартного цикла Find-> Fix-> Test-Release:

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

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

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

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

• Имеют статус «вопрос» или «ожидает ответов», чтобы представить, что вопросы были отправлены бизнес-аналитику, что по сути блокирует продвижение к ошибке.

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

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

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

Отладка Дэвида Дж. Аганса

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

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

Это поднимает реальную проблему ошибки: Непонимание полностью, что делает код.

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

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

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

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

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

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

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

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

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

Как правило, ошибки проходят следующий цикл назначения: Тестировщик -> (Руководитель проекта / руководитель, затем разработчик; или разработчик) -> Тестировщик -> Руководитель проекта / руководитель -> Закрыто.

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

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

Отсюда три ветки:

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

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

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

Тест (программное обеспечение) -> Журнал (ошибка) -> Исправить -> Проверить -> Закрыть

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

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

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

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

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

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

На что следует обратить внимание:

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

Что может помочь упростить приоритизацию ошибок:

• интеллектуальное оповещение
• возможность заглушить или отложить ошибки
• группировать похожие ошибки вместе
• отображение ошибок для пользователей
• объединение ошибок по всей вашей системе в одном месте.

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