CmsPlugin.ru
Обзоры популярных CMS и плагинов. Рекомендации по созданию и продвижению сайтов

Правила хорошего тона при работе с баг-трекингом

/ Автор: / Просмотров: 1638
Bugzilla
Путь к светлому будущему крупных IT-компании лежит через баг-трекинг. Баг-трекинг — «кровеносная система» большинства компаний, занимающихся разработкой ПО и не только.

В данной статье хочу поделиться своим опытом - общими правила, которые вывел при коллективной работе с баг-трекинговой системой. Работать довелось с Bugzilla, поэтому реальные примеры связаны с ней. Система древняя, но рабочая, к тому же лет 10 назад особых альтернатив из бесплатных не было.

Предварительная работа

Баг-трекинг - дискуссионная площадка по делу, поэтому обсуждения и согласования всех нюансов по задаче проводите до оформления требования.

По крупным задачам лучше переговорить лишний раз с продукт-менеджером (ПМ) и всеми заинтересованными лицами. Видеозвонки, GDocs, переписка в Slack и через почту - в помощь.

"Сырые" требования чреваты:

  • Спам в почте. По умолчанию в переписке может быть более 3 человек в копии.
  • Сложнее следить за ходом мысли в переписке по багу.
  • Возрастает напряженность у ПМ.
  • Лишняя нагрузка на исполнителя (assignee).

Если всё будет сделано по уму, то про вот такую "чехарду" можно забыть:

История бага

Избегайте дублей

Дубликат

Дабы не злить ПМ "дупами", обязательно ознакомьтесь с базой уже заведённых требований.

В Bugzilla беглый поиск проводится в разделе Search (вкладка Advanced Search).

Описание задачи

Правильная постановка задачи - 50% успешного решения и, как минимум, сохранение своей кармы.

  • Заголовок (summary) — краткая суть задачи [Что? Где?].
  • Описание (description) — все необходимые данные для исполнителя [Что? Где? Как?].

То, что кажется очевидным вам, не факт, что будет понятно исполнителю. Поэтому старайтесь в лаконичной форме описывать задачу с единственно возможной трактовкой.

Если есть возможность объединить несколько мелких требований по одной теме, лучше сделать это. Так общая картина будет лучше видна и исполнителю, и проверяющему (QA).

Форматирование текста (абзацы, нумерация пунктов и т.д.) упрощает восприятие описания, даёт возможность сослаться на один из пунктов требования.

Приведу пример:

Оформление требования

Связывайте требования

Это упрощает навигацию по тематическим багам и определяет четкий порядок их реализации.

  • зависящие друг от друга требования по приоритету их реализации - через Depends on и Blocks;
  • близкие по теме - через See also (доп. информация для исполнителя).

Зависимость требований

Новое требование или "Reopen"?

Если формально требование полностью выполнено, то переоткрыть баг допустимо, на мой взгляд, в следующих случаях:

  • допущены явные ошибки/опечатки со стороны автора требования;
  • после реализации вскрылись "косяки", которые напрямую касаются предмета обсуждения.

В общем, сводится всё к одному правилу - нецелесообразно заводить новое требование.

Баг-трекинг и Вики - сладкая парочка

Благодаря интеграции системы отслеживания ошибок и вики-движка (т.н. Wiki Projects) появляется возможность оформления больших по объёму требований.

В Bugzilla связь возможна с Twiki. Достаточно в спецификации вставить тег с номером требования:

%BGQ{bug_id="номер_требования" data="on"}%

Но спецификация в Projects сама по себе – не панацея. Максимум по объем можно впихнуть в одну такую спеку 3-4 "экрана". Длинные портянки текста воспринимаются исполнителями с трудом, и таких "крокодилов" обычно откладывают в "долгий ящик".

Агрегация спецификаций – отличный способ разделить большую задачу на ряд поменьше. Тем самым вы улучшите читабельность спецификаций и придадите относительную независимость задачам.

Кстати, хорошая скороговорка: специфировали, специфицировали, да не выспецифицировали smile

Итого

Постарался акцентировать внимание в статье на простых, но эффективных приёмах. Очевидные вещи про дополнительные поля намеренно опустил, т.к. они заполняются в зависимости от ситуации, движка и принятых правил в команде.

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

Оставьте комментарий!

grin LOL cheese smile wink smirk rolleyes confused surprised big surprise tongue laugh tongue rolleye tongue wink raspberry blank stare long face ohh grrr gulp oh oh downer red face sick shut eye hmmm mad angry zipper kiss shock cool smile cool smirk cool grin cool hmm cool mad cool cheese vampire snake excaim question

Ваш комментарий будет опубликован после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)