Что такое bug tracking system
Выбираем подходящий баг-трекинг
Я общался с десятками 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 подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:
Итоги
Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:
А как в вашей компании устроен процесс работы с багами?
Обзор популярных систем bug-трэкинга
Содержание статьи
Рано или поздно в растущих компаниях бесплатная система управления проектами (читай: Redmine) перестает справляться с потоком приходящих задач, а ее минусы перевешивают все существующие плюсы. И именно тогда нужно сделать правильный выбор и заплатить за ту систему, которая будет соответствовать всем необходимым требованиям.
Что такое Agile и Scrum?
Agile-методы — это методы разработки программного обеспечения, ориентированные на разработку по итерациям (планирование обновлений и контроль их выполнения).
Как гласит Википедия, основных идей гибкой методологии разработки четыре:
Суть методологии заключается в том, что разработчики от итерации к итерации выполняют требования заказчика, постоянно улучшая свой продукт. Есть несколько популярных методов работы по Agile. Одним из них является Scrum.
Scrum — это методология управления проектами, позволяющая планировать изменения, которые будут выполнены, и контролировать их выполнение.
Для контроля выполнения задач в Scrum используется доска (рис. 2), по которой можно отслеживать процесс выполнения задач. Доска может иметь много состояний, у каждой команды они называются по-своему, но основные из них три:
Также на доске есть диаграмма, по которой можно отслеживать ход выполнения задач во время итерации и корректировать список задач.
Зачем что-то менять?
Конечно, когда количество задач в системе около двух тысяч и все пользователи привыкли к ней, никто не хочет ничего менять. Для того чтобы решиться на переход, нужно быть уверенным, что текущая система не справляется, и четко знать, что нужно найти.
Что не устраивало в Redmine?
Безусловно, Redmine заслуживает внимания и имеет большое количество плюсов, и при этом еще и бесплатный. Можно как душе угодно настраивать права, статусы, трекеры и любые другие поля, достаточно удобно делать выборки, создавать задачи по почте и так далее. Очень удобна сквозная нумерация задач, хотя тут есть и плюсы, и минусы. Но приспособить его к Scrum не представляется возможным (кроме плагинов, которые являются платными и тормозят систему): доски нет, отслеживать время крайне неудобно, чтобы расположить задачи в произвольном порядке, нужно вводить дополнительные поля и сортировать по ним, нет нормальной интеграции c Git и SVN и так далее.
Что хочется увидеть в новой системе?
Перед тем как изучать системы, нужно четко определить критерии, по которым системы будут оценены:
Кандидаты
После изучения рынка и чтения большого количества статей и отзывов было отобрано пять вариантов для сравнения: популярная и раскрученная JIRA Agile, Trello, Targetprocess, Assembla и YouTrack от питерской компании JetBrains. Соответствие всем критериям оценено по 10-балльной шкале.
Assembla
Соответствие критериям
Язык: теоретически русский
Интеграция с Git: Есть и не требует дополнительных программ
Доска: 7 (из 10), не очень понятная, на 2/3 на английском
Настраиваемые поля: 8 (из 10) есть
Фильтрация: 9 (из 10)
Создание задач по email: есть
Права доступа: теоретически нормально настраиваемые
Локальная установка: нет
Цена: 30 пользователей — 49 долларов в месяц, 50 пользователей — 99 долларов в месяц
Впечатления
Плюсов у системы достаточно много. У них очень хорошая служба поддержки: в 19:30 по Москве задал вопрос по возможностям программы и ответ получил в течение пяти минут. Очень качественная статистика: можно прослеживать любые действия разработчика и видеть, что и когда он делал. Все изменения статусов, открытие/закрытие задач и коммиты отображаются в статистике. Можно прямо в системе заполнять ежедневные отчеты для Stand Up. Хорошо реализован поиск.
Один из главных минусов программы — перевод. Он сделан некачественно, и переведено далеко не все. В программе нужно долго разбираться. Вряд ли получится понять что-то, зайдя в нее первый раз. Задачи нельзя переносить между проектами, установить баг-трекер на свой сервер нельзя, что неудобно для больших компаний.
Trello
Язык: только английский
Интеграция с Git: нет
Доска: 6 (из 10) хорошая, но не переведена
Настраиваемые поля: 6 (из 10) есть
Фильтрация: 5 (из 10)
Создание задач по email: есть
Права доступа: теоретически нормально настраиваемые
Локальная установка: нет
Цена: 5 долларов в месяц
Впечатления
Система удобна тем, что она вся построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Но это же и главный минус программы. Она слишком простая и не предназначена для больших команд. Задачи банально не имеют номера, не говоря уже о переводе или установке на свой сервер. Конечно, такой подход удобен для заказчиков, которые могут увидеть все задачи в одном месте, не делая сложных поисков и не разбираясь в системе, но, как только количество открытых задач приблизится к пятистам, это, даже для заказчиков, из плюса превратится в минус.
Баг-трекер недорогой и подойти может только небольшим командам, у которых мало задач. В таком случае система будет справляться со своими обязанностями и помогать разработчикам следить за выполнением задач.
YouTrack
Интеграция с Git: есть, с помощью TeamCity
Доска: 8 (из 10) хорошая
Настраиваемые поля: 8 (из 10)
Фильтрация: 9 (из 10)
Создание задач по email: есть
Права доступа: хорошо настраиваемые
Локальная установка: да
Цена: 25 пользователей — 500 долларов в год, 50 пользователей — 750 долларов в год
Впечатления
Плюсов у YouTrack значительно больше, чем минусов. Не очень удобной кажется нумерация, так как номер задачи меняется при переносе ее в другой проект, поиск и подписка на обновления вообще требуют отдельной статьи — описать их в несколько строчек невозможно. Но с этими проблемами разобраться несложно, и сделать это должен только администратор баг-трекера, у пользователей этих проблем при правильной настройке не возникнет. Доска, как и диаграмма, очень удобные, статусы и приоритеты можно выделять так, чтобы сразу было видно то, что нужно ярко выделить, все удобно настраивается. Что также очень полезно — есть скрипт для импорта задач из большинства баг-трекеров, что сильно облегчает работу менеджера при переходе (хоть импорт и имеет свои минусы). Также минусом является отсутствие техподдержки. Если программа стоит 750 долларов, то можно как-то выделить человека, который будет отвечать на вопросы, а из помощи существует только англоязычный форум и собственно YouTrack, в котором можно создавать задачи по системе и писать о багах.
JIRA Agile
Интеграция с Git: есть
Доска: 7 (из 10) хорошая
Настраиваемые поля: 8 (из 10)
Фильтрация: 8 (из 10)
Создание задач по email: есть
Права доступа: хорошо настраиваемые
Локальная установка: да
Цена: 25 пользователей — 600 долларов в год, 50 пользователей — 1100 долларов
Впечатления
Для тестирования была выбрана не обычная версия JIRA, а JIRA Agile, имеющая доску и диаграмму для Scrum. Эта версия программы стоит дороже обычной. Баг-трекер не переведен на русский язык.
В системе очень много возможностей для настройки. Может быть, даже слишком много. По каждому проекту можно посмотреть подробную статистику, доска хорошая, но кажется менее удобной, чем в YouTrack. Что действительно удобно — сами задачи и список задач находятся в одном окне, то есть для переключения между задачами достаточно одного клика. В Assembla и YouTrack это реализовано хуже.
Можно сделать вывод: система сделана программистами для программистов, что имеет свои плюсы и минусы. К примеру, заказчик будет разбираться с системой долго, и вопросов возникнет очень много.
Targetprocess
Интеграция с Git: нет
Доска: 8 (из 10) хорошая
Настраиваемые поля: 6 (из 10)
Фильтрация: 4 (из 10)
Создание задач по email: есть
Права доступа: настраиваемые, но плохо
Локальная установка: да
Цена: 25 долларов в месяц за каждого пользователя, при локальной установке 249 долларов за каждого пользователя
Впечатления
Система очень дорогая, и тяжело понять, почему она так дорого стоит. Доска удобная, а размещение задач сделано по такому же типу, как в Trello, только более приспособлено к большим командам и большому количеству задач. Диаграмма тоже хорошая, ничего лишнего, и все понятно. Возможности по настройке полей хуже, чем у других систем. Видно, что баг-трекер хотели сделать как можно более простым и удобным, но вместо того, чтобы сделать всю функциональность как можно более простой, похоже, решили просто ее обрезать. Конечно, удобно заходить и видеть все задачи, легко переключаться между досками проектов и менять статусы, но, как только требуется сделать какие-то более сложные действия, возникают проблемы. На русский язык Targetprocess также не переведен.
Итоги
В ходе выбора нового баг-трекера было изучено пять программ. Система Trello оказалась непригодной для больших компаний и большого количества задач, система красиво выглядит и может подойти небольшим командам, но не более того. Четвертое место занял Targetprocess: система похожа на Trello, но более приспособлена для работы с большими объемами задач. Доска сделана качественно и просто, но, когда дело доходит до более тонкой настройки, появляется много сложностей и деталей, с которыми Targetprocess не справляется. Широких возможностей по настройке система не дает, а стоимость больше, чем остальных систем, что кажется необоснованным.
Популярная система JIRA с плагином Agile заняла третье место. В ней очень много возможностей для настройки, хорошая статистика по проектам, удобно смотреть задачи и неплохо реализована доска. Но разобраться в системе достаточно сложно, заказчикам изучение этого баг-трекера будет стоить немало труда, и администратору придется постоянно отвечать на возникающие вопросы. Если баг-трекером будут пользоваться только программисты, ее можно рассматривать как реальный вариант, но в компании, где половину пользователей составят заказчики, система должна быть такой, чтобы при первом входе было хотя бы приблизительно понятно, что нажимать, чтобы найти нужные задачи или создать новую.
Из всех вариантов больше всего понравились две системы: Assembla и YouTrack. Они очень отличаются друг от друга, что сильно усложнило выбор. Assembla ведет прекрасную статистику каждого пользователя, по ней можно изучать работу программистов и оценивать ее, видно все коммиты и к каким задачам они относятся. В YouTrack такого нет. Время, потраченное разработчиками на задачи, отслеживать можно, но для этого нужно заставить их писать это время в каждой задаче. Также Assembla не требует сторонних программ для интеграции с Git. YouTrack здесь отстает несильно, для него есть бесплатное приложение TeamCity, которое предоставляют разработчики, но с ним нужно будет дополнительно разбираться. Также в Assembla очень удобно следить за Stand Up отчетами разработчиков, чего вообще нет в YouTrack.
Если сравнивать качество перевода, то здесь, без сомнения, с большим отрывом выигрывает YouTrack. Баг-трекер переведен полностью и качественно (хоть перевод появился и достаточно недавно). Assembla переведена далеко не полностью, а там, где переведена, некоторые названия вызывают улыбку. Скорее всего, это временное явление и, если бы система выбиралась через полгода, возможно, этой проблемы уже бы не было. Что точно останется в ближайшем будущем, так это сложность самой системы для понимания и изучения. Если о YouTrack можно хоть что-то рассказать в нескольких словах и пользователь приблизительно поймет, как работать с системой, то с Assembla дела обстоят сложнее. Первые полчаса совершенно непонятно, что делать и что вообще происходит. Конечно, YouTrack тоже не сразу понятен, и для новых пользователей придется писать инструкцию, но он более нагляден и прост в использовании, хоть и дает меньше возможностей по администрированию. Выбирая между этими двумя системами, нужно решить, что важнее — возможность контролировать разработчиков и вести статистику их работы или, настроив систему самостоятельно и потратив на нее немало времени, получить простой в использовании и наглядный баг-трекер (где некоторые действия придется делать самостоятельно и не будет некоторых возможностей, но от постоянных вопросов по работе системы ты будешь избавлен).
После раздумий был выбран второй вариант, и первое место в обзоре систем управления проектами занял YouTrack.
Национальная библиотека им. Н. Э. Баумана
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.