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