Баг трекинговыми системами что это
4 лучших багтрекера или как QA эффективно отслеживает ошибки
Чем больше задач, проектов, клиентов, тем серьезнее встает этот вопрос: как систематизировать информацию о всех тасках и обнаруженных багах для учета рабочего времени, так называемых человеко-часов и возможности видеть картину в целом для расставления приоритетов.
В настоящее время без багтрекера невозможно представить работу как начинающего, так и опытного QA инженера. Для построения правильного процесса тестирования багтрекер просто необходим. Но как выбрать именно тот, единственный и неповторимый, который будет с тобой каждый день и с которым можно строить планы на будущее? Мы все еще о багтрекере. Так вот, чтобы помочь себе и сократить ваше время на поиски идеального багтрекера в столь изобилующем багтрекерами современном мире, мы подготовили небольшой обзор, основанный на нашем опыте и популярности систем. Мы выделим их ключевые особенности, а также в конце поделимся таблицей сравнения, которая помогла нам систематизировать багтрекеры и выбрать лучший для наших потребностей.
Redmine
Не можем умолчать тот факт, что мы сами пользуемся Redmine. Мало того что он бесплатный, но и нареканий не вызывал, и недостатков особых за 3 года использования нами обнаружено еще не было.
Bontq
YouTrack
Желаем вам выбрать вашего лучшего друга-багтрекера.
Анастасия Филатова, QA Engineer ROI4CIO
Выбираем подходящий баг-трекинг
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
С чего мы начинали, или Jira
Два года назад у нас была выделенная команда тестировщиков, которые вручную тестировали продукт после интеграции кода всех команд. До этого момента код проверялся разработчиками на девелоперских стендах. Ошибки которые находили тестировщики заносились в бэклог в Jira. Баги хранились в общем бэклоге и переезжали из спринта в спринт с другими задачами. Каждый спринт два-три бага доставались и чинились, но большинство оставалось на дне бэклога:
У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.
При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:
Прощай Jira, да здравствует Kaiten
Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:
Время экспериментов, или нет
Мы решили поэкспериментировать с форматами и создали отдельную доску в Kaiten, на которой хранили баги и меняли статусы. Мы упростили заведение баг-репорта, чтобы тратить меньше времени. При добавлении карточки в Kaiten тестировщики помечали разработчиков. Об этом им на почту отправлялось уведомление. Мы вывели эту доску на монитор, который висел в проходе рядом с нашим рабочим местом, чтобы разработчики видели прогресс и процесс тестирования стал прозрачным. Эта практика тоже не прижилась, потому что основной канал общения – Slack. Наши разработчики не проверяют почту часто. Поэтому это решение быстро перестало работать и мы снова вернулись к Slack.
Верните муравьишек
После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.
Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.
Наш идеальный способ по работе с багами сейчас
Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.
В-третьих, мы приняли «zero bug policy». В статье «#zerobugpolicy или как мы баги чиним» bevzuk подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:
Итоги
Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:
А как в вашей компании устроен процесс работы с багами?
Национальная библиотека им. Н. Э. Баумана
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.
Баг трекинговыми системами что это
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 Таблицы подойдут.
Плюсы:
— Бесплатно.
— Полная свобода творчества.
Минусы:
— Нет возможности интеграция с различными программами.
— Нет возможности учитывать время.
________
У каждой баг-трекинговой системы есть свои преимущества и недостатки. Достаточно изучить одну любую систему, чтобы понять принцип работы остальных. Как только вы поймете принцип, то на освоение новой системы у вас будет уходить совсем немного времени.