среда, 6 декабря 2006 г. - www.msmirnov.ru

Управление ошибками на практике

Здесь я привожу копию моей статьи "Управление ошибками на практике", опубликованной в журнале RSDN Magazine #3 за 2006г. http://rsdn.ru/?article/methodologies/errorpractice.xml

Управление ошибками на практике.

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

Введение

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

Проблемы, возникающие при отсутствии управления ошибками

В фазе кодирования стало ясно, что отсутствие формализованного подхода приводит к следующим проблемам:
  1. Разработчики начинают забывать об ошибках. Такое часто бывает, если ошибок достаточно много. Двигаясь вперед, устраняя эти ошибки, он может пропустить некоторые из них, посчитав их низкоприоритетными, а потом забыть к ним вернуться.
  2. Тестировщики забывают проверять качество устранения ошибок. Если разработчик исправил ошибку и попросил тестировщика проверить это, то, во-первых, тестировщик уже может не помнить, в чем она состояла (или забыть детали) и, во-вторых, также может забыть выполнить проверку, переключившись на ошибки других разработчиков.
  3. Разработчики устраняют ошибки «не в том порядке». Довольно часто такое может быть, когда разработчику хочется устранять не те ошибки, которые являются важными с точки зрения заказчика или руководителя проекта. Если в команде мало разработчиков (1-2), то, в принципе, они могут напрямую контактировать с пользователями, чтобы выяснять приоритет ошибок, но даже в этом случае они могут не знать всей полноты картины.
  4. Руководитель не знает, сколько ошибок ждут устранения, и сколько исправлено. Очевидно, что если информация об ошибках поступает в устном виде, то очень трудно отследить прогресс их устранения. Руководителю проекта в такой ситуации очень трудно понять, что происходит. Ему неизвестно, сколько еще ошибок ждут своей очереди, какие из них являются важными, а какие – нет, какие из них можно отложить, а каким надо уделить первоочередное внимание.
Внедрение формализованного процесса помогло решить подобные проблемы.

Описание процесса

Основными участниками такого процесса являются:
  • Тестировщик.
  • Руководитель команды.
  • Разработчики.
Проще всего описать процесс управления ошибками через последовательность действий, выполняемых над ошибкой в рамках такого процесса.
ШагУчастникДействиеРезультат
1.ТестировщикОбнаруживает ошибку и вносит ее в систему управления ошибками.
1.Заказчик или пользователь.Сообщает об ошибке и вносит ее в систему управления ошибками.
1.РазработчикЗамечает ошибку у себя или у другого разработчика и вносит ее в систему управления ошибками.Ошибка внесена в систему управления ошибками.
2.Руководитель команды и иногда тестировщикОпределяет приоритет ошибки и назначает разработчика, ответственного за ее устранение.Ошибка поступает к разработчику.
3.РазработчикУстраняет ошибку и помечает ее как исправленную.Ошибка поступает к тестировщику на проверку.
4ТестировщикПроверяет правильность устранения ошибки и, если ошибка не устранена или устранена неверно, то вновь направляет ее к разработчику, а если все в порядке, то закрывает ошибку.Ошибка прекращает свое существование или отправляется на повторную доработку.
Здесь видно, как ошибка от обнаружения до устранения переходит от одного члена команды к другому.
Центральным звеном является система управления ошибками (Bug Tracking). Без нее эффективное внедрение такого процесса невозможно.
Описанные выше процесс является упрощенной моделью, в его организации могут быть изменения, например:
  1. Пользователи не обязательно должны сами вносить ошибки в базу. За них это могут осуществлять специалисты службы поддержки. Кроме того, сам продукт в процессе работы может автоматически вносить сообщения в базу ошибок. Это, конечно, возможно при условии, что система управления ошибками имеет API.
  2. Необязательно именно Team Leader должен заниматься распределением ошибок. Если команда работает достаточно тесно, то тестировщик должен знать, кто из разработчиков отвечает за компонент системы, содержащий данную конкретную ошибку. В этом случае он может самостоятельно провести назначение.
  3. Некоторые ошибки могут оказаться трудными для проверки тестировщиком – например, ошибки времени исполнения в Windows-сервисах. Такие ошибки можно проверять, используя unit-тестирование или привлекая других разработчиков. При unit-тестировании также может происходить автоматическое наполнение базы ошибок.
  4. Ошибкам не обязательно должен быть назначен ответственный за их устранение разработчик. Team Leader может посчитать некоторые ошибки несущественными и отложить их исправление на потом, пометив специальным образом.
