Хорошее название бага понятно любому:
менеджеру, плохо знающему техническую часть проекта;
джуниору, который только пришел в проект;
разработчику (зачем мне это чинить?)
Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?
И в этой статье я хочу разобрать каждый из них подробнее.
Что?
Что именно не работает?
Не все картинки отображаются корректно
↓
Картинка с котиком на главной уехала за пределы экрана
Что значит «не все картинки»? На главной их может быть с десяток. Они все сейчас отображаются некорректно? Или половина? Или все, кроме одной? Самый разный приоритет будет у задач. И мне надо понимать, что именно сломалось — все сразу или одна конкретная картинка.
Что произошло?
Вопрос «Что» отвечает сразу за два вопроса — что сломалось и как именно (что произошло?)
Не все картинки отображаются корректно
↓
Картинка с котиком на главной уехала за пределы экрана
Что значит «не отображаются корректно»? Варианты снова самые разные. Картинки расплющило, они отображаются в плохом разрешении, их вообще нет, вместо них крестики. Так что именно происходит?
Если не разделять эти случаи, то потом будете искать именно «картинки не отображаются» и придется заходить внутрь каждой задачи с одним и тем же заголовком «отображаются некорректно».
Где?
Где именно проблема? В каком месте или компоненте продукта?
Не все картинки отображаются корректно
↓
Картинка с котиком на главной уехала за пределы экрана
Совершенно разные баги получаются. Например, если у нас опечатка на главной странице сайта — это надо срочно исправить. А если где-то на 30 странице пользовательского соглашения, которое никто никогда не открывал, то пусть еще поживет, некритично.
Аналогично с картинками — ну уезжает картинка за пределы экрана где-то там, в старых отчетах, которые никто не использует давно, ну и что? Другое дело, если проблема на главной странице сайта.
Если проблема в каком-то конкретном компоненте, то есть два разных способа ее описания:
Сначала указать компонент, а потом описать проблему
Просто описать проблему, а компонент указать в отдельном поле
Мне больше импонирует второй вариант, сравните:
Подсказки. Предлагать вариант с исправленной опечаткой в ФИО
↓
Предлагать подсказки с исправленной опечаткой в ФИО
С одной стороны, первый вариант очень удобен. Потому что если я делаю поиск по «ФИО» в баг-трекере, то я сразу по первой части заголовка вижу, где проблема:
Подсказки
Обработка
Загрузка
Отчеты
...
Но... Обычно в баг-трекере есть отдельное поле «Компонент», так зачем дублировать его в названии? Если нужен конкретный компонент, можно указать его в настройках поиска.
Когда мы читаем текст, взгляд «спотыкается» о знаки препинания. Поэтому чем меньше знаков препинания в тексте, тем проще прочитать заголовок. Во втором варианте тоже понятно, что речь о подсказках, но читается он проще.
Однако тут дело привычки. И, разумеется, все зависит от компании, в которой вы работаете. Если вы пришли в команду, а у них принято в начале писать доп. инфу:
Компонент, где обнаружена проблема.
Стенд, на котором ее нашли (DEV, TEST, YOUR_NAME…).
Браузер.
...
Не надо махать шашкой и кричать, что это неудобно. Делайте так, как удобно команде.
Если в команде еще нет устоявшихся правил, рекомендую попробовать название писать «кратко, но емко» и без лишних знаков препинания. А всю доп инфо располагать в соответствующих полях.
А дальше уже посмотрите, насколько это вам удобно или нет. Может быть, выработаете свой стиль. Главное — чтобы заголовок был понятным и показывал команде всю нужную информацию!
Когда?
Когда проблема проявляется? Всегда или при конкретных условиях?
Отчет падает с ошибкой
↓
Отчет падает с ошибкой 500, если месячный баланс равен 0
Другой пример:
Не все картинки отображаются корректно
↓
Картинка с котиком на главной уехала за пределы экрана
Так как в исправленном варианте названия ничего не отвечает на вопрос «когда» — подразумевается, что она ВСЕГДА уезжает. А вот если мы локализовали, что проблема только при некоторых условиях:
Браузер IE 7 и младше
Ширина браузера менее 500 пикселей
...
То это должно отображаться в названии. Потому что если на главной странице куда-то уезжает картинка — это плохо. А если она уезжает в старом браузере, то и фиг бы с ней (если, конечно, у нас не энтерпрайз продукт, который мы разрабатывали четко под этот браузер).
Если вы не указываете ответ на вопрос «Когда?» — это значит, что баг воспроизводится всегда. Или вы плохо его локализовали, что уже не очень здорово.
Итого
Хорошее название бага отвечает на 3 главные вопроса:
Что? — Что сломалось и как именно (что произошло?)
Где? — Где именно проблема? В каком месте или компоненте продукта?
Когда? — Когда проблема проявляется? Всегда или при конкретных условиях?
По такому названию можно определить степень критичности проблемы, не заходя внутрь и не вчитываясь в детали воспроизведения.
А это круто, особенно при поиске задачи потом — ведь в списке поиска мы видим в первую очередь название, и хочется найти “ту самую задачу” без долгих прокликиваний “зашли внутрь, нет, не оно”.
Поэтому старайтесь писать кратко, но емко. И коллеги будут вам благодарны =)
PS — это выдержка из моей книги про баги.
Комментариев нет:
Отправить комментарий