«

»

Май 04

Мысли о баг-репортах. Часть I. «Title» он же «Заголовок»

Казалось бы, что может быть проще — составить описание обнаруженного дефекта. Ан нет, пожалуй, отчет об ошибке, один из самых простых и очевидных артефактов, которые воспроизводит тестировщик, и который содержит больше всего «багов» 🙂

«Ошибка в логировании»
«Опечатка в заголовке»
«Автомат уходит в бесконечную перезагрузку»
«Виснет приложение»
«Подумать позже»

Это реальные заголовки, с которыми я сталкивался.
Весело, особенно «Подумать позже» — ошибка была заведена тестировщиком на кусок требований, которые отложили от реализации. Этакая таска, ага. Только вот, практики использования багтрекера в роли таск-трекера на проекте не было. И каждый на проекте, натыкаясь на этот баг, считал своим долгом подумать… Я, например, думал несколько раз 😛

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

«Ха, программисты… прочитают описание и поймут что действительно ‘Ошибка в логировании'»?
Может быть. Раз прочитают. Два прочитают. Самые добродушные и спокойные — три раза прочитают такие заголовки. Не стоит испытывать терпение коллег.  Не стоит вызывать желание отпинаться от проблемы.

Представьте себе, что список  400-500 ошибок за фазу тестирования экспортится в электронную таблицу и предоставляется заказчику для ознакомления. Заказчик будет в восторге от заголовков вида: «Виснет приложение», даже если подобный дефект один?

«Эй, ну я каждый день завожу по 30 ошибок, а тут ещё и мучиться с заголовком?!»
Сколько из ваших 30 ошибок возвращается к вам с просьбой уточнить, или закрывается как ‘as design’, хотя, хоть убейте, в описании всё-же прозрачно и очевидно?

«Ну классно, а что ты предлагаешь?»
Ничего нового, сложного и не выполнимого.
Думать о том, кто будет исправлять ошибку, думать о том, кто будет читать ваши отчеты по заголовкам. Сотни ваших отчетов.

1. Twitter великолепная вещь. 140 символов. Не надо больше. Не нужны поэмы и драмы в названиях отчетов.
2. Великолепные три вопроса W, которые любят менеджеры, помогут и при написании заголовка отчета:

  • Who
  • What
  • When

Кто или Что работает неправильно.
Что именно делается не правильно.
Когда и\или при каких условиях эта ошибка возникает.

Пример:

Немного провокации
В зависимости от команды, заказчиков и приложения можно сделать название отчета немного более кричащим.

«Заголовок «Выигрвш ноликов» вместо заголовка «Выигрыш ноликов» после разгромной победы ноликов над крестиками»
Главное что-бы в команде и у заказчиков не возникло вопросов: «Что значит разгромная победа?». Пользоваться этим стоит очень и очень осторожно, что бы не переусердствовать, заголовки в лушчих традициях желтой прессы не украсят отчеты:

  • Спецсигнал никогда не откажется от Викиты Нихайкова.
  • Нижнежевовское водохранилище — портал в иные миры!
  • Велосипед из Германии утром похитил почтальона.

Часть II.1 здесь

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

8 комментариев

3 пинга

Перейти полю для комментария

  1. Natalya Rukol

    Спасибо за грамотную статью и за финальную фразу про велосипед — весело 🙂

    Баг-репорты стоит расценивать как продукт, который мы, тестировщики, производим. Точнее, как один из интерфейсов предоставления нашего сервиса — «информации о продукте».

    И у нашего сервиса есть пользователи:
    1) Разработчики, которым по заголовку должно быть понятно, хотя бы приблизительно, в каком модуле проблема
    2) Аналитики и РМ’ы, которым по заголовку надо понять, как это влияет на продукт, является ли этот дефект «шоустоппером», критичен ли он
    3) Другие тестировщики, которые поиском ищут дефекты, чтобы не плодить дубликаты

    Исходя из этого, можно сказать, что «правильный заголовок» удовлетворяет следующим требованиям:
    — определяет критичность дефекта (влияние на пользователя, те самые что и когда)
    — определяет расположение дефекта (когда)
    — предоставляет возможности поиска (коды ошибок, дословные фразы, ключевые слова и т.д.)

    Плохие примеры:
    * Ошибка #6578 (когда? на что это влияет?)
    * Ошибка при сохранении документа (какая? на что влияет?)

    Хороший пример:
    При сохранении любого документа появляется ошибка #6578, хотя документ успешно сохраняется

    В этом заголовке есть «что» (ошибка), «когда» (при сохранении любого документа), её номер (чтобы легко найти поиском) и влияние на пользователя («хотя документ успешно сохраняется» — без этой фразы не понятен impact).

    Всё ИМХО, конечно 🙂

    1. Сергей Атрощенков

      Наталья, спасибо за комментарий. Мысль про степень влияния интересная. Ещё ведь можно копнуть глубже и описать тип пользователей, на которых воздействует проблема. Сегодня вечером добавлю в статью мысли 🙂

    2. Сергей Атрощенков

      Да, я слегка погорячился, начал писать, понял что это планировал в описание дефекта внести, всё-таки 🙂

  2. Victor Doulepov

    Из рассказа создалось странное ощущение, что система учёта дефектов не настроена под процесс, и оттого нужно максимум информации запихивать именно в заголовок.
    Даже сценарий воспроизведения дефекта и ожидаемое правильное поведение.
    Дублирование?

    1. Сергей Атрощенков

      Система учета дефектов — может и настроена быть.

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

      Когда необходимую информацию можно получить из 100-140 символов, предоставлять ещё 200-300 символов, я не вижу необходимости.

  3. Алексей Фёдоров

    Почему Вы не указываете информации о типе дефекта (напр., Blue Screen of Death, диление на ноль, переполнение буффера) в заголовке?

  4. sypai

    «Не нужны поэму и драмма в названии отчетов.»

    насчет грамотности статьи я бы не спешил с выводами на месте комментаторов 😉

    Исправьте у вас три (или четыре в зависимости от того как вы хотели сказать) ошибки в одном предложении.

    нужнА (-Ы) ,поэмЫ (-А), драМа (-Ы), названиЯХ.

    удачи!

  5. Сергей Атрощенков

    Спасибо, поправил 🙂

  1. Контрольный список вопросов Феникс. | BarbaricQA.com

    […] это добавляем дополнительную информацию в наш отчет об ошибке (в этом поможет описание и определение проблемы) и… […]

  2. Итоговое руководство по составлению отчетов об ошибках. | BarbaricQA.com

    […] Мысли о баг-репортах. Часть I. «Title» он же «Загол… […]

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>