Что это такое?

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, а также следить за процессом устранения этих ошибок. Так описаны в Wikipedia bug tracking system (далее BTS).

BTS помогает программисту следить за ошибками. Когда вы замечаете ошибку, необходимо собрать о ней максимальное количество доступной информации. Необходимо быть предельно точным в наблюдениях. Особенно это касается отчетов об ошибках, приходящих от пользователей.

Можно привести пример Энди Ханта, автора книги «Программист-прагматик»: он разрабатывал графический редактор, и в ходе разработки появилась специфическая ошибка, которую обнаружил тестировщик. Программа «падала» когда тестировщик проводил кистью прямую линию. Программист утверждал, что программа работает замечательно и у него ошибка не проявляется. Несколько дней между тестером и программистом продолжался спор. Наконец, все собрались в одной комнате, тестировщик провел линию от ВЕРХНЕГО ПРАВОГО угла до НИЖНЕГО ЛЕВОГО. Программа зависла. Программист охнул и признался, что он проводил черту только из НИЖНЕГО ЛЕВОГО к ВЕРХНЕМУ ПРАВОМУ углу. Этот пример иллюстрирует, насколько важны подробные отчеты и сбор полной информации об ошибках.

Как правило, BTS позволяет хранить информацию об ошибке в следующем виде:

кто сообщил о проблеме;

дата и время, когда была обнаружена проблема;

серьёзность проблемы;

описание неправильного поведения программы;

кто занимается устранением проблемы;

состояние ошибки.

Это минимальный набор требований к БД BTS, на самом же деле многие системы багтрэкинга позволяют вести намного более подробный учет ошибок. В чем то, они напоминают системы управления проектами. А многие из них интегрированы с такими системами.

Необходимо заметить, что системы отслеживания ошибок могут быть полезны не только для программистов. Отчеты о «работе над ошибками» могут использовать менеджеры проекта. Фактически такие отчеты позволяют судить о производительности программистов, при работе по улучшению работы ПО. При обработке отчетов необходимо учитывать приоритет ошибок и сложность их устранения. Менеджер должен понимать, что некоторые ошибки могут быть трудно устранимы, в силу архитектуры системы. Бессмысленно требовать скорейшего устранения ошибок в системных модулях: непродуманные действия по устранению одной ошибки могут породить сотни других ошибок.

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

Вариантов решения проблемы несколько.

• Оставить все как есть, пусть разработчики сами решают как им быть дальше. Вариант самый простой, но про последствия писать, думаю, излишне.
• Напрячь разработчиков — пусть пишут «самую лучшую в мире BTS в отдельно взятой конторе». Если клиенты могут подождать, и денег/времени не жалко — отличный вариант.
• Использовать готовое решение и при необходимости доработать его под свои нужды. Вот на этом, пожалуй и остановимся.

Итак, перед нами стоит задача выбора системы отслеживания ошибок (bug tracking system, BTS) удовлетворяющую следующим базовым требованиям

• Поддержка большого количества проектов
• Удобный и функциональный web-интерфейс
• Наличие интеграции с системами контроля версий
• Поддержка многоязычности
• Учет и планирование рабочего времени
• Организация внутрикомандного взаимодействия разработчиков
• Работа с базами знаний (к примеру, wiki)
• Легкость доработки под нужды компании.
• Легкость установки и сопровождения.

Системы отслеживания ошибок (bug-tracking systems) предназначены для обеспечения качественной поддержки программных продуктов. Главным компонентом таких систем является база данных, в которой хранится информация о недостатках продуктов. Сообщения о проблемах, добавляемых в базу данных, принято называть «тикетами» (от англ. ticket — «билет, ярлык, объявление»). Тикеты разделяются на категории по таким критериям, как продукт и/или его компонент, к которому относится тикет, тип тикета (задача, ошибка, запрос на улучшение), его важность и желаемое время решения найденной проблемы.

Поиск по сайту: