«Что? Где? Когда?» в названии багов

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

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

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

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

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

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

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

Что?

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

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

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

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

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

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

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

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

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

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


Где?

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

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

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

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

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

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

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

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

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

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

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

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

  • Подсказки

  • Обработка

  • Загрузка

  • Отчеты

  •   ...

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

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

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

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

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

  • Браузер.

  •  ...

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

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

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


Когда?

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

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

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

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

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

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

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

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

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

  •  ...

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

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


Итого

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

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

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

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

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

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

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

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале  

Источник: https://habr.com/ru/articles/780676/


Интересные статьи

Интересные статьи

В январе 2022 мы подводили командные итоги 2021 и обнаружили, что у нас довольно много приемочных багов при тестировании новых фич. Мириться с этим было нельзя, и за дело принялся знающий человек — на...
После весны 2020 года слово “тестирование” приобрело некоторые неожиданные значения и неоднозначные коннотации — пожалуй, везде, кроме IT. В нашей сфере без него никуда — и так было всегда. Видов тес...
Как выйти на рынок с программным продуктом для платёжных операций, который удовлетворит потребности пользователей и гарантирует безопасность транзакций? Рассказываем в этой статье.
Наука не враг духовности, напротив: научное знание — глубочайший источник духовного. Когда мы осознаем свое место в бесконечности световых лет и сменяющих друг друга эпох, когда постига...
Большая часть продаж и поддержки все так же происходит по телефону, и во времена удаленки эта цифра только возрастает. Но как контролировать сотрудников колл-центра? Специально для этого ...