Для организации подобного процесса следует также соблюдать следующие условия:
  1. Каждый отчет об ошибке должен содержать необходимый набор свойств. Это поможет всем членам команды ориентироваться в списке ошибок. Как мне кажется, следующего набора свойств достаточно для начала организации процесса:
  • Приоритет – Низкий, Средний, Высокий, Критический.
  • Тип ошибки – Exception, Дизайн, Неверная функциональность и т.п.
  • Компонент продукта – сайт, база данных и т.п.
  • Версия компонента.
  1. Чтобы разработчикам не требовалось тратить время на повторение ошибок, тестировщикам необходимо описывать ошибки как можно более подробно. Желательно, каждую ошибку должны сопровождать:
  • Снимок экрана (если возможно).
  • Информации о пользователе (например, логин для сайта), сообщившем об ошибке.
  • URL, если речь идет о сайте.
  • Стек, если речь идет об ошибке времени выполнения.
  • Последовательность действий, приводящая к ошибке.
  • Файлы отчетов об ошибках, письма пользователей, тексты ошибок и т.д.
  1. Необходимо заранее обеспечить каждому разработчику возможность просмотра списка ошибок, назначенных ему, а также общего списка, создав специальные отчеты и т.п. Тестировщикам следует обеспечить быстрый доступ к списку ошибок, ожидающих проверки.
  2. Хорошо зарекомендовала себя практика давать возможность разработчикам назначать других разработчиков ответственными за ошибки. В этом случае разработчики смогут передавать ошибки друг другу на рассмотрение, если в устранении задействовано несколько человек.
  3. Следует ограничить возможность разработчиков удалять или закрывать ошибки. Такое право должно быть только у тестировщика и руководителя. Это следует сделать, чтобы исключить возможность умышленного сокрытия ошибки.
  4. Разработчики при отметке об исправлении ошибки должны указывать время, потраченное на ее устранение. В дальнейшем это поможет получать разнообразные аналитические отчеты, например:
  • процент времени, затрачиваемый на устранение ошибок;
  • средние затраты времени на устранение ошибки;
  • среднее время жизни ошибки.
  1. Если пользователи продукта хотят самостоятельно составлять отчеты об ошибках и отслеживать их устранение, то им стоит предоставить web-интерфейс системы управления ошибками. Для внутреннего использования обычно удобнее Windows-интерфейс. Поэтому при выборе системы управления ошибками стоит обратить внимание на то, чтобы она предоставляла оба способа доступа.
Подобный процесс управления ошибками очень хорошо согласуется с идеей ежедневных сборок всей системы. При этом после сборки и тестового развертывания:
  1. Тестировщики получают новую порцию устраненных ошибок для верификации.
  2. Проводя регрессионное тестирование продукта, тестировщики проверяют, не повлияло ли устранение ошибок на работу продукта. Если в работе продукта появились проблемы – помещают их в базу ошибок. Опять же это может быть автоматизировано.
  3. Руководитель разработчиков знает, какая порция ошибок была исправлена в текущей сборке продукта. Иногда это может служить некоторой формой отчетности перед заказчиком.
  4. Оценивая критичность ошибок, которые в данный момент устраняются разработчиками, их руководитель может отложить тестовую сборку до устранения этих ошибок.
При выборе системы управления ошибками (bugtracking-системы), стоит обратить внимание на следующие характеристики:
  1. Интерфейс. Система должна предоставлять как web-, так и windows-интерфейс. Обычно для работы внешних пользователей лучше подходит web-интерфейс, а для внутренних – windows.
  2. Наличие API. Используя API, вы сможете помещать новые ошибки в базу при автоматизированном тестировании.
  3. Возможности конфигурации. Скорее всего, ваш процесс управления ошибками будет иметь свои нюансы и будет отличаться от того, который предлагается по умолчанию системой. Поэтому системы должны предоставлять богатые возможности по настройке последовательности процесса, его шагов, прав разработчиков и т.п.
  4. Первоначальный опыт показал, что не стоит использовать MS Project Server в качестве подобной системы. Его предназначение состоит в управлении более объемными задачами, чем мелкие ошибки.

Заключение

В этой статье я дал ряд рекомендаций по организации процесса управления ошибками. Конечно, это только схематичное описание процесса. Каждый конкретный случай, скорее всего, будет иметь существенные отличия. Однако такой подход показал свою эффективность в моем опыте управления разработкой.
Я с радостью рассмотрю любые комментарии и вопросы по данной тематике. Мои координаты доступны на сайте http://www.msmirnov.ru/ или по электронной почте msmirnov@msmirnov.ru
Мой сайт - www.msmirnov.ru