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

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

Хорошая книга по этому вопросу:

Debugging by David J. Agans

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

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

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

В моих организациях это происходит следующим образом:

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

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

3. PM или руководитель отдела назначает разработчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсюда есть три ответвления:

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

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

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