Что такое система отслеживания ошибок

From Wikipedia, the free encyclopedia

A bug tracking system or defect tracking system is a software application that keeps track of reported software bugs in software development projects. It may be regarded as a type of issue tracking system.

Many bug tracking systems, such as those used by most open-source software projects, allow end-users to enter bug reports directly.^[1] Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other project management software.

A bug tracking system is usually a necessary component of a professional software development infrastructure, and consistent use of a bug or issue tracking system is considered one of the «hallmarks of a good software team».^[2]

Making[edit]

A major component of a bug tracking system is a database that records facts about known bugs. Facts may include the time a bug was reported, its severity, the erroneous program behavior, and details on how to reproduce the bug; as well as the identity of the person who reported it and any programmers who may be working on fixing it.^[3]

Typical bug tracking systems support the concept of the life cycle for a bug which is tracked through the status assigned to the bug. A bug tracking system should allow administrators to configure permissions based on status, move the bug to another status, or delete the bug. The system should also allow administrators to configure the bug statuses and to what extent a bug in a particular status can be moved. Some systems will e-mail interested parties, such as the submitter and assigned programmers, when new records are added or the status changes.

Usage[edit]

The main benefit of a bug-tracking system is to provide a clear centralized overview of development requests (including both bugs and improvements; the boundary is often fuzzy), and their state. The prioritized list of pending items (often called backlog) provides valuable input when defining the product road map, or maybe just «the next release».

In a corporate environment, a bug-tracking system may be used to generate reports on the productivity of programmers at fixing bugs. However, this may sometimes yield inaccurate results because different bugs may have different levels of severity and complexity. The severity of a bug may not be directly related to the complexity of fixing the bug. There may be different opinions among the managers and architects.

A local bug tracker (LBT) is usually a computer program used by a team of application support professionals (often a help desk) to keep track of issues communicated to software developers. Using an LBT allows support professionals to track bugs in their «own language» and not the «language of the developers.» In addition, an LBT allows a team of support professionals to track specific information about users who have called to complain—this information may not always be needed in the actual development queue. Thus, there are two tracking systems when an LBT is in place.

Part of integrated project management systems[edit]

Bug and issue tracking systems are often implemented as a part of integrated project management systems.
This approach allows including bug tracking and fixing in a general product development process, fixing bugs in several product versions, automatic generation of a product knowledge base and release notes.

Distributed bug tracking[edit]

Some bug trackers are designed to be used with distributed revision control software. These distributed bug trackers allow bug reports to be conveniently read, added to the database or updated while a developer is offline.^[4] Fossil and Veracity both include distributed bug trackers.

Recently, commercial bug tracking systems have also begun to integrate with distributed version control. FogBugz, for example, enables this functionality via the source-control tool, Kiln.^[5]

Although wikis and bug tracking systems are conventionally viewed as distinct types of software, ikiwiki can also be used as a distributed bug tracker. It can manage documents and code as well, in an integrated distributed manner. However, its query functionality is not as advanced or as user-friendly as some other, non-distributed bug trackers such as Bugzilla.^[6] Similar statements can be made about org-mode, although it is not wiki software as such.

Bug tracking and test management[edit]

While traditional test management tools such as HP Quality Center and IBM Rational Quality Manager come with their own bug tracking systems, other tools integrate with popular bug tracking systems.^{[citation needed]}

See also[edit]

• Application lifecycle management
• Comparison of issue-tracking systems – Including bug tracking systems
• Comparison of project management software – Including bug tracking systems

References[edit]

External links[edit]

• Bug Tracking Software at Curlie
• How to Report Bugs Effectively by Simon Tatham
• List of distributed bug tracking software
• How to Write a Bug Report that Will Make Your Developers Happy

From Wikipedia, the free encyclopedia

A bug tracking system or defect tracking system is a software application that keeps track of reported software bugs in software development projects. It may be regarded as a type of issue tracking system.

Many bug tracking systems, such as those used by most open-source software projects, allow end-users to enter bug reports directly.^[1] Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other project management software.

A bug tracking system is usually a necessary component of a professional software development infrastructure, and consistent use of a bug or issue tracking system is considered one of the «hallmarks of a good software team».^[2]

Making[edit]

A major component of a bug tracking system is a database that records facts about known bugs. Facts may include the time a bug was reported, its severity, the erroneous program behavior, and details on how to reproduce the bug; as well as the identity of the person who reported it and any programmers who may be working on fixing it.^[3]

Typical bug tracking systems support the concept of the life cycle for a bug which is tracked through the status assigned to the bug. A bug tracking system should allow administrators to configure permissions based on status, move the bug to another status, or delete the bug. The system should also allow administrators to configure the bug statuses and to what extent a bug in a particular status can be moved. Some systems will e-mail interested parties, such as the submitter and assigned programmers, when new records are added or the status changes.

Usage[edit]

The main benefit of a bug-tracking system is to provide a clear centralized overview of development requests (including both bugs and improvements; the boundary is often fuzzy), and their state. The prioritized list of pending items (often called backlog) provides valuable input when defining the product road map, or maybe just «the next release».

In a corporate environment, a bug-tracking system may be used to generate reports on the productivity of programmers at fixing bugs. However, this may sometimes yield inaccurate results because different bugs may have different levels of severity and complexity. The severity of a bug may not be directly related to the complexity of fixing the bug. There may be different opinions among the managers and architects.

A local bug tracker (LBT) is usually a computer program used by a team of application support professionals (often a help desk) to keep track of issues communicated to software developers. Using an LBT allows support professionals to track bugs in their «own language» and not the «language of the developers.» In addition, an LBT allows a team of support professionals to track specific information about users who have called to complain—this information may not always be needed in the actual development queue. Thus, there are two tracking systems when an LBT is in place.

Part of integrated project management systems[edit]

Bug and issue tracking systems are often implemented as a part of integrated project management systems.
This approach allows including bug tracking and fixing in a general product development process, fixing bugs in several product versions, automatic generation of a product knowledge base and release notes.

Distributed bug tracking[edit]

Some bug trackers are designed to be used with distributed revision control software. These distributed bug trackers allow bug reports to be conveniently read, added to the database or updated while a developer is offline.^[4] Fossil and Veracity both include distributed bug trackers.

Recently, commercial bug tracking systems have also begun to integrate with distributed version control. FogBugz, for example, enables this functionality via the source-control tool, Kiln.^[5]

Although wikis and bug tracking systems are conventionally viewed as distinct types of software, ikiwiki can also be used as a distributed bug tracker. It can manage documents and code as well, in an integrated distributed manner. However, its query functionality is not as advanced or as user-friendly as some other, non-distributed bug trackers such as Bugzilla.^[6] Similar statements can be made about org-mode, although it is not wiki software as such.

Bug tracking and test management[edit]

While traditional test management tools such as HP Quality Center and IBM Rational Quality Manager come with their own bug tracking systems, other tools integrate with popular bug tracking systems.^{[citation needed]}

See also[edit]

• Application lifecycle management
• Comparison of issue-tracking systems – Including bug tracking systems
• Comparison of project management software – Including bug tracking systems

References[edit]

External links[edit]

• Bug Tracking Software at Curlie
• How to Report Bugs Effectively by Simon Tatham
• List of distributed bug tracking software
• How to Write a Bug Report that Will Make Your Developers Happy

• Что такое баг-трекер
• В чем польза
• Jira
• Trello
• Axosoft
• Backlog
• ReQtest
• Mantis Bug Tracker
• Bugzilla
• BugHerd

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

Что собой представляет система отслеживания ошибок?

Инструменты отслеживания ошибок (системы баг-трекинга) предназначены для систематической регистрации багов и прочих проблем и удобного управления жизненным циклом бага.

Среднестатистическая баг-трекинговая система имеет следующий функционал:

• создание тикетов с подробным описанием багов
• классификация и расстановка приоритетов в тикетах
• назначение тикетов конкретным специалистам
• отслеживание статуса бага на разных этапах
• удобный поиск, сортировка и составление баг-репортов
• аналитика и автоматическое формирование репортов.

Зачем нужна система отслеживания ошибок?

Баг-трекинговые системы упрощают отслеживание, классификацию и приоритизацию багов. Также они полезны для аналитики: с их помощью можно получить информацию, которая позволит повысить общую эффективность команды и потенциально оптимизировать затраты на разработку. К тому же баг-трекинговые системы упрощают коммуникацию между тестировщиками и разработчиками.

Обзор популярных систем отслеживания ошибок

JIRA

Инструмент отслеживания ошибок Jira был запущен в 2003 году. Со временем он превратился в систему управления проектами, широко используемую в agile-разработке. В частности, в Jira есть доски Scrum и Kanban, дорожные карты и многое другое. 

Что касается баг-трекинга, Jira предоставляет полный набор необходимых функций. 

✅ Плюсы:

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

❌ Минусы:

• Пользователи отмечают, что UI сбивает с толку и порой сложен для понимания
• Функции репортов не учитывают все параметры, которые было бы полезно отслеживать
• Jira может оказаться дорогой для небольших команд
• Регистрация, настройка и устранение неполадок сложны

Jira предлагает три платных пользовательских плана с гибкими ценами. Также есть бесплатная пробная версия (7 дней).

Итог

Jira идеально подходит для гибкого управления проектами и ценится за свою функциональность. Но изобилие функций и расширений имеет и обратную сторону: инструмент сложно настраивать.

TRELLO

Как и Jira, Trello — это продукт Atlassian. Он хорошо подходит и для отслеживания ошибок, и для управления продуктами в целом. 

Изюминкой Trello является упор на визуализацию. Пользователи могут создавать доски для отдельных проектов. На этих досках они создают списки — с задачами, статусами и т. д. В каждом списке есть карточки для отдельных маленьких задач или, как в нашем случае, для багов. 

По своей сути Trello — это способ организации заметок на стене в цифровом пространстве.

✅ Плюсы:

• Интуитивно понятный интерфейс позволяет легко настроить инструмент
• Благодаря визуализации досок всем членам команды удобно отслеживать прогресс
• Каждая карточка может содержать много разной информации, включая подробные описания багов, мультимедийные файлы, комментарии и обсуждения и т. д.
• Пользователи могут назначать и переназначать задачи и управлять сроками их выполнения
• Также можно отслеживать показатели производительности, просматривать историю и активность для каждой карточки
• Trello поддерживает более 100 интеграций с другими инструментами, включая Confluence, Slack, Google Drive и Dropbox
• Доступно мобильное приложение

❌ Минусы:

• Иногда в Trello невозможно загрузить изображения с высоким разрешением
• Десктопные приложения работают только при подключении к Интернету
• Техническая документация непонятна, поэтому процесс настройки многим кажется сложным
• При использовании для крупных проектов доска становится сложной для навигации

Trello предлагает два коммерческих плана: для сравнительно небольших команд (до 100 человек) и для совместной работы нескольких команд (100+ пользователей). Есть и бесплатная версия, дающая доступ к базовому функционалу. 

Итог

Trello — простое и доступное решение для небольших проектов. Но если у вас масштабный проект с обилием информации, Trello может быть не так полезен. Имейте в виду, что это в первую очередь инструмент управления проектами, а не баг-трекинговая система. 

AXOSOFT 

Axosoft — это инструмент для гибкого управления багами. Его основными особенностями являются доска планирования Scrum и диаграмма сгорания задач, управление требованиями и вики-страницы для сбора знаний о продукте и идей. 

✅ Плюсы: 

• Простота использования
• Пользователи могут автоматически превращать электронные письма в тикеты службы поддержки
• Папки проекта помогают упорядочить информацию и упростить ее поиск
• Есть возможность создавать настраиваемые поля и правила
• Ход процесса исправления багов можно отслеживать в режиме реального времени
• Легкое переключение между двумя доступными режимами просмотра (Kanban и список)
• Функция тайм-трекинга полезна для планирования спринтов и управления командой
• Пользователи могут создавать вики-страницы для тест-кейсов и документации
• Есть API для интеграции Axosoft с программами для управления тестированием и другими инструментами

❌ Минусы: 

• Пользовательский интерфейс несколько запутан, из-за чего новичкам сложно ориентироваться
• Пользователи сообщают о проблемах с фильтрацией, созданием репортов и потерянными задачами
• Сообщество пользователей невелико, а служба поддержки часто неэффективна и реагирует медленно

Продукт платный, есть разные планы подписки. Также есть 14-дневная бесплатная версия и 30-дневная гарантия возврата денег для пользователей, которые не удовлетворены продуктом. 

Итог

Это инструмент для баг-трекинга и отслеживания спринтов, который подойдет agile-командам. Он предлагает информацию, полезную для планирования спринта, и позволяет создать внутреннюю базу знаний. 

BACKLOG

Backlog — это комплексное ПО для управления проектами с функцией баг-трекинга. Эту программу можно использовать для управления задачами, клиентами и рабочими процессами, контроля версий, совместной работы в команде и многого другого.

Что касается отслеживания ошибок, то с помощью Backlog легко сообщать о багах и отслеживать их жизненный цикл. 

✅ Плюсы: 

• Простота использования, интуитивно понятный интерфейс, благодаря чему кривая обучения минимальна
• В тикеты можно добавлять подробные описания и вложения, необходимые для устранения багов
• Пользователи могут расставлять приоритеты, назначать тикеты членам команды, а также устанавливать и изменять сроки
• Легко управлять задачами, группируя их или создавая персонализированный список наблюдения
• Ветки комментариев позволяют отслеживать обсуждения, изменения и решения
• Члены команды получают уведомления обо всех добавлениях, изменениях статуса, комментариях и т. д. 
• Можно включить пользователей в уведомления об устранении багов, даже если не вы создали тикет и не вам его назначили
• Как и в Axosoft, есть возможность создавать вики-страницы для обмена знаниями
• Backlog предлагает готовые интеграции с различными инструментами коммуникации и разработки. Также пользователи могут создавать API для подключения Backlog к другим инструментам, если нет интеграции по умолчанию. 

❌ Минусы: 

• Интеграция с Git не слишком хороша, в результате бывают задержки в работе
• Фильтрация немного запутана, поэтому пользователи не всегда получают релевантные результаты
• Невозможно назначить задачу более чем одному пользователю. Альтернативное решение — создание подзадач, а это влияет на эффективность. 
• Нужно заново настраивать уведомления об обновлениях статуса для каждого изменения. 
• Новые пользователи ценят простоту этого инструмента, но со временем сталкиваются с нехваткой функций. 

Backlog предлагает несколько пользовательских планов, а также бесплатную версию (один проект с участием до десяти пользователей и 100 МБ дискового пространства). 

Итог

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

REQTEST

ReQtest — это не только облачная система отслеживания проблем, но и программное обеспечение для управления требованиями с выделенным модулем баг-репортов. 

Изюминкой этого инструмента является полная отслеживаемость требований, включая сопоставление багов, тестов и исправлений со спецификациями продукта. 

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

✅ Плюсы: 

• Приложение интуитивно понятное и логичное, поэтому его легко установить, настроить и использовать
• Модуль управления требованиями позволяет сортировать иерархию спецификаций, упрощая установку приоритета багов и напрямую связывая требования с тикетами
• Есть модули, позволяющие пользователям мгновенно писать тест-кейсы 
• Пользователи могут настраивать параметры и поток, создавая необходимые категории и поля
• Можно копировать незавершенные задачи из текущего спринта в следующий
• Есть десктопное приложение для «поимки» багов на скриншотах и видео
• Инструмент интегрируется с Jira, что еще больше упрощает сотрудничество между командами

❌ Минусы: 

• Ограниченные возможности настройки уровней пользователей и предоставляемых прав
• Трудно организовать тест-кейсы в рамках тестовых прогонов
• Слишком мало интеграций с другими инструментами
• Дизайн и UX можно и улучшить

ReQtest предлагает два платных плана и бесплатную 10-дневную пробную версию с доступом ко всем функциям. 

Итог

ReQtest может быть идеальным  решением для команд, ориентированных на требования. Модуль баг-трекинга имеет нужный функционал, а приложение для отслеживания ошибок — огромный бонус. Цена ReQtest немного больше, чем у большинства других систем баг-трекинга, но пользователи уверяют, что функциональность того стоит. 

MANTISBT

Mantis Bug Tracker — это инструмент с открытым исходным кодом, написанный на PHP. Несмотря на довольно простой внешний вид, он достаточно функционален и предлагает все необходимые функции для отслеживания ошибок. 

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

✅ Плюсы: 

• Поскольку код открыт, вы можете изменять все, что вам не нравится, добавлять функции, которые команда сочтет полезными, и подгонять инструмент под любую бизнес-логику.
• Используя базовую версию, можно отслеживать несколько проектов
• Легко создавать новые проекты и массово добавлять новых пользователей, а также отслеживать жизненный цикл багов
• Можно добавлять очень подробные описания багов, прикреплять скриншоты и документы
• Визуализация хорошая: можно видеть четкую картину приоритетов и статусов багов
• Рабочие процессы и доступ к проектам легко настраиваются
• Пользователи могут просматривать назначенные кому-либо тикеты, чтобы отслеживать  эффективность
• Фильтры продуманы до мелочей и очень практичны

❌ Минусы: 

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

MantisBT — это бесплатный инструмент. Дополнительные функции предоставляются платно. 

Провайдер также предлагает MantisHub — SaaS с большим количеством функций и несколькими тарифными планами. Баг-трекер — один из элементов его функциональности. 

Существует также бесплатная пробная версия MantisHub, хотя ее продолжительность не указана. 

Итог

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

BUGZILLA 

Bugzilla — одна из самых известных программ для отслеживания ошибок с открытым исходным кодом. Эта программа была представлена Mozilla еще в 1998 году. 

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

Плюсы: 

• Система легко настраивается, проста в установке и обслуживании
• Форма баг-репортов имеет все необходимые функции и поля для подробного описания бага
• Легко отслеживать ход исправления и жизненный цикл бага в целом
• Пользователи могут просматривать историю issue и получать уведомления по электронной почте при любых изменениях статуса
• Функция поиска позволяет находить issues по ключевым словам
• Пользователи могут оставлять комментарии в отдельных темах под каждым багом
• Инструмент автоматически обнаруживает повторяющиеся баги и сообщает о них
• Баг-репорты можно настроить в привязке к различным факторам 

❌ Минусы: 

• Иногда приложение тормозит
• Трудно переходить на новые версии
• Нет поддержки agile-разработки
• Интерфейс устарел, поэтому визуально не привлекателен и не очень удобен для пользователя 
• Крутая кривая обучения: пользователи с нетехническим образованием могут столкнуться с трудностями
• Прикладывать можно только изображения (по одному за раз)

Bugzilla доступна бесплатно. Пользователи также могут получить бесплатную поддержку. Если вам нужна поддержка более высокого уровня, ее предоставляют подрядчики, перечисленные на сайте Bugzilla. 

Итог

Bugzilla — это хорошее решение с открытым исходным кодом, имеющее все основные функции системы отслеживания ошибок.  Но пользователи должны быть готовы столкнуться с устаревшим интерфейсом и некоторыми сложностями настройки. В целом, это неплохая баг-трекинговая система. 

BUGHERD

BugHerd — это простая система отслеживания ошибок, применяемая в основном при тестировании сайтов. Изюминкой этого инструмента является его  визуализация, напоминающая доску с заметками. 

BugHerd устанавливается при помощи расширения или однострочного JavaScript-тега. Система размещается поверх сайта в качестве виртуального слоя. Пользователи могут закреплять комментарии со своими отзывами на веб-страницах, что упрощает обнаружение и исследование багов. Это также помогает поддерживать непрерывный рабочий процесс и эффективно общаться с членами команды. 

Плюсы: 

• Интерфейс интуитивно понятен и прост.
• Репорты тоже очень простые. Инструмент собирает информацию, необходимую команде для воспроизведения и исправления багов (браузер, ОС, данные селектора CSS и т. д.), и автоматически делает снимки экрана с точно определенной областью, в которой обнаружен дефект
• Пользователи управляют багами с помощью доски задач в стиле Kanban
• Легко поддерживать порядок в тикетах при работе над несколькими проектами 
• Инструмент обеспечивает эффективное сотрудничество независимо от размера команды
• BugHerd интегрируется с различными инструментами управления проектами и разработки

❌ Минусы: 

• На досках отсутствуют настраиваемые столбцы
• Интеграция с мобильными устройствами слишком медленная
• Отсутствует опция сортировки столбцов по пользователям (есть только по проектам)
• Инструмент часто обновляется, и иногда могут возникать сбои

BugHerd  имеет несколько вариантов ценообразования. Каждый из них предлагает разное количество пользователей и немного различающиеся функциональные возможности. Есть также 14-дневная бесплатная пробная версия. 

Итог

BugHerd имеет выдающиеся функции визуальной отчетности, которые делают его отличным инструментом для совместной работы и обратной связи при тестировании сайта. С его помощью сообщать о багах очень просто. Серьезных жалоб или негативных отзывов о BugHerd нет, но некоторым пользователям не хватает функционала. 

Самые большие ошибки, подобно толстым канатам, часто состоят из множества мелких. Возьмите канат и разделите его на нити, из которых он состоит, и вы сможете легко порвать их одну за другой. Вы подумаете: «Вот и все, что было!». Но скрутите эти нити вместе, и вы получите нечто потрясающее.

Введение

Идеальных программ не существует. Все люди грешны и все программисты делают ошибки в своих проектах. Даже идеально протестированная программа может дать сбой. Почему? Дело в том, что наши программы живут в окружении других программ, написанных другими программистами. Причем сейчас не идет речь о совместимости с ОС и аппаратными ресурсами. Вам сильно повезло, если вы знаете, с какими программами (интерфейсами) предстоит взаимодействовать вашему творению. Но ошибки могут быть и здесь.

Например, я сталкивался с ситуацией, когда моя программа, которую я много раз тестировал и прогонял по всевозможным юнит тестам, при переезде на другой сервер начинала работать совершенно неправильно. В чем может быть проблема? Во-первых, на сервере стояла более новая ОС, но для моей программы это было не страшно. Выяснилось, что ошибка происходит на несколько звеньев раньше в процессе вычислений. И скрипт, написанный другим программистом под более старую версию ОС, выдавал некорректные данные для моей программы. Это пример показывает, что ошибки в программе могут вызываться «внешним миром», в котором она живет. Однако мне повезло, ведь я прекрасно знал, что может влиять на работу программы. Ошибку я нашел достаточно быстро, т.к. мне хватило лишь проверки входных данных, чтобы узнать место в системе, где появился сбой.

Но бывает иначе. Ошибка, похожа на мину замедленного действия, которая ждет своего часа и находится в самых неожиданных местах. Достаточно вспомнить пример с выходом Service pack 3 для Windows XP. У небольшой группы пользователей это обновление ОС вызывало постоянную перезагрузку компьютера. Выяснилось, что все пострадавшие были владельцами компьютеров Hewlett-Packard с процессором AMD. Бывший менеджер по политике безопасности Microsoft Джеспер Йоханссон в своем блоге высказал возможные причины ошибки. Он предположил, что HP использовала при первоначальной инсталляции один и тот же образ как для компьютеров на базе Intel, так и на базе AMD. В результате получилось, что в обоих случаях за управление питанием компьютера отвечает файл intelppm.sys, однако Microsoft создавала этот файл для работы на процессорах Intel,  для процессоров AMD служит файл amdk8.sys. Это показывает, какими изощренными могут быть сбои, когда программный продукт предназначен для огромного числа пользователей. И ошибка не всегда может заключаться в программе.

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

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

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

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

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

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

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

• кто сообщил о проблеме;
• дата и время, когда была обнаружена проблема;
• серьёзность проблемы;
• описание неправильного поведения программы;
• кто занимается устранением проблемы;
• состояние ошибки.

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

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

Обзор

 В данном обзоре я рассмотрю несколько наиболее распространенных систем отслеживания ошибок:

• BUGS
• Bugzilla
• JIRA
• Trac
• Track Studio

BUGS — the Bug Genie

www.thebuggenie.com

Это свободная система отслеживания ошибок, распространяемая по Mozilla Public License 1.1. Для управления предоставляется веб-интерфейс. Система кроссплатформенная, написана на PHP. Проект достаточно успешно развивается, последняя версия BUGS вышла в марте 2008.

BUGS предоставляет базовый набор инструментов для регистрации ошибок, расстановки приоритетов, формировании задач для разработчиков. Эта система позволяет оповещать всех разработчиков, которые могут быть связаны с ошибкой. Система отслеживает ошибки в зависимости от версии и конфигурации ПО. Все ошибки сохраняются в единую БД, представляющую собой базу знаний об ошибках в проекте. Далее по этой БД можно формировать подробные отчеты. BUGS поддерживает возможность устанавливать blocker bugs — ошибки, которые могут блокировать выпуск релиза.

В последних версиях разработчики BUGS улучшили формат отчетов. Что особенно приятно: BUGS обладает user-friendly интерфейсом.  Для работы с этой BTS вам не потребуется копаться в горах мануалов.

Недостаток BUGS  — отсутствие распределенной многопользовательской работы. Невозможно работать удаленно с несколькими серверами или несколькими БД. В силу этого можно рекомендовать, BUGS для небольших команд разработчиков.  Благо BUGS это open source продукт и требует для своей работы стандартный набор: Apache, PHP, MySQL.

Bugzilla

www.bugzilla.org

Bugzilla – это одна из наиболее популярных систем багтрэкинга. В 1998 году Netscape представила первый релиз этой системы. Bugzilla является свободным ПО и распространяется по Mozilla Public License. Собственно, разработку этой системы сейчас ведет Mozilla Foundation.

Bugzilla пользуются более 800 (!) компаний по всему миру. Среди них встречаются такие гиганты как NASA, Id Software, Red Hat, Novell и другие. Почему же эта система пользуется такой популярностью?

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

Разработчик Bugzilla Max Kanat-Alexander в своем блоге указал, что одна из системных проблем Bugzilla – это выбор Perl в качестве языка программирования. Макс указывает, что принцип Perl TMTOWTDI(There More Than One Way To Do It) не всегда помогает в разработке, т.к. позволяет быстро реализовывать некоторые вещи, представляющие не всегда лучший выход из проблемы. Также Макс говорит о проблеме «читабельности» кода на Perl, которая усложняет поддержку перловых программ. Кроме того, программы, написанные на Perl, далеко не лучшим образом работают с памятью. Подробнее со всеми замечаниями можно ознакомиться здесь: http://avatraxiom.livejournal.com/58084.html.

Возвращаясь к обзору Bugzilla, отмечу, что, несмотря на все проблемы, Bugzilla работает достаточно устойчиво и предоставляет разработчикам неплохой базовый функционал:

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

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

С помощью Bugzilla достаточно просто управлять пользователями, обмениваться сообщениями с другими разработчиками внутри системы. Очень понравилось, что Bugzilla умеет визуализировать информацию: менеджерам очень понравятся всевозможные таблицы, графики и диаграммы, вид которых можно настраивать.

Bugzilla можно интегрировать с другими программами, для управления проектами:

• CVS
• Perforce SCM
• Subversion
• Tinderbox/Tinderbox2

 К недостаткам Bugzilla можно отнести сложность установки, зависимость от модулей Perl, сложность администрирования и несколько неприглядный интерфейс. Bugzilla для работы требует Apache, Perl и базу MySQL.

Систему Bugzilla можно рекомендовать достаточно широкому кругу пользователей, которых устроит стандартный набор функций. Этот проект активно развивается (последняя версия вышла в мае 2008), так что скоро можно будет ожидать добавления новых функций, которые сделают систему удобнее для использования. Bugzilla проверена временем, а это важный аргумент в пользу этой системы.

JIRA

www.atlassian.com/software/jira/

Систему отслеживания ошибок JIRA называют «bug tracking системой номер один». Попробуем разобраться, почему эта система от компании Atlassian заслужила такого звания.

Ответ будет простым: JIRA обладает на сегодняшний день наиболее широкой функциональностью среди систем отслеживания ошибок. В целом JIRA повторяет архитектуру Bugzilla. Процесс баг трэкинга следующий:

Создаваясь, сообщение обязательно имеет Assignie – ответственного, адресата (если такового не указать система в зависимости от настроек конкретного проекта либо автоматом «направит» сообщение, то есть адресует его, лидеру проекта (указывается при создании проекта), либо укажет необходимость выбрать адресата, если проект настроен так, чтобы сообщения не могли быть безадресными. «Получатель» может перенаправить его далее или вернуть писавшему («петля разработчик-тестировщик»).

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

Сообщения можно установить статус IN PROGRESS – в начале работы над ним, и соответственно указав, когда работы над ним закончены. Особо хочется указать на работу с версиями и статусами с точки зрения просмотра списков сообщений. Система поддерживает возможность создания персонифицированных сообщений.

Аккаунты пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы – то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление аттачей и создание комментариев для менеджеров из других проектов).

JIRA идеально подходит для крупных проектов, с большим штатом тестировщиков. Используя JIRA можно работать под различными ОС, создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект. JIRA можно успешно интегрировать с subversion.

Эта BTS обладает одним существенным недостатком: она платная. Стоимость установки JIRA на один сервер начинается от $1200. Однако, это не такая высокая цена для компании, которая способна оплатить штат тестировщиков. JIRA можно смело рекомендовать разработчикам больших распределенных проектов.

Trac

trac.edgewall.org

Trac – это открытое ПО, являющиеся одновременно инструментом для управления проектом и системой отслеживания ошибок. Проект Trac разрабатывается компанией Edgewall Software и распространяется по Modified BSD license.

Интерфейс Trac фактически представляет wiki. Система использует в работе SVN репозиторий, так что использовать его имеет смысл только вместе с svn.  Что же умеет Trac?

• разделение проекта на этапы (milestones)
• контроль выполнения (roadmap)
• все изменения по проекту заносятся на временную шкалу (timeline)
• поддержка RSS

Отчеты об ошибках можно заносить в тикеты. Среди прочего Trac позволяет: учет ошибок, замечаний, пожеланий с возможностью фильтрации и занесение соответственно в milestone, roadmap. В Trac реализован модуль просмотра репозитория, это существенно облегчает работу с SVN.

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

Track Studio

www.trackstudio.ru

Track Studio я включил в этот обзор, т.к. этот проект разработан российской компанией «ГРАН». Всегда интересно сравнивать зарубежные и российские разработки. Тем более, когда наш продукт ни в чем не уступает западным аналогам. Track Studio написан на Java и работает на UNIX и Windows NT. Как и Trac это не классическая система отслеживания ошибок, а комплексная система позволяющая управлять проектами и требованиями к ПО.  

В отличие от JIRA, оптимизированной для работы с внешними клиентами, Track Studio позволяет эффективно организовать работу внутри компании (например, обработку обращений клиентов). Track Studio позволяет эффективно управлять тысячами проектов: проекты можно организовывать в иерархию, можно делать поиск проектов по параметрам, к проектам можно прикладывать файлы (например, с техническим заданием), для проектов можно создавать пользовательские поля (дата релиза, клиент, номер договора) и многое другое. Одно из преимуществ состоит в том, что Track Studio хорошо поддерживает БД Oracle. В ORACLE нельзя создать текстовые поля длиннее 4000 байт, однако описания проблем и различные служебные данные в JIRA и Track Studio могут достигать десятков килобайт. Track Studio разбивает длинные текстовые поля на куски по 1800 символов, которые хранит отдельными записями в специальной таблице. Этот способ является быстрым, простым в реализации и очень удобным в использовании.

Какие недостатки у Track Studio? В Track Studio сложно осуществлять интеграцию с другими средами разработки. Кроме того у программы достаточно сложный интерфейс.

Цены на Track Studio начинаются от $500, что является существенным преимуществом по сравнению с JIRA. Эту систему имеет смысл использовать при разработке крупных проектов, когда возникает потребность задействовать все фичи, входящие в состав Track Studio.

Сравнительный анализ

Выводы

Если вы еще не используете систему отслеживания ошибок – вам стоит о ней серьезно задуматься, т.к. в первую очередь это увеличивает производительность программистов, систематизирует и автоматизирует борьбу с ошибками. Если вы программист-фрилансер попробуйте использовать бесплатную программу BUGS. Средним проектам наверняка пригодится Bugzilla, по крайней мере она удовлетворяет большинству требований к BTS. Крупным командам разработчиков, которые взаимодействуют с отделами тестирования и поддержки конечных пользователей, понадобится JIRA. Ну а если кроме багтрекинга вы хотите вести учет продвижения разработки проекта и руководить задачами программистов, то есть смысл выбрать систему подобную Trac или Track Studio.

Но в любом случае, начинайте использовать систему отслеживания ошибок! Если вы программист, вы оцените, сколько времени вы будете экономить в борьбе с ошибками, используя BTS. Если же вы менеджер ИТ проекта BTS поможет вам наиболее полно контролировать процесс разработки ПО.

Оригинал статьи

1. Системы отслеживания ошибок. Основные понятия. Обзор.

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

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

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

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

• серьёзность(критичность)
  проблемы;

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

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

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

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

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

1. Система отслеживания ошибок Bugzilla.

Bugzilla
— свободная система отслеживания ошибок
(багтрекинга) с веб-интерфейсом.

В
1998 году Bugzilla
была выпущена как открытое программное
обеспечение компанией Netscape.
В настоящее время система разрабатывается
«The
Mozilla
Foundation».

Bugzilla
— это хорошо продуманная и оттестированная
система, с одной стороны она довольно
проста, с другой стороны, там есть всё,
что нужно для багтрекинга типичного
проекта. Сейчас Bugzilla
используют более трёхсот компаний и
организаций по всему миру, среди них
есть такие компании как: NASA,
Id
Software,
IBM
и софтверные проекты: Mozilla
Firefox,
Linux,
Gnome,
KDE,
Apache
Project,
OpenOffice.org.

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

Ключевым
понятием системы является баг — некоторое
задание, запрос, рекламация по поводу
ошибки в системе, или просто сообщение,
требующее обратной связи.

Для
работы Bugzilla
требуются:

• веб-сервер
  (например, Apache);

• поддержка
  языка Perl;

• база
  данных MySQL
  или Oracle
  (экспериментально).

1. Система управления задачами jira.

Atlassian
JIRA
— система отслеживания ошибок,
предназначена для организации общения
с пользователями, хотя в некоторых
случаях систему можно использовать для
управления проектами. Разработана
компанией Atlassian
Software
Systems.
Платная. Имеет веб-интерфейс. Название
системы (JIRA)
было получено путём модификации названия
конкурирующего продукта — Bugzilla.
JIRA
создавалсь в качестве замены Bugzilla
и во-многом повторяет архитектуру
Bugzilla.
Система позволяет работать с несколькими
проектами. Для каждого из проектов
создаёт и ведёт схемы безопасности и
схемы оповещения.

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

Основные
детали:

• сильный,
  понятный пользовательский интерфейс;

• хорошая
  расширяемость;

• упраление
  ошибками, проблемами, задачами.

Основные
понятия:

• задача
  (task);

• движение
  проблемы (workflow);

• шаг;

• переход.

Соседние файлы в предмете CASE-технологии

• #
• #
• #
• #