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 и до читателей на Хабре:
А в комментариях буду рад увидеть какие-то нестандартные использования баг-трекеров, которые попадались Хаброжителям.
GitLab 8.11: канбан-доска и разрешение конфликтов одним кликом
Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8
В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования!
Итак, в новой версии появились:
MVP этого месяца — Clement Ho. Спасибо ему за мерж-реквесты и отзывчивость в работе над задачами.
Доска тикетов (Issue Board)
Тикеты (issues) в GitLab — очень гибкий инструмент. Они могут содержать ссылки друг на друга, можно обозначить их приоритеты, можно отсортировать по популярности. Доска тикетов добавляет новый способ работы с ними.
Теперь можно настраивать рабочие процессы (workflows) и быстро получать информацию о состоянии тикетов. Всё это доступно на простой и приятной глазу доске, похожей на те, что используются в Канбане или Скраме.
Доска создается для каждого проекта автоматически. По умолчанию все открытые тикеты формируют список-бэклог (Backlog), а все закрытые появляются в списке завершённых (Done list).
Добавляя новые списки, вы создаёте новые рабочие процессы. Принадлежность тикета к списку определяется меткой. При добавлении тикета в список к ней добавляется соответствующая метка, при удалении из списка — метка удаляется.
Если хотите посмотреть на эту фичу в действии, загляните на доску GitLab CE версии 8.12.
Разрешение конфликтов при мерже
Мержи в крупных и активно разрабатываемых проектах обычно вызывают много проблем. Мы хотим, чтобы у вас был встроенный инструмент для разрешения конфликтов. Поэтому теперь можно это делать прямо в интерфейсе GitLab.
Когда мерж блокируется конфликтом, можно просто нажать кнопку «Resolve these conflicts» и перейти в интерфейс разрешения. Там можно выбрать нужные строки и закоммитить полученный результат.
Разумеется, так получится разрешить далеко не все конфликты. Но мы надеемся, что в большинстве случаев этот инструмент поможет вам ускорить прохождение мерж-реквестов.
Разрешения на работу с ветками для конкретных пользователей (только EE)
Теперь в Enterprise Edition можно настраивать разрешения на пуш или мерж в ветку не только для подгрупп пользователей (как developers или owners ), но и для конкретных пользователей.
Новые настройки можно совмещать с другой функциональностью, в том числе с разрешениями для подгрупп. Например, можно разрешить пушить непосредственно в ветку только тимлидам Пете и Маше, но подтверждать мерж-реквесты в эту ветку — всем членам группы уровня developer и выше.
Для каждого действия (пуш и мерж) можно настроить любое количество авторизованных пользователей.
«Закрытие» комментариев в мерж-реквестах.
В мерж-реквестах бывают длинные ветки комментариев, в которых можно запутаться. Но каждый из них важен.
Мы добавили возможность отметить комментарий или целую ветку как обработанную и закрыть её.
В мерж-реквестах теперь также есть счётчик незакрытых обсуждений и удобная кнопка перехода к к следующему открытому обсуждению.
Схемы конвейеров.
Конвейеры в GitLab могут иметь достаточно сложную структуру с множеством последовательных и параллельных сборок. Теперь можно посмотреть на схему конкретного конвейера, отображающую его строение и состояние. Такая схема наглядно показывает происходящие в нём процессы.
Просто кликните на конвейере на странице мерж-реквеста или в списке конвейеров. Вы увидите схему этого конвейера с отображением выполненных, проваленных, активных и ожидающих сборок.
Шаблоны тикетов и мерж-реквестов.
Возможность стандартизировать тикеты и мерж-реквесты с помощью шаблонов уже была в GitLab Enterprise Edition. Начиная с GitLab 8.11 шаблонов может быть много — например, один для ошибок, а другой для предложений. А сама возможность есть во всех версиях: GitLab.com, GitLab CE/EE.
Цель этой фичи — улучшить внешний вид и полноту предложений, сообщений об ошибках и мерж-реквестов.
Слеш-команды
Теперь в GitLab есть слеш-команды ( /command ) — так же, как в IRC, HipChat, Mattermost или Slack. Они позволяют менять метки, назначать исполнителей, подписываться и отписываться от тикетов и делать многое другое — быстро и не отрывая рук от клавиатуры. Команды работают в описании тикета или мерж-реквеста, а также в комментариях.
Как ими пользоваться:
Можно использовать слеш-команды даже при создании нового тикета или реквеста:
Если последовательно указать несколько команд, то все они будут выполнены.
Несколько идей, как можно использовать слеш-команды:
Мы сами с нетерпением ждём ваших рассказов о том, какие ещё способы использования вы изобретёте.
Интеграция с Koding
Koding позволяет запускать среду разработки в облаке, использовать единые настройки этой среды для всей команды и даже использовать локальный редактор. Благодаря этому не нужно тратить время на установку и настройку стека для каждого нового компьютера и при любом изменении.
Начиная с версии 8.11 GitLab поддерживает интеграцию с Koding. Теперь одним нажатием кнопки можно выкачать проект целиком или отдельный мерж-реквест и открыть его в полноценной облачной IDE. (обратите внимание, что на GitLab.com интеграция с Koding пока не добавлена).
Включите поддержку Koding в Admin > Application settings
Настройте Koding для работы с вашим проектом:
И все! Теперь вы можете быстро выкачать любой мерж-реквест, ветку и коммит проекта в полноценную IDE.
Мы подготовили небольшое видео, показывающее процесс работы связки Koding + GitLab:
Для того, чтобы узнать больше о Koding в GitLab, обратитесь к нашей документации.
Конвейеры в мерж-реквестах
Теперь конвейеры отображаются в мерж-реквестах:
Нажмите на конвейер, чтобы увидеть его схему и билды, относящиеся к нему.
Отображение статуса развертывания для мерж-реквестов
Теперь вы можете указывать URL для своих сред развертывания (environments):
Благодаря этому GitLab показывает статус развертывания для мерж-реквестов в случаях, когда развертывание происходит автоматически при мерже:
После успешного мержа GitLab покажет вам ссылку на среду развертывания, что позволяет увидеть результат мерж-реквеста в один клик.
Веб-хуки для конвейеров (pipelines)
Для упрощения интеграции с конвейерами GitLab мы добавили веб-хуки для них. Они срабатывают при создании, запуске или завершении работы конвейера.
Для того, чтобы добавить веб-хук, выберите Webhooks в меню Settings вашего проекта.
Подсветка и скрытие кода
Теперь редактор GitLab поддерживает подсветку и позволяет скрывать блоки кода.
Ссылки на мерж-реквесты при пуше
Теперь при пуше на GitLab появляются ссылки на создание мерж-реквеста, а также на все мерж-реквесты, имеющие отношение к текущему.
Значок покрытия тестами (test coverage)
Появилась возможность создавать значки, показывающие покрытие тестами вашего проекта:
Временные ограничения на доступ к проекту
При выдаче доступа к проекту одиночному пользователю, либо группе, теперь можно установить определенную дату, после которой доступ к проекту будет для них закрыт.
Это упрощает работу с правами доступа для временных членов команды.
Перемещение проектов между шардами (только EE)
В GitLab 8.10 были добавлены множественные точки монтирования (mount points).
В GitLab 8.11 появилась возможность перемещать проекты между шардами (shards) при помощи команды rake. Эта функциональность не предполагается для частого использования, однако она может оказаться полезной в случаях, когда вы хотите протестировать новый шард или переместить часто используемый проект на хранилище с быстрым доступом.
Улучшения производительности
В данном релизе был введен ряд изменений направленных на повышение производительности — мерж-реквесты и их диффы стали еще быстрее! Ниже приведены графики, показывающие разницу в производительности после развертывания GitLab 8.11 RC2 на GitLab.com (падение в производительности попадает на развертывание).
Время загрузки диффов для мерж-реквестов:
Количество выполненных SQL-запросов при отображении диффов:
Время, потраченное на выполнение SQL-запросов при отображении диффов:
Также значительно повысилась производительность конвейеров:
Ниже приведен детальный список проведенных улучшений и соответствующих мерж-реквестов:
Улучшения
Новые фичи
Инструментирование
GitLab Mattermost 3.3
В Mattermost 3.3 добавлены локализации на китайский, корейский и голландский языки, бот на Go,
возможность помечать (flag) посты, упоминания вида @here и многое другое.
Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее.
Поддержка Redis Sentinel
В GitLab теперь еть экспериментальная поддержка Redis Sentinel.
Прочие изменения
Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в Changelog.
Upgrade-барометр
Обновление до GitLab 8.11 потребует даунтайма из-за миграций баз данных
Даунтайм для сайта GitLab.com (самый крупный из известных нам инстансов GitLab) составил 15-30 минут. В зависимости от количества данных на вашем инстансе ваш даунтайм может быть меньше.
Одна из миграций удаляет несколько столбцов в нескольких таблицах (и инстанс GitLab нужно свернуть, чтобы эти данные не пропали в процессе доступа к ним).
Две другие миграции создают новые таблицы и наполняют их информацией на основе уже существующих в системе данных: в этом случае даунтайм нужен, чтобы добавляемые данные не поменялись в процессе работы миграции (и оставались неизменными, пока развертывание 8.11 не завершено полностью).
Наконец, еще одна миграция добавляет два внешних ключа (foreign keys), и здесь даунтайм нужен для гарантии отсутствия одновременного доступа к изменяемым данным.
Устаревание (deprecation) Ruby 2.1
С этим релизом мы обновили Ruby до версии 2.3.
Для ручных установок мы настоятельно рекомендуем вам обновить Ruby до 2.3. Установки GitLab, сделанные через Omnibus, автоматически будут использовать Ruby 2.3.
Поддержка Ruby 2.1 и 2.2 будет полностью прекращена в GitLab версии 8.13.
Для тех, кто обновился раньше остальных
Форсированная двухфакторная аутентификация при использоваии GitLab API и Git поверх HTTP
Если у вас включена двухфакторная аутентификация и вы пытаетесь получить API-токен через метод /sessions или Resource Owner Password Credentials flow provided в OAuth2, то вы не сможете залогиниться. Для успешного логина в этих случаях вам нужно будет использовать Personal Access Token.
Реиндексирование Elasticsearch (только для EE)
Мы изменили структуру индексов Elasticsearch и теперь они используют взаимоотношения типа «родитель-ребенок». Это повышает производительность, но требует полной перестройки всех индексов Elasticsearch. После обновления до 8.11 вам надо будет вручную удалить старые индексы и построить новые.
Для удаления старых индексов сделайте вот такой запрос к Elasticsearch:
Для перестройки индексов выполните действия описанные в документации по интеграции с Elasticsearch
Внимание Описанное выше применимо только если вы обновляетесь с предыдущей версии (8.10). Если вы обновляетесь с более ранних версий, проверьте разделы «Upgrade-барометр» для всех промежуточных версий.
Если вы обновляетесь с версии GitLab, меньшей, чем 8.0 и при этом у вас включен CI, вам нужно сначала обновиться до 8.0.
По умолчанию в процессе обновления все пакеты Omnibus будут остановлены, потом будут прогнаны все их миграции, и только потом они будут запущены снова. Это поведение не зависит от «размера» обновления. Изменить это поведение можно, создав файл /etc/gitlab/skip-auto-migrations.
Установка
Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел: https://about.gitlab.com/installation/
Обновление
Enterprise Edition
GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE.
GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут.
Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.
Issue tracker что это
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 Таблицы подойдут.
Плюсы:
— Бесплатно.
— Полная свобода творчества.
Минусы:
— Нет возможности интеграция с различными программами.
— Нет возможности учитывать время.
________
У каждой баг-трекинговой системы есть свои преимущества и недостатки. Достаточно изучить одну любую систему, чтобы понять принцип работы остальных. Как только вы поймете принцип, то на освоение новой системы у вас будет уходить совсем немного времени.
