Багтрекинговые системы что это
4 лучших багтрекера или как QA эффективно отслеживает ошибки
Чем больше задач, проектов, клиентов, тем серьезнее встает этот вопрос: как систематизировать информацию о всех тасках и обнаруженных багах для учета рабочего времени, так называемых человеко-часов и возможности видеть картину в целом для расставления приоритетов.
В настоящее время без багтрекера невозможно представить работу как начинающего, так и опытного QA инженера. Для построения правильного процесса тестирования багтрекер просто необходим. Но как выбрать именно тот, единственный и неповторимый, который будет с тобой каждый день и с которым можно строить планы на будущее? Мы все еще о багтрекере. Так вот, чтобы помочь себе и сократить ваше время на поиски идеального багтрекера в столь изобилующем багтрекерами современном мире, мы подготовили небольшой обзор, основанный на нашем опыте и популярности систем. Мы выделим их ключевые особенности, а также в конце поделимся таблицей сравнения, которая помогла нам систематизировать багтрекеры и выбрать лучший для наших потребностей.
Redmine
Не можем умолчать тот факт, что мы сами пользуемся Redmine. Мало того что он бесплатный, но и нареканий не вызывал, и недостатков особых за 3 года использования нами обнаружено еще не было.
Bontq
YouTrack
Желаем вам выбрать вашего лучшего друга-багтрекера.
Анастасия Филатова, QA Engineer ROI4CIO
Не баг-трекер, а…
Настоящий IT-шник всегда любит сварить «кашу из топора». А если этой кашей еще и получается вкусно накормить коллег, то выходит вообще замечательно.
По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.
С этой темой я уже выступал на конференции SQADays, но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.
Смысл?
Disclaimer
Примеры, которые пойдут дальше, взяты из реальной жизни. Но успешное внедрение у кого-угодно никак не означает, что и у вас все пойдет как по маслу. Не забывайте думать, пробовать и советоваться со старшими товарищами.
Ну и сразу попрошу прощения, что частенько упор пойдет на использование JIRA (можете кинуть в меня помидор), т.к. эту систему я использую на повседневной основе, но и другие баг-трекеры не были забыты — практически все нижеописанное можно сделать и с их помощью.
Поехали!
HelpDesk
Наиболее частым, не совсем стандартным, применением баг-трекера, которое мне приходилось наблюдать, было использование его в качестве HelpDesk-а в службе технической поддержки.
Из плюсов такого применения можно отметить удобство связывания обращений в HelpDesk и багов, по ним заведенных (интеграции с HelpDesk-ами с каждым днем хорошеют, но идеала все нет), и отсутствие необходимости учить техподдержку работать с двумя системами. Но нужно понимать, что такая система будет чуть менее удобна, чем отдельный HelpDesk, и если вам приходится работать с большим количеством обращений, большинство из которых решается службой поддержки самостоятельно, то лучше смотреть на отдельную HelpDesk-систему.
Ближе к делу. Как такую систему можно настроить?
Использование этих плагинов/обработчиков позволяет парсить письма, сохранять тему письма в теме созданной заявки, аттачить вложения из письма к заявке, привязывать ответные сообщения к соответствующим заявкам.
Но даже если вы не планируете разворачивать у себя HelpDesk, попробуйте использовать создание и комментирование заявок через email в повседневной работе. Некоторые находят это очень удобным.
Для JIRA отдельно стоит отметить плагин Issue Collector, который позволяет настроить удобные формы обратной связи для последующего размещения у себя на сайте.
К сожалению, плагин еще сыроват и не во всех случаях может надежно работать.
Наличие службы поддержки обычно подразумевает и наличие SLA (Service Level Agreement), по которому вы обязаны решать инциденты за строго определенное время. А для искоренения забывчивости администраторы, с подачи руководства, настраивают всякие напоминалки:
Бюрократия
Согласования, отфутболивания, заявки, многоуровневые иерархии сотрудников, что может быть лучше… для автоматизации? На самом деле, автоматизация каких-то бюрократических моментов организации, если и не помогает сделать их проще, то уж прозрачнее так точно делает.
Доводилось видеть баг-трекеры, с помощью которых делали согласование закупок оборудования, отслеживание бюджета проекта, работу с документами и т.п.
В основе такой кастомизации обычно лежит создание своего Workflow — жизненного цикла заявки. Т.е. какие состояния у заявки есть и какие переходы могут быть между ними. Кроме того, благодаря настройке прав доступа отдельные переходы можно разрешить только для специально обученных ответственных товарищей.
Помогает создание своего workflow и в ежедневной рутине разработчика. Например, могут быть введены новые промежуточные состояния для задач вроде «в тестировании» или «идет приемка заказчиком».
Новые типы заявок (например, «согласование документа», «закупка», «проектирование» или «тестирование») позволяют не только сделать процесс работы более наглядным, но и привязать к каждому типу заявки отдельный Workflow. Так если для задачи «разработка» имеет смысл ввести состояние «тестирование» в жизненном цикле, то для задачи «дизайн» такое может и не понадобится.
Почтовые рассылки
Баг-трекер это не только ценный инструмент, но обычно и система почтовых нотификаций, в него встроенных. И эти нотификации можно использовать себе во благо для создания почтовых рассылок внутри организации. Рецепт прост:
Дележ ресурсов
Вам определенно следует позаботиться о контроле за ресурсами, если одни и те же сервера часто одновременно используются для различных нагрузочных тестов, либо два сотрудника одновременно пытаются забрать один и тот же iPad в командировку для демонстрации.
Воспитывать совесть у коллег с помощью баг-трекера сложно, но повысить уровень организации можно. Рецепт:
Естественно, никто не может запретить человеку забрать ресурс и «не отметиться в системе», но с помощью доброго слова и удобного инструмента можно сделать больше, чем с помощью одного доброго слова.
Голосования
Довольно распространенную функцию голосования за реализацию тех или иных заявок тоже можно использовать себе на благо. Если вы задались вопросом «куда пойти на корпоратив» или «что подарить директору на день рождения», то можете смело использовать баг-трекер (убедитесь только, что директор им не пользуется :). Рецепт:
JIRA и Bugzilla имеют встроенную функцию для голосований. Для Redmine есть плагин.
Тест-менеджмент
Есть любители использовать баг-трекер в качестве системы для хранения набора регресcионных тестов, которые нужно выполнять вручную на каждой очередной версии продукта. Сам я не фанат такого способа, но раз люди используют, то что-то в этом есть. Рецепт:
Плюсы такого решения: очень удобно из тестов ссылаться на заявки/баги в баг-трекере, нельзя закрыть версию, в которой есть «незакрытые» тесты. В целом может быть не так удобно, как специализированная система для тест-менеджмента.
Технические возможности расширения
Кроме возможностей по настройке баг-трекеров (а все предыдущие рецепты по сути настройки) часто есть возможность расширить функциональность баг-трекера и программно.
Все основные баг-трекеры имеют интерфейсы для удаленного доступа, которые можно использовать для какой-то своей автоматизации. Например, автоматически постить заявки по каким-то событиями или из внешних систем.
Кто не хочет заморачиваться с программированием, может использовать для автоматизации клиенты командной строки:
Для разжигания холиваров скажу, что самый развитый клиент у JIRA 🙂
Опять-таки здесь JIRA впереди планеты всей. В основном благодаря экосистеме для разработчиков плагинов, которая при должном уровне подготовки позволяет очень здорово кастомизировать поведение JIRA и добавлять всякие «полезности» и «свистелки».
Итоги
Пару мыслей, которые я хотел донести до слушателей на SQADays и до читателей на Хабре:
А в комментариях буду рад увидеть какие-то нестандартные использования баг-трекеров, которые попадались Хаброжителям.
Багтрекинговые системы что это
9 систем баг-трекинга, которые помогут тестировщику оформить и сохранить все найденные баги.
Каждый день тестировщики создают десятки и сотни баг-репортов (отчетов об ошибках). Эти отчеты копятся, копятся и копятся. Задумывались о том, где лучше всего их хранить?
С этой задачей нам помогут справиться баг-трекинговые системы, которых на рынке сейчас достаточно много. Рассмотрим самые популярные и удобные из них.
Jira
Изначально Jira предназначалась только для отслеживания ошибок. Однако сейчас она также используется для планирования agile-проектов.
Это платная система. Но есть тариф “Free” с возможностью добавления 10 пользователей.
Jira представляет собой интерактивную доску (Дашборд), с помощью которой можно следить за выполнением поставленных задач. Все задачи классифицируются различными видами функций, подзадач, багов и т.д. Они могут редактироваться, назначаться на различных исполнителей или просто изменять статус с «открыт» на «закрыт». Все изменения по задаче записываются в журнал.
Плюсы:
— Широкий функционал, который можно дополнительно расширить с помощью плагинов.
— Интеграция с различными системами (Git, Zephyr, Trello, Slack, Google Drive & Docs, draw.io и так далее).
— Есть возможность строить диаграмму Ганта.
— Рабочие столы можно настроить под себя.
— Позволяет составлять план работы.
— Возможность искать задачи по гибким фильтрам.
— Наличие мобильного приложения.
— Связывание задач/ошибок.
— Уведомления по электронной почте.
— Пользователи получают последние обновления о ходе выполнения проектов.
Минусы
— Сложность настройки и обслуживания, особенно для малого бизнеса и небольших команд.
— Иногда тяжело найти то, что нужно (из-за огромного количества функций).
— Требуется много времени, чтобы научиться эффективно использовать.
Redmine
Это бесплатное веб-приложение. И это больше, чем просто трекер ошибок. Redmine — решение для управления проектами с открытым исходным кодом и существует он уже более десяти лет. Написан на Ruby и совместим с MySQL, PostgreSQL, Microsoft SQL и SQLite.
Баг-репорт может отслеживаться любым сотрудником, который добавлен в проект и отмечен как наблюдатель.
Плюсы:
— Есть возможность установить дополнительные плагины для расширения функционала.
— Удобный пользовательских интерфейс.
— Возможность планирования с помощью диаграммы Гантта.
— Ленты и уведомления по электронной почте.
— Многоязычный интерфейс (поддерживает 34 разных языка).
— Поддержка нескольких баз данных.
— Учет временных затрат.
— Гибкая система отслеживания проблем.
Минусы:
— Некоторые функции очень скрыты.
— Сложно разобраться в установке на сервер.
— На больших объемах данных, пользователей или количестве подключенных плагинов начинает снижаться производительность.
— Отсутствуют оповещения об изменении документов.
— Слабо развита система предоставления прав пользователя (например, ограничения доступа к определенным задачам проекта).
Mantis
Бесплатный инструмент. По сравнению с другими баг-трекинговыми системами, это довольно простой инструмент. Он доступен как в виде web-приложения, так и в мобильной версии. Баг-репорт можно назначить на любого пользователя, который работает в проекте.
Инструмент построен на PHP и совместим с базами данных MySQL и PostgreSQL. Его также можно настроить для управления проектами.
Плюсы:
— Открытый исходный код.
— Возможность настройки полей.
— Поддержка time tracking.
— Возможность работы в нескольких проектах одновременно.
— Доступная история изменений в отчетах.
— Неограниченное количество пользователей, проектов и баг-репортов.
— Управление доступом, которое можно изменить для каждого проекта.
— Настраиваемые поля проблем.
— Многофункциональная мобильная версия (iPhone, Android и Windows Phone).
— Есть плагины, которые значительно улучшают использование инструмента.
Минусы:
— В процессе создания отчета об ошибке можно прикрепить только один снимок экрана. Можно прикрепить еще один к уже созданному сообщению об ошибке.
— Пользовательский интерфейс не привлекателен.
— Нет возможности сгенерировать отчет о проделанной работе.
— Нет возможности отслеживать что-то автоматически.
Trac
Открытая бесплатная веб-система для контроля багов и разработки софтверных продуктов. Есть русская локализация.
Trac специально создан для проектов разработки и отслеживания проблем, но также может использоваться для управления документами. Он имеет минималистский дизайн, встроенную вики и интегрируется с Apache Subversion и GitHub.
Можно связать ошибки с различными задачами, файлами, страницами вики или ошибками. Trac написан на Python и совместим с SQLite, MySQL и PostgreSQL.
Плюсы:
— Поддержка нескольких платформ: Linux, Unix, Mac OS X, Windows и т.д.
— Перекрестные ссылки между базой данных зарегистрированных ошибок, системой контроля версий и вики-страницами.
— Мониторинг и управление прогрессом.
— Параметры управления пользователями.
— Подсветка кода и сравнение файлов.
— Большое количество плагинов.
Минусы:
— Несколько проектов не могут быть обработаны.
— Ограниченная функциональность, если не использовать все его плагины.
— Комплексная установка.
Яндекс.Трекер
Сервис для управления проектами по методологии Agile. Платный, но предоставляется бесплатный доступ на 30 дней.
Пользователи могут создавать задачи, описывать их, назначать исполнителей и наблюдателей, а также комментировать ход решения вопроса в карточке задачи. Гибкие настройки прав доступа. Высокая производительность.
Плюсы:
— Живые задачи в реальном времени.
— Очереди задач для группировки.
— Фильтры и поиск.
— Дашборды, визуализация прогресса, agile-доски.
— Учёт времени и трудозатрат.
— Напоминания и призывы.
— Просмотр истории изменений.
— Интеграция с GitHub, возможность добавлять вызовы API в программы, написанные на языке Python (то есть можно легко перенести данные из другого инструмента).
— Есть дополнительные плагины.
— Возможность ограничить доступ к задачам с конфиденциальной информацией.
— Мобильное приложение для iOS и Android.
Минусы:
— Довольно «сырое» мобильное приложение, ряд действий можно осуществлять только с ПК.
Zoho
Платная система, но при регистрации до 3-х пользователей предусмотрен бесплатный тариф. Zoho Issue Tracker является неотъемлемым модулем для программного обеспечения Zoho Projects. Это облачная сквозная система, которая позволяет сообщать об ошибках, управлять рабочими процессами и исправлять дефекты.
Плюсы:
— Гибкий рабочий процесс.
— Разные категории вопросов.
— Пользовательские циклы управления ошибками.
— Подробные отчеты.
— Гибкая система фильтрации: серьезность, категория и т.д.
— Многофункциональное мобильное приложение.
— Интуитивно понятный интерфейс.
— Просмотр статистики пользователя.
— Интеграция с Bitbucket и GitHub.
— Автоматический багтрекер. Позволяет установить правила для запуска обновлений в полях ошибки или в сторонних приложениях.
— Уведомления по электронной почте об изменениях.
Минусы:
— Проблемы с поддержкой клиентов из разных часовых поясов.
— Дополнительная плата за Zoho Reports.
— Сложно учиться.
YouTrack
Платный баг-трекер с возможностью пользоваться бесплатной ограниченной версией. Поддерживает Scrum и Kanban, а также работу по собственной (свободной) методике. Обеспечивает контроль просроченных задач, диаграммы «выгорания задач» и кумулятивного потока исполнения, поддержку вложенных задач, а также возможность обслуживания нескольких проектов в одной контрольной панели.
Доступен в виде облачного сервиса, либо в виде веб-приложения для установки на собственный веб-сервер.
Плюсы:
— Хорошо настроенный инструмент.
— Интеллектуальный поиск.
— Экспорт в CSV.
— Тайм-менеджмент.
— Специальные команды для быстрой смены нескольких задач одновременно.
— 17 видов отчетов.
— Специальные теги для группировки вопросов.
— Создание вопросов по электронной почте.
— Логическое связывание задач.
— Режим вики.
Минусы:
— Поддержка недостаточна даже в платных версиях.
— Нет отслеживания вех.
— Проекты имеют публичный статус в бесплатной версии.
Trello
Веб-приложение, которое изначально было предназначено для управления проектами небольших групп. Платная система, но есть бесплатный тариф с определенными ограничениями.
Проекты распределяются на доски, которые выглядят очень наглядно. На досках задачи можно распределять по колонкам по принципу доски в канбан: новые задачи, задачи в очереди, задачи в работе, завершенные задачи и так далее.
Атрибуты, как таковые, в данной системе не предусмотрены. Но для присвоения серьезности или приоритета можно использовать цветовые маркеры. На доски добавляются определенные пользователи, которые закрепляются за задачами, где пишут комментарии по ходу выполнения.
Плюсы:
— Freemium-модель.
— Наглядность в ходе выполнения задачи.
— Возможность работы на нескольких досках.
— Интеграция с различными сервисами.
— Система построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии.
Минусы:
— Система построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Да, это плюс и минус одновременно. Когда количество баг-репортов измеряется сотнями, смотреть “все на одном экране” становится неудобно.
— Слишком простая и не предназначена для больших команд. Задачи банально не имеют номера, не говоря уже о переводе или установке на свой сервер.
Google Таблицы
Универсальный бесплатный инструмент. Если проект небольшой и в нем не так много баг-репортов, то Google Таблицы подойдут.
Плюсы:
— Бесплатно.
— Полная свобода творчества.
Минусы:
— Нет возможности интеграция с различными программами.
— Нет возможности учитывать время.
________
У каждой баг-трекинговой системы есть свои преимущества и недостатки. Достаточно изучить одну любую систему, чтобы понять принцип работы остальных. Как только вы поймете принцип, то на освоение новой системы у вас будет уходить совсем немного времени.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Система отслеживания ошибок
Содержание
Общее описание BTS (bug traking systems)
BTS помогает программисту следить за ошибками. Когда вы замечаете ошибку, необходимо собрать о ней максимальное количество доступной информации. Необходимо быть предельно точным в наблюдениях. Особенно это касается отчетов об ошибках, приходящих от пользователей.
Как правило, BTS позволяет хранить информацию об ошибке в следующем виде:
Это минимальный набор требований к БД BTS, на самом же деле многие системы багтрэкинга позволяют вести намного более подробный учет ошибок. В чем то, они напоминают системы управления проектами. А многие из них интегрированы с такими системами.
Необходимо заметить, что системы отслеживания ошибок могут быть полезны не только для программистов. Отчеты о «работе над ошибками» могут использовать менеджеры проекта. Фактически такие отчеты позволяют судить о производительности программистов, при работе по улучшению работы ПО. При обработке отчетов необходимо учитывать приоритет ошибок и сложность их устранения. Менеджер должен понимать, что некоторые ошибки могут быть трудно устранимы, в силу архитектуры системы. Бессмысленно требовать скорейшего устранения ошибок в системных модулях: непродуманные действия по устранению одной ошибки могут породить сотни других ошибок.
Состав информации о дефекте
Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения могут включать в себя:
Кроме того, развитые системы предоставляют возможность прикреплять файлы, помогающие описать проблему (например, дамп памяти или скриншот).
Жизненный цикл дефекта
Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка.
Типичный жизненный цикл дефекта:
4. далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус назначен (если он описан как исправленный, но не исправлен), либо в статус закрыт. 5. открыт повторно — дефект вновь найден в другой версии.
Система может предоставлять администратору возможность настроить, какие пользователи могут просматривать и редактировать ошибки в зависимости от их состояния, переводить их в другое состояние или удалять. В корпоративной среде система отслеживания ошибок может использоваться для получения отчётов, показывающих продуктивность программистов при исправлении ошибок. Однако, часто такой подход не даёт достаточно точных результатов, потому что разные ошибки имеют различную степень серьёзности и сложности. При этом серьёзность проблемы не имеет прямого отношения к сложности устранения ошибки. [Источник 2]
Примеры bug traking systems (систем отслеживания ошибок)
Существует большое разнообразие bug traking систем, вот далеко не полный их список:
Свободно распространяемые BTS (bug traking systems):
Платные BTS (bug traking systems):
Обзор багтрекерных систем (Bug tracking system)
Обзор Redmine
Redmine — открытое приложение для управления проектами, включающее в себя систему отслеживания ошибок. Функциональность решения такова, что оно подойдёт достаточно крупным компаниям.
и многое другое. Задачи в Redmine могут быть взаимосвязаны. Предусмотрены следующие варианты связей: дублирование, простая связка, блокировка, предшествование, следование. Это охватывает практически все возможные варианты и позволяет оптимизировать работу в том числе и по исправлению ошибок. Код программы опубликован на GitHub и распространяется по GPL v.2. [Источник 4]
Обзор Bugzilla
Bugzilla — одна из наиболее популярных систем отслеживания ошибок. Она была создана ещё в 1998 г. компанией Netscape. В настоящее время ее поддержкой и развитием занимается Mozilla Foundation.
Bugzilla предоставляет пользователю следующие возможности:
Несмотря на некоторые недостатки, Bugzilla успешно применяется в весьма крупных проектах: Mozilla Firefox, GNOME, KDE, OpenOffice.org и даже развитие ядра Linux. Распространяется приложение на условиях Mozilla Public License.
Разработчик Bugzilla Max Kanat-Alexander в своем блоге указал, что одна из системных проблем Bugzilla – это выбор Perl в качестве языка программирования. Макс указывает, что принцип Perl TMTOWTDI (There More Than One Way To Do It) [17] не всегда помогает в разработке, т.к. позволяет быстро реализовывать некоторые вещи, представляющие не всегда лучший выход из проблемы. Также Макс говорит о проблеме «читабельности» кода на Perl, которая усложняет поддержку перловых программ. Кроме того, программы, написанные на Perl, далеко не лучшим образом работают с памятью. Возвращаясь к обзору Bugzilla, стоит отметить, что, несмотря на все проблемы, Bugzilla работает достаточно устойчиво и предоставляет разработчикам неплохой базовый функционал:
Система предоставляет отличную базу знаний для ошибок, по которой можно весьма легко формировать отчеты. Bugzilla имеет стандартный веб-интерфейс. С помощью Bugzilla достаточно просто управлять пользователями, обмениваться сообщениями с другими разработчиками внутри системы. Очень понравилось, что Bugzilla умеет визуализировать информацию: менеджерам очень понравятся всевозможные таблицы, графики и диаграммы, вид которых можно настраивать.
Bugzilla можно интегрировать с другими программами, для управления проектами:
К недостаткам Bugzilla можно отнести сложность установки, зависимость от модулей Perl, сложность администрирования и несколько неприглядный интерфейс. Bugzilla для работы требует Apache HTTP Server, Perl и базу MySQL.
Систему Bugzilla можно рекомендовать достаточно широкому кругу пользователей, которых устроит стандартный набор функций. Этот проект активно развивается (последняя версия вышла в мае 2008), так что скоро можно будет ожидать добавления новых функций, которые сделают систему удобнее для использования. Bugzilla проверена временем, а это важный аргумент в пользу этой системы.
Обзор Mantis
Mantis — распространённый баг-трекер, написанный на PHP. Также программа может использоваться для учёта заданий и контроля за их выполнением. Иногда это решение применяется для организации Helpdesk.
Программа отличается удобным и функциональным интерфейсом, хотя некоторые пользователи отмечают, что выглядит он достаточно «угрюмо». Тем не менее, юзабилити решения достаточно высоко — практически все операции требуют минимального числа действий. Однако не все настройки программы можно выполнить через веб-интерфейс. Эффективная работа с приложением требует хотя бы начальных знаний PHP. Mantis поддерживает работу с несколькими проектами. Несмотря на то, что система не содержит в себе Wiki, она может быть интегрирована со многими популярными платформами. Исходный код опубликован на GitHub. Распространяется приложение на условиях GPL v.2.
Это свободная система отслеживания ошибок, распространяемая по Mozilla Public License 1.1. Для управления предоставляется веб-интерфейс. Система кроссплатформенная, написана на PHP. Проект достаточно успешно развивается, последняя версия BUGS вышла в марте 2008.
Обзор JIRA
Систему отслеживания ошибок JIRA называют «bug tracking системой номер один». Попробуем разобраться, почему эта система от компании Atlassian заслужила такого звания.
Ответ будет простым: JIRA обладает на сегодняшний день наиболее широкой функциональностью среди систем отслеживания ошибок. В целом JIRA повторяет архитектуру Bugzilla. Процесс баг трэкинга следующий:
Создаваясь, сообщение обязательно имеет Assignie – ответственного, адресата (если такового не указать система в зависимости от настроек конкретного проекта либо автоматом «направит» сообщение, то есть адресует его, лидеру проекта (указывается при создании проекта), либо укажет необходимость выбрать адресата, если проект настроен так, чтобы сообщения не могли быть безадресными. «Получатель» может перенаправить его далее или вернуть писавшему («петля разработчик-тестировщик»). Каждому Issue можно поставить приоритет важности, адресовать на себя, добавить комментарий. При чём как общий комментарий, видимый всеми, так и комментарий направленный одному человеку – очень приятная фишка, когда ведущий разработчик переадресует сообщение своему коллеге, указывая какую-то техническую подробность, которая нужна только ему. Сообщения можно установить статус IN PROGRESS – в начале работы над ним, и соответственно указав, когда работы над ним закончены. Особо хочется указать на работу с версиями и статусами с точки зрения просмотра списков сообщений. Система поддерживает возможность создания персонифицированных сообщений.
Аккаунты пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы – то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление аттачей и создание комментариев для менеджеров из других проектов).
JIRA идеально подходит для крупных проектов, с большим штатом тестировщиков. Используя JIRA можно работать под различными ОС, создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект. JIRA можно успешно интегрировать с subversion.
Эта BTS обладает одним существенным недостатком: она платная. Стоимость установки JIRA на один сервер начинается от 1200$. Однако, это не такая высокая цена для компании, которая способна оплатить штат тестировщиков. JIRA можно смело рекомендовать разработчикам больших распределенных проектов. [Источник 6]
Обзор Trac
Trac — система управления проектом со встроенным механизмом отслеживания ошибок, поддерживаемая компанией Edgewall Software [22] и распространяется по Modified BSD license. Концепция решения — разумный минимализм и модульное построение.
Trac включает в себя модули управления задачами, просмотра репозиториев и организации взаимодействия. При необходимости функциональность может быть расширена за счёт специальных дополнений. Написанная на Python система Trac может интегрировать возможности по отслеживанию ошибок с Wiki и инструментарием управления версиями. Решение позволяет создавать дорожные карты и разнообразные отчёты. Распространяется приложение на условиях модифицированный лицензии BSD.
Система использует в работе SVN репозиторий, так что использовать его имеет смысл только вместе с SVN. Trac может:
Отчеты об ошибках можно заносить в тикеты. Среди прочего Trac позволяет: учет ошибок, замечаний, пожеланий с возможностью фильтрации и занесение соответственно в milestone, roadmap. В Trac реализован модуль просмотра репозитория, это существенно облегчает работу с SVN.
Обзор Track Studio
Track Studio я включил в этот обзор, т.к. этот проект разработан российской компанией «ГРАН». Всегда интересно сравнивать зарубежные и российские разработки. Тем более, когда наш продукт ни в чем не уступает западным аналогам. Track Studio написан на Java и работает на UNIX и Windows NT. Как и Trac это не классическая система отслеживания ошибок, а комплексная система позволяющая управлять проектами и требованиями к ПО.
Обзор Devprom
Devprom – система управления жизненным циклом программного обеспечения, нацеленная на построение и поддержку эффективных процессов гибкой разработки.
Объединение участников команд для более тесного взаимодействия;
Полный обзор багтрекерных систем (Bug tracking system)
Сравнение систем отслеживания ошибок
Системы управления проектами
Выводы
Если вы еще не используете систему отслеживания ошибок – вам стоит о ней серьезно задуматься, т.к. в первую очередь это увеличивает производительность программистов, систематизирует и автоматизирует борьбу с ошибками. Если вы программист-фрилансер попробуйте использовать бесплатную программу BUGS. Средним проектам наверняка пригодится Bugzilla, по крайней мере она удовлетворяет большинству требований к BTS. Крупным командам разработчиков, которые взаимодействуют с отделами тестирования и поддержки конечных пользователей, понадобится JIRA. Ну а если кроме багтрекинга вы хотите вести учет продвижения разработки проекта и руководить задачами программистов, то есть смысл выбрать систему подобную Trac или Track Studio.