- Кратко
- Может ли заменить Jira (да)
- Жизненный цикл дефекта в Bugzilla
- Функциональность
- Практикум
- Agile-инструменты
Что такое Bugzilla
Бесплатный баг-трекер с открытыми исходниками, сайд-проект создателей браузера Firefox. «Багзилле» уже 25 лет, она 1998 года рождения — так долго могут жить только качественные ИТ-проекты (ну ок, просто очень надежные).
Нужно ли осваивать Bugzilla тестировщику-новичку? Скорее всего — да; если не прямо сейчас, точно понадобится позже; хотя бы потому, что другой популярный баг-трекер, Jira, уже не работает в России — и Bugzilla может заменить.
Несмотря на бедноватый интерфейс для 2023 года, и неидеальную функциональность, этот трекер как ни странно котируется у разработчиков элитного уровня — глядя на список проектов и ИТ-компаний на официальном сайте. Кроме типичных инди-проектов, в Bugzilla работают команды Linux Kernel, Eclipse, GCC, KDE, Wine.
Может ли Bugzilla заменить Jira
По первых, Jira платная, во вторых закрытый код; в третьих, и это главное, Jira официально ушла из России. Существующие подписки были блокированы (и продолжают блокироваться). Все же, официальную подписку приобрести сложно, но можно, окольными путями (особенно если иностранный партнер заинтересован в том чтобы российская команда продолжала работать в Jira); существуют сервисы, работающие за комиссию 25%. Кто-то продолжает работать в Jira, не видя альтернатив, тем более что продукт действительно качественный.
- Особенно для функционального тестирования
- И приоретизации задач
- Возможности планирования и мониторинга трудно сравнить с бесплатными аналогами
- И гибкость, в опытных руках, для любых задач и любых масштабов
Чем отличается Bugzilla от Jira
- Юридические/политические проблемы Jira, то есть лицензия и сложности с ее заказом/продолжением/оплатой. В Bugzilla этих проблем просто не существует.
- Архитектура. Jira построена на MySQL, Oracle, PostgeSQL, Perl. Bugzilla — J2EE, Tomcat, Lucene, MySQL, Oracle, PostgreSQL.
- Коммуникация с серверами в Bugzilla значительно меньше, чем в Jira. Bugzilla можно запускать много экземпляров на одном сервере, Bugzilla очень простая; Jira — сложная система, работающая совершенно иначе. Для Bugzilla-сервера в крупных проектах рекомендуется выделить как минимум 1 Гб оперативки и нужен хороший процессор. Что касается Jira, в комьюнити Atlassian рекомендуют хранить не более 200 000 багов в одном Jira-экземпляре.
- О приоритизации дефектов перетаскиванием мышкой в Bugzilla придется забыть (как и о множестве других удобных функций в интерфейсе).
- Дашборд с кастомными гаджетами. Саммари с прогрессом, репортами — этого нет в Bugzilla
- Трекинг релиза в реальном времени. Легкость отслеживания состояния релиза всеми участниками команды в любой момент — здесь Bugzilla тоже не блещет.
- Атачменты. В Bugzilla можно прикрепить только один файл за один раз.
- Размер атачмента только 1 Мб (в Jira — 10 Мб)
- Канбана нет в Bugzilla (то есть поддержки канбан-досок). Впрочем есть костыли, об этом — в конце.
- Интерфейс совершенно несравним с Jira. Комьюнити старается что-то улучшить в этом плане, надо отдать должное, но пока не очень получается. И видимо вряд ли получится в будущем.
- Кастомные поля в репортах в Bugzilla есть, несколько типов, но тоже несравнимо с их количеством в Jira (плюс еще плагины).
- Рабочие процессы (воркфлоу) — в Bugzilla администратор прописывает глобальный воркфлоу для всех продуктов, редактируя матрицу; в Jira пользователи могут задать много рабочих процессов, в зависимости от типа проекта, изменять их статусы/переходы и т.п.
- Поиск. В Bugzilla есть неплохие функции поиска, но Jira намного гибче и мощнее и в этом плане тоже.
Жизненный цикл бага в Bugzilla
Функциональность
- Подключается к другим инструментам багтрекинга и управления тестированием
- Настраиваемые функции поиска
- Настраиваемые уведомления об изменении статусов багов
- Ведение истории изменения статусов
- Можно регистрировать зависимости между багами, и графически их отображать
- Прикреплять к багам дополнительные файлы (только рисунки)
- Несмотря на бесплатность и открытость, обладает достаточной защищенностью, подтвержденную аудитами
- Есть веб-версия (чем мы далее и воспользуемся)
- Можно настраивать слежение за интересующими багами и проектами/компонентами
- Локализация, в том числе русская в десктопной версии
Блиц-практикум
Установка/Регистрация
Десктопная версия написана на древнем языке Perl и работает на MySQL; установка может быть сложна для QA-новичков. Нужно (было бы) поставить целый пакет из:
- Perl (Active Perl)
- БД MySQL/PostgreSQL/Oracle
- Веб-сервер (на котором запускать SGI-скрипты)
- Саму Bugzilla
- Perl-модули
- Мейл-агент
Но есть другой вариант для новичка в QA, гораздо проще и быстрее — веб-версия Bugzilla. Чтобы освоить основные операции в Bugzilla, ее будет достаточно. Заходим по ссылке, и видим следующее:
Создаем экаунт (нажимаем большую кнопку “New Account” справа) и видим:
Вводим свою почту, подтверждаем, что ознакомились с неким “Этикетом поведения в сообществе Bugzilla” и нажимаем «Создать экаунт» (Create Account).
После регистрации можно привязать к Bugzilla свой GitHub-экаунт (который желательно иметь уже давно), и в дальнейшем входить через Гитхаб, что удобнее.
Зарегистрировались, подтвердились, вошли в свой личный экаунт в Bugzilla:
Создание бага
Тестировщик ищет баги, и когда находит, вносит данные о них в баг-трекер. Чтобы создать новый баг, нажимаем крупную кнопку с плюсом — “New Bug” (Создать).
Появится страница выбора приложения, в котором мы (якобы) нашли баг:
Нажимаем, например, “Other Products” справа внизу, и далее видим:
Далее нажимаем, к примеру, приложение “Calendar”. Появится окно запроса/уточнения, в котором нужно указать суть проблемы/бага
В этом поле поиска (с подсказкой “Short summary of issue”) вводим, например, слово “fail”, как достаточно частое слово в описании любого бага, нажимаем «Искать похожие баги» («Find similar issues») и видим список багов, содержащих в описании это слово:
Нажимаем сверху кнопку “Своего бага я здесь не вижу” (My issue is not listed), раз его нет, значит сейчас будем создавать; после нажатия оказываемся на странице заполнения атрибутов нового бага в системе:
В правом нижнем углу переключаемся на стандартную форму заполнения (Switch to the standard bug entry form), и заполняем:
Поля, которые тестировщик должен заполнить, когда создает баг:
- Продукт (у нас уже выбран Календарь)
- Компонент (модуль, часть продукта по функциональности)
- Тип — дефект
- Версия
- Короткое описание (Summary)
- и другие поля, по желанию
После заполнения нажимаем “Отправить баг” (Submit bug). Теперь баг создан.
Поиск багов
Возвращаемся на главную страницу и жмем крупную кнопку “Advanced Search”. Появится окно поиска по всевозможным критериям:
Далее сверху переключаемся на вкладку “Simple Search”. Вводим в поиск наше волшебное слово “fail”, нажимаем “Search”, и видим список всех открытых багов (точнее не всех, а только 500):
Теперь переключаемся на вкладку «Advanced Search» в верхней панели сайта. Это вкладка по умолчанию, для поиска по точным критериям. В строке поиска вводим, опять же, слово “fail”, в пяти окнах ниже уточняем запрос, выбрав только Client Software->Calendar, и нажимаем кнопку “Search”. Видим список открытых багов в этом приложении:
Настройка Bugzilla
Настройки (крупная кнопка Preferences на главной странице) — там можно настроить:
- Вход на сайт (доступна двухфакторная аутентификация, для безопасности)
- Активные сессии в Bugzilla
- Уведомления на почту о всех событиях с багами
- Разрешения
- Слежение за нужными компонентами.
В Saved Searches хранятся поиски, включая поиски других пользователей, расшаренные для всех:
Можно настроить наблюдение за какими-то интересующими компонентами:
Панель управления Bugzilla (дашборд)
В «My Dashboard» в верхней панели инструментов — прикрепленные к конкретному тестировщику (то есть тебе) баги, а также запросы.
Если багов нет (не найдены, не созданы), Bugzilla сообщает: «Zarro Boogs found».
Если баг создан, проверен, но по каким-либо причинам у разработчиков нет возможности (или желания, или необходимости) его фиксить, в Bugzilla принято ставить пометку WONTFIX.
Репорты
Баг-репорты — формализованный метод анализировать баги, следить за их статусом, поддерживать коммуникацию с другими участниками команды. В Bugzilla три типа репортов:
- Графические
- Таблицы
- Дубликаты
Графические репорты
Генерируются в виде линейных графиков, столбиковых и круговых диаграмм. Такие «вижуалы» помогают представить текущую ситуацию с багами более наглядно.
Чтобы сгенерировать графический репорт, нажимаем кнопку “ »» ” в верхней панели, далее нажимаем “Репорты” (Reports):
Далее выбрать “Графические репорты” (Graphical reports):
Появится окно генерации репорта, в котором нужно выбрать параметры графика по горизонтали-вертикали:
Здесь нужно будет указать параметры оси X и Y, и формат графика. Например, формат укажем “Стоблцы”; по вертикали найдем и выберем в выпадающем списке Серьезность (Severity), а по горизонтали — найдем и укажем «Компонент» (Component), промотав этот список почти до конца. В строке поиска напишем, опять же, слово “fail”, и нажимаем кнопку “Генерировать репорт” (Generate report). Количество багов в Компонентах, отсортированное по Серьезности, графически выглядит примерно так:
Линейный график:
Круговая диаграмма:
Табличные репорты
Возвращаемся в Репорты и выбираем Табличные:
Выбираем в списках Серьезность и Ответственного за баг (Assignee), далее выбираем Client Software/Calendar, нажимаем «Генерировать», и сгенерируется вот такой табличный репорт:
Можно также настроить вывод в CSV-формат.
Баги-дубликаты в Bugzilla
Так называют баги, которые уже кто-то зарепортил, и возможно не один раз. Ведение учета дубликатов помогает снизить их количество: тестировщики переходят к новому багу, экономя время своей QA-команды и разработчиков.
- Полезно посмотреть частые баги
- Если тестировщик нашел баг, хочет его зарепортить, и находит такой баг в списке (а скорее всего он там будет), нужно кликнуть номер бага, чтобы далее подтвердить повторное его появление; и можно добавить свою дополнительную информацию в комментарий — об обстоятельствах появления бага
- А если бага нет в списке дубликатов, можно пробовать найти похожий баг, найти и затем добавить в комментарий дополнительные уточняющие данные
- Если похожего нет, то это новый баг, и он тогда регистрируется; заполняются все поля и т.п., как на первом этапе туториала — ‘Создание бага‘
Итак, заходим в главной панели: “>>” — “Репорты”, на открывшейся странице находим “Дубликаты” (Duplicates):
Выводится список:
Как видим, один и тот же баг может быть обнаружен 100 раз и более. Список можно сортировать по компонентам, типам, серьезности, и так далее. Если не находим нужное, nj чтобы уточнить поиск, проматываем вниз, к «Update Search», и там уточняем:
- Ограничить поиск следующими продуктами из списка правее
- Искать только в списке 20 самых частых багов или во всех
- Показывать только баги с Открытым статусом (здесь подробнее о статусах багов)
Например, посмотрим открытые баги в самой Bugzilla:
Agile-инструменты для Bugzilla
Открытая архитектура Bugzilla способствует экспериментам; уже много лет есть попытки, той или иной степени успешности, «приделать» к Bugzilla Agile-инструменты.
AgileTools Bugzilla Extension
Заявляется поддержка Scrum-процессов: планирование, мониторинг прогресса. Канбана нет.
BzKanban
Плагин для создания канбан-доски, должен работать с 5 версией Bugzilla.
KanbanBoard
Фронтенд-плагин для канбана
Kanbanzilla
Канбан-доска для Bugzilla
Scrumbugz
Аддон для управления спринтами
***
