Bugzilla что это за программа

Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

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

Преамбула

Скажу честно как все было… Надеюсь руководство меня не побьет и не уволит. Работать в компанию я пришел молодым и не опытным руководителем проектов. Быстро освоил весь производственный процесс и целиком в него влился. Стал руководить проектами: выявлять потребности заказчика, переводить все это на язык веба и формировать задания для разработчиков.

Bugzilla — Defect Tracking Tool | Introduction 01

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

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

Выбор системы багтрекинга

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

• Продукт — это проект
• Раздел — включает в себя проекты. Мы поделили проекты по логическим группам: в работе, завершенные, на поддержке, продвижение.
• Компонент — это этап: концепция, дизайн, верстка, программирование
• Ошибка — это задача или баг.

• В нее стали заносится не только ошибки по проектам, но и ставить задачи по работе: задачи по дизайну, верстке, наполнению и т.д. Т.е. все рабочие процессы фиксируются в BugZilla
• Система контроля отработанного времени для исполнителей. Время работы над задачей фиксируется в BugZilla. В конце каждого месяца делается срез отработанного времени и с учетом этого начисляется заработная плата (это ввели уже позже).
• Система отчетов для клиентов, работа над проектами которых идет по гибким методологиям. Они всегда могут войти в систему, посмотреть что делается. Поставить новую задачу или изменить приоритеты, а так же дать необходимые комментарии на возникшие вопросы по тем или иным задачам.

Разграничение прав доступа к проектам

1. Внедрение системы среди ограниченного числа сотрудников и отлаживание взаимодействия
2. Вовлечение всех сотрудников на всех этапах производственного процесса
3. Доступ к системе сторонних разработчиков и клиентов

А расскажу я об этапе 3 и о том как правильно настроить багзилу, чтобы в нее можно было пустить сторонних разработчиков, менеджеров и клиентов. Но при этом запретить сторонним разработчикам видеть уже поставленные ошибки по проекту и вообще не иметь доступ к проектам компании.

FAQ по баг-трекингу Bugzilla

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

Так как багзила в основном используется для поддержки Open Source проектов, то в ней по умолчанию действует принцип — что не запрещено в явном виде — то разрешено (т.е. так настроены настройки по умолчанию). Т.е. при создании новой задачи или проекта — он автоматически становится виден всем.

1. Разграничить доступ к проектам и задачам которые уже созданы.
2. При создании нового проекта автоматически запретить к нему доступ всем заведенным в системе пользователям. Позволить администраторам выбирать кому данный проект будет доступен.

1. Так как у нас проектная разработка, то под каждый новый проект заведен соответствующий продукт в багтрекере.
2. Каждому проекту мы создали группы, совпадающую с названием проекта. Делается это в разделе «Администирование» -> «Группы» — «Создать группу»
3. В свойствах каждого проекта производим настройку доступа («Администрирование» -> «Продукты» -> Выбираем продукт -> «Права доступа по группам»)
4. Выставляем доступ по группам для продукта. Для того чтобы ошибки данного проекта были доступны только членам созданной группы выставляем параметры как показано на рисунке: для «Группы»-> «Включено», «Остальные» -> «Запрещено». Для остальных групп везде ставим «Запрещено», «Запрещено».
5. Соответсвующим пользователям в разделе «Администрирование» -> «Пользователи» выбираем нужного пользователя и в столбце с группами под названием «Включен в группы» назначаем соответствующую группу (проект), все задачи по которому пользователь должен видеть.
6. Так же давайте запретим пользователям видеть все продукты в поиске, доступ к которым запрещен. Для этого убедимся что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «useentrygroupdefault» выбран как «Вкл.»
7. Теперь необходимо ранее заведенные ошибки, связанные с проектом, так же связаться с соответсвующей группой и таким образом закрыть их от постороннего взора:
   — Переходим к поиску
   — Выбираем продукт
   — Отбираем все ошибки по нему (новые, закрытые, выполненные и т.д.)
   — Выбираем групповое редактирование
   — Выделить все
   — В самом конце выбираем «Добавить ошибки в эту группу» — название нашей созданной группы под проект
   — Сохранить

Кстати, нет необходимости каждому программисту или дизайнеру присваивать каждый раз группу проекта, над которой он будет работать. Если в качестве исполнителя задача поставлена не него, то он будет видеть конкретную задачу по данному проекту.
Для этого надо убедиться, что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «strict_isolation» выбран как «Выкл.» Таким образом над одним проектом смогут работать различные исполнители и не видеть задач друг друга, в то время как менеджер будет видеть полную картину проекта.

1. Установим в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «makeproductgroups» выбран как «Вкл.»
2. Теперь при создании нового продукта к нему автоматически будет создаваться группа.
3. Вот и все. Теперь при создании ошибок к данному проекту они будут доступны только тем пользователям, которым назначена группа данного проекта.

Заключение

И вот по истечению 2,5 лет я могу сказать что решение в пользу BugZilla было принято верным. Сейчас без этой системы не могут обойтись ни менеджеры, ни сами разработчики, ни клиенты. Сейчас это один из основных инструментов при работе над проектами. В любой момент можно сделать срез по выбранному разработчику и посмотреть что у него стоит в работе. Тем самым планировать загрузку разработчиков и очередность решения задач.

Олег Демьянов
Руководитель отдела веб-разработки
компании «Твинс»

Источник: habr.com

Bugzilla

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

Особенности Bugzilla для пользователей:

• Расширенный поиск.
• Уведомления по электронной почте.
• Списки ошибок в различных форматах (Atom-календари, и т.д.).
• Регулярные отчёты по электронной почте.
• Отчёты и графики.
• Автообнаружение дубликатов багов.
• Изменение задач по электронной почте.
• Отслеживание времени.
• Вложения и комментарии.
• Перемещение между багами.
• Сохранение и «расшаривание» запросов.

• Безопасность.
• Расширенный механизм настраиваемых установок.
• Настраиваемые поля.
• Пользовательские рабочие процессы.
• Полная поддержка Unicode.
• Локализация.
• Поддержка mod_perl.
• Интерфейс веб-сервиса (XML-RPC).
• Управление видимостью бага / редактирование.
• Методы проверки подлинности.
• Поддержка нескольких СУБД.

Источник: startpack.ru

Home

Когда я пришел на свою первую работу, меня в первую очередь ознакомили с тем, без чего не может обойтись ни один человек на фирме. Ею оказалась моя первая в жизни «система управления ошибками» (СУО) — Bugzilla.

• Интерфейс Bugzilla
• Жизненный цикл бага (Bug lifecycle) в Bugzilla
• Поиск в Bugzilla
• Администрирование Bugzilla
• Безопасность в Bugzilla
• Заключение о Bugzilla

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

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

Выбор СУО достаточно ответственное дело, потому что, если вы уже выбрали СУО, а потом выяснилось, что вам не хватает некоторых опций, то вы будете вынуждены перенести базу багов на другую СУО, а это задача очень трудоёмкая, а иногда и невыполнимая. У меня была такая проблема, когда мне поручили найти замену Bugzilla (надо было найти СУО с поддержкой custom fields) и, когда мы перешли на новую систему мы еще долго вспоминали о старой и доброй Bugzilla. Некоторые удобные решения использованные в Bugzilla новая СУО не поддерживала, и нам пришлось с этим смирится. Итак, начнём.

Описание.

Название: Bugzilla
Версия: 2.16.6
Разработчик: The Mozilla Organization
Сайт: http://www.bugzilla.org
Распространение: freeware

Рис. 1. Создание нового бага в Bugzilla.

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

1. Интерфейс Bugzilla.

Интерфейс выглядит довольно серо, но поскольку графика отсутствует, страницы грузятся очень быстро. Все элементы на страницах удобно расположены, информация читается очень легко. На страницах минимум подсказок, они удобно спрятаны за ссылками названий полей (рис. 2).

Рис. 2. Ссылка на раздел в справке Bugzilla.

На каждой странице есть своего рода меню (рис. 3), в котором расположены ссылки на часто используемые действия (добавить баг, поиск, и т.д.) либо поиски (например, если вам постоянно надо просматривать список исправленных (fixed) багов по-вашему проекту, то вы задаете параметры поиска и сохраняете их в виде ссылки. Потом вам надо будет просто периодически кликать по нему и смотреть на результаты).

Рис. 3. Меню Bugzilla.

2. Жизненный цикл бага (Bug lifecycle) в Bugzilla.

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

Рис. 4. Редактирование свойств бага в Bugzilla.

Для каждого бага ведется история изменений (рис. 5), можно просмотреть зависимость (depend) бага (рис. 6) от остальных багов (в виде дерева) либо посмотреть, не заблокирован (block) ли данный баг другим багом. Причем, если вы указали, что баг #4 зависит от бага #5, то система автоматически проставит эту зависимость не только в баге #4, но и в баге #5.

Рис. 5. История изменения бага в Bugzilla.

Рис.6. Зависимость данного бага от остальных багов в Bugzilla.

Для каждого компонента можно назначить отвечающего как за разработку (Initial owner), так и за тестирование (Initial QA contact), это очень удобно, когда каждый тестер тестирует отдельный компонент. Еще есть одна маленькая приятность, когда вы хотите добавить комментарии к багу и вставить в него ссылку на другой баг, то вам достаточно просто написать bug #.

3. Поиск в Bugzilla.

Одна из самих сильных сторон Bugzilla. Стоит выделить возможность составления сложных запросов. Можно найти, что угодно, только надо знать, как правильно сформулировать запрос. Есть возможность одним кликом менять любые параметры сразу для нескольких багов (Change Several Bugs at Once). Мне этого очень не хватало, когда мы перешли с Bugzilla на Jira.

Все остальное, как и у других СУО.

Рис. 7. Поиск в Bugzilla.

4. Администрирование Bugzilla.

Пожалуй, самая запутанная и сложная часть. Не всегда понятно какая опция что и как делает. Но если один раз сесть и разобраться во всех настройках, то потом все кажется очень простым. Есть такая страница параметров (parameters), где собрано почти 70 настроек (рис. 8). Когда я впервые зашел на эту страницу, мне сразу захотелось оттуда уйти.

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

Рис. 8. Страница parameters в Bugzilla.

Опишу некоторые опции:

• Есть возможность подключить LDAP.
• Есть возможность модифицировать (конструировать) шаблон письма (notification), которое отправляется при редактировании бага.
• Есть возможность настроить значение поиска по умолчанию (когда вы делаете новый поиск).
• Есть возможность настроить значение полей нового бага (определённые поля уже будут иметь некоторые значения).
• Есть возможность включить/выключить показ некоторых полей (milestone, QA contact, votes, OS, и т.д.) при создании нового бага.
• Есть опции, которые заставляют комментировать (писать комментарии) при редактировании (смене статуса) бага.

Security в Bugzilla.

Довольно простой, настроить его можно только для отдельного пользователя. Все остальное, как и у других СУО.

Рис. 9. Права пользователя в Bugzilla.

Заключение о Bugzilla.

Bugzilla — это хорошо продуманная и оттестированная система (за 1 год я почти не нашел там багов), с одной стороны она довольно простая, с другой там есть все, что нужно для баг трекинга типичного проекта. Могу порекомендовать для тех, кому необходима простая и надёжная СУО. Сейчас Bugzilla используют 337 компаний и организаций по всему миру, среди них есть такие компании как: NASA, Id Software, IBM и софтверные проекты: Mozilla, Linux Kernel, Gnome, KDE, Apach Project, Open Office. Удачи вам в выборе системы.

Компания в которой работает автор

IntelliArts (www.intelliarts.com) is a custom software development and consulting company based in Lviv, Ukraine. Most of our software development activities are related with Java platform. We create various solutions from embedded systems (automotive, telematics, home gateways and so on) to enterprise level applications (document management, global electronic publishing etc).

Company mission is to meet requirements of our customers and provide high quality yet cost-effective custom software solutions and consulting services.

In order to achieve company mission we are consistent with next values:

• quality — we aim at providing the highest quality of service in the every phase of customer relationship from first contact to follow up support.
• customers — stand by our customer’s business goals, identify and understand their business needs and architect solutions, which efficiently addresses those needs.
• partnership — we focus not only on developing and maintaining the products and services we offer, but also on building long term relationships.
• know-how to develop software — we know how to use methodologies and technologies that fit the customers’ requirements and business needs.
• fast communication — we understand the importance of communication and client support, and maintain a 24-hour feedback policy. This ensures that any request or question received is answered within 24 hours.
• continious self-improvement — the IT industry is very dynamic, so we are we are very sensitive to the changes around us to leave at the leading edge in our industry.

These values permeate our thinking, our planning, our behavior and determine our «day-in day-out» decision making.

Having entrusted us with the development of the software be sure to gain the best combination of quality, reliability and rapidity. We are confident that working with us you will have the most positive impressions.

Источник: www.software-testing.ru