Home

Автор: Ольга Назина (Киселёва)

Хорошее название бага понятно любому:

• менеджеру, плохо знающему техническую часть проекта;

• джуниору, который только пришел в проект;

• разработчику (зачем мне это чинить?)

Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?

И в этой статье я хочу разобрать каждый из них подробнее.

Что?

Что именно не работает?

Не все картинки отображаются корректно

↓

Картинка с котиком на главной уехала за пределы экрана

Что значит «не все картинки»? На главной их может быть с десяток. Они все сейчас отображаются некорректно? Или половина? Или все, кроме одной? Самый разный приоритет будет у задач. И мне надо понимать, что именно сломалось — все сразу или одна конкретная картинка.

Что произошло?

Вопрос «Что» отвечает сразу за два вопроса — что сломалось и как именно (что произошло?)

Не все картинки отображаются корректно

↓

Картинка с котиком на главной уехала за пределы экрана

Что значит «не отображаются корректно»? Варианты снова самые разные. Картинки расплющило, они отображаются в плохом разрешении, их вообще нет, вместо них крестики. Так что именно происходит?

Если не разделять эти случаи, то потом будете искать именно «картинки не отображаются» и придется заходить внутрь каждой задачи с одним и тем же заголовком «отображаются некорректно».

Где?

Где именно проблема? В каком месте или компоненте продукта?

Не все картинки отображаются корректно

↓

Картинка с котиком на главной уехала за пределы экрана

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

Аналогично с картинками — ну уезжает картинка за пределы экрана где-то там, в старых отчетах, которые никто не использует давно, ну и что? Другое дело, если проблема на главной странице сайта.

Если проблема в каком-то конкретном компоненте, то есть два разных способа ее описания:

1. Сначала указать компонент, а потом описать проблему

2. Просто описать проблему, а компонент указать в отдельном поле

Мне больше импонирует второй вариант, сравните:

Подсказки. Предлагать вариант с исправленной опечаткой в ФИО

↓

Предлагать подсказки с исправленной опечаткой в ФИО

С одной стороны, первый вариант очень удобен. Потому что если я делаю поиск по «ФИО» в баг-трекере, то я сразу по первой части заголовка вижу, где проблема:

• Подсказки

• Обработка

• Загрузка

• Отчеты

•   ...

Но... Обычно в баг-трекере есть отдельное поле «Компонент», так зачем дублировать его в названии? Если нужен конкретный компонент, можно указать его в настройках поиска.

Когда мы читаем текст, взгляд «спотыкается» о знаки препинания. Поэтому чем меньше знаков препинания в тексте, тем проще прочитать заголовок. Во втором варианте тоже понятно, что речь о подсказках, но читается он проще.

Однако тут дело привычки. И, разумеется, все зависит от компании, в которой вы работаете. Если вы пришли в команду, а у них принято в начале писать доп. инфу:

• Компонент, где обнаружена проблема.

• Стенд, на котором ее нашли (DEV, TEST, YOUR_NAME…).

• Браузер.

•  ...

Не надо махать шашкой и кричать, что это неудобно. Делайте так, как удобно команде.

Если в команде еще нет устоявшихся правил, рекомендую попробовать название писать «кратко, но емко» и без лишних знаков препинания. А всю доп инфо располагать в соответствующих полях. 

А дальше уже посмотрите, насколько это вам удобно или нет. Может быть, выработаете свой стиль. Главное — чтобы заголовок был понятным и показывал команде всю нужную информацию!

Когда?

Когда проблема проявляется? Всегда или при конкретных условиях?

Отчет падает с ошибкой

↓

Отчет падает с ошибкой 500, если месячный баланс равен 0

Другой пример:

Не все картинки отображаются корректно

↓

Картинка с котиком на главной уехала за пределы экрана

Так как в исправленном варианте названия ничего не отвечает на вопрос «когда» — подразумевается, что она ВСЕГДА уезжает. А вот если мы локализовали, что проблема только при некоторых условиях:

• Браузер IE 7 и младше

• Ширина браузера менее 500 пикселей

•  ...

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

Если вы не указываете ответ на вопрос «Когда?» — это значит, что баг воспроизводится всегда. Или вы плохо его локализовали, что уже не очень здорово.

Итого

Хорошее название бага отвечает на 3 главные вопроса: 

1. Что? — Что сломалось и как именно (что произошло?)

2. Где? — Где именно проблема? В каком месте или компоненте продукта?

3. Когда? — Когда проблема проявляется? Всегда или при конкретных условиях?

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

А это круто, особенно при поиске задачи потом — ведь в списке поиска мы видим в первую очередь название, и хочется найти “ту самую задачу” без долгих прокликиваний “зашли внутрь, нет, не оно”.

Поэтому старайтесь писать кратко, но емко. И коллеги будут вам благодарны =)

Обсудить в форуме