25 октября 2012 в 13:18

Как правильно составлять баг-репорты

Ответ на топик «Распространенные ошибки при составлении баг-репортов».

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

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

Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Если используются какие-то входные данные, удостоверьтесь, что и они не содержат лишнего (действительно ли весь этот здоровенный кусок текста роняет редактор, а не один символ из него?).
Когда вы поняли, какие именно данные и какие ваши действия приводят к проблеме, кратко сформулируйте ее суть — придумайте заголовок баг-репорта. Опишите проблему настолько подробно и конкретно, насколько позволяет заголовок, при этом не увлекаясь его длиной :)
Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»
Пример «более хорошего» заголовка: «Редактор зависает при вставке текста, содержащего символ N, из буфера обмена по Ctrl+V»
Allenary: Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.

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

Теперь откройте баг-трекер, начните заполнять форму баг-репорта.
Запишите заголовок.

В каких-то баг-трекерах поля «Подробное описание» и «Шаги для воспроизведения» различаются, в каких-то — нет.

Если поле «Подробное описание» есть, опишите в нем проблему более подробно — уточните те детали, которые пришлось опустить в заголовке. Если вы понимаете, в чем причина проблемы (используется устаревшая формула для расчетов, не учитывается какое-то значение и т.д.) — тоже пишите все здесь. Если не знаете — лучше не гадайте.
Если в форме записи об ошибке нет отдельного поля Affect version (версия продукта, в котором проявляется проблема), то укажите версию здесь.

«Шаги для воспроизведения» — основное поле для заполнения в баг-репорте.
Запишите шаги, которые вы определили. Как уже было сказано, шагов должно быть необходимо и достаточно для воспроизведения проблемы. Лишние не пишите. Необходимых тоже не пропускайте :)
После описания шагов обязательно напишите результат — что получилось.
Далее здесь же опишите ожидаемый результат, если это необходимо. Конечно, не стоит писать «Редактор не падает», но если, например, результаты расчетов не соответствуют ожидаемым, то это надо указывать.
Таким образом, описание шагов для воспроизведения должно выглядеть как-то так:
Шаги для воспроизведения:
1. Открыть…
2. Кликнуть…
3. Ввести в поле… значение N1
4. Ввести в поле… значение N2
4. Кликнуть кнопку Calculate

Результат:
В поле Result отображается V1.

Ожидаемый результат:
В поле Result отображается V2.


Если требуются исходные файлы, данные, дампы и пр. — сразу приаттачьте. Само собой, файлы должны содержать только информацию, необходимую для воспроизведения ошибки. Подчистите все лишнее.
Если проблема с визуальным отображением, то скриншот обязателен — можно будет понять ошибку и без воспроизведения шагов. Khizhnyak: На скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.

Но вставлять скриншоты в каждый баг-репорт совершенно не обязательно: пожалуйста, не плодите лишних сущностей. Если он ничем не поможет в воспроизведении проблемы — не тратьте время на его изготовление.

Кстати, про видео воспроизведения ошибки: оно может помочь разве что для подтверждения, что проблема действительно есть, просто воспроизвести ее сложно. Но часто ли вы делаете запись экрана заранее? :)

По остальным полям.
Severity, Priority.
Наличие этих полей и значения в этих полях отличаются от багтрекера к багтрекеру.
Severity — это критичность бага с точки зрения тестировщика: фича, опечатка в тексте, мелкая проблема, значительная проблема, падение продукта, блокирующая проблема и пр.
Priority — приоритет, с которым проблема должна быть исправлена.
Если есть оба поля, то тестировщик, как правило, выставляет только Severity, а Priority — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.

Environment — есть во всех баг-трекерах. Это программно-аппаратное окружение, в котором проявляется проблема.
Укажите версию операционной системы, наличие сервис-паков, разрядность.
Если ваш проект зависит от каких-то компонентов — их наличие и версии обязательно! .NET, JRE/JDK и прочие SDK.
Интерпретируемый язык? Версию интерпретатора — обязательно!
Для веб-проектов — браузер, установленные плагины, если это влияет на работу проекта. Если что-то не работает в одном браузере, то проверьте, работает ли в остальных.

В какой версии исправить, на кого назначить — зависит от политики внутри компании. Не знаете, что поставить? Спросите коллегу.

Статья дополнена правильными замечаниями из комментариев.
Андрей @freiman
карма
17,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (27)

  • +9
    Тестер помни: багрепорт «ничего не работает!» оскорбляет чувства программирующих.
    • 0
      Багрепорт «ничего не работает!» позорит «тестера» и профессию.
  • +3
    >>Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»

    — У нас в компании это пример самого распространенного заголовка.
    • 0
      у вас так часто всё виснет когда вставляешь из буфера обмена?))
      • –1
        С чего Вы взяли?
      • +1
        Кэп подсказывает, что смысл комментария в том, у нас часто пишут «плохие» заголовки, а не именно такие, как в примере, на то он и пример.
      • +1
        У нас, кстати, часто. Почему-то большинство программистов не любят ставить ограничение на количество символов в текстовом поле…
  • +2
    И еще хотелось бы дополнить, что на скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.
    • +1
      Да, хорошее замечание.
      Сам всегда выделяю красной рамкой место, на которое надо обратить внимание. А вот упомянуть об этом в посте забыл.
  • 0
    Вы серьёзно предлагаете перебирать посимвольно кусок текста тестировщику, если с этим куском падает приложение? Даже бинарным поиском тестировщик на это потратит в разы больше времени, чем программист с дебаггером, мне кажется.

    Да, я понимаю, что это просто пример, но нахожу его как минимум неоднозначным.
    • 0
      Бинарным поиском подобные задачи решаются довольно быстро.

      А пример, конечно, весьма условный, не из рабочей практики.
    • 0
      Ну это распространенное пожелание к тестировщикам. Во времена работы в Cybiko на одном из совещаний был высказан тезис, что хороший тестировщик, должен уметь находить ошибки кода, архитектуры и дизайна, качественно описывать их и предлагать работающее исправление. На что было предложено тогда уволить всех программистов и дизайнеров. Начальнику отдела — бросать тестировщикам ярлык для проверки, чтобы потом они исправлением ошибок доводили продукт до ума ;-)
      • 0
        Находить ошибки кода и архитектуры (ага, при тестировании методом черного ящика к тому же :) ) может тестировщик 90lvl, такой в лучшем случае один на всю компанию :)
  • +3
    Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
    Что: неправильный расчет данных
    Где: на странице NNN
    Когда: после ввода а поле Y отрицательного значения.
    • +1
      Да, хороший принцип.
  • 0
    не соглашусь про видео. бывают последовательности и результаты, которые намного проще показать на видео чем описывать или скриншотить
    • 0
      а проще ли их потом воспроизвести программисту? или вам самим для проверки исправления бага?
  • 0
    И не забывайте о конфигурации тестового стенда!
    Возможно в этом посте это подразумевалось под шагами, но обычно она указывается отдельно и может включать в себя( в зависммости от типа тестируемого ПО:
    1. Версия тестируемой программы.
    2. Версия окружения( система, браузер, специальные библиотеки).
    3. Версия железа на котором происходит ошибка( если РС, то процессор, память, видео. Для мобильных устройств — тип мобильного устройства).
    • 0
      Да, про это немного есть в посте.
      Я разделил пункт на «affect version» и «environment»
      affect version — версия тестируемой программы
      environment — версия окружения, железа.
      • 0
        Ага, теперь увидел. При первом прочтении как то проскользнуло.
        Еще хорошо бы написать что делать если ошибка не воспроизводится, или воспроизводится статистически( т.е. конкретного алгоритма как ее получить — нет, но в течении некоторого времени она проявляется). Конечно это индивидуально для каждой компании, но мы такого рода ошибки собирали, потом помогало понимать что может еще рухнуть.
  • 0
    Вы забыли о следующем моменте: как быть, когда существует несколько путей воспроизведения ошибки?
    • 0
      Достаточно указать один, самый короткий/простой для воспроизведения.
      Главное — воспроизвести ошибку, чтобы понять ее причину.

      А когда вы перепроверяете, то можете попробовать все пути воспроизведения.
      • 0
        Опять же зависит от платформы и политики компании. Иногда бывает полезно разнести разные пути воспроизведения в разные записи. Возможно они инициированы разными проблемами в коде и исправление одной на другие не повлияет — проверять придется все.
  • 0
    а в нашем баг трекере раздел Environment ограничивается именем ОС! Из-за этого приходится постоянно задавать одни и те же вопросы :(. Вообще, очень правильная статья
    • 0
      Попросите ответственного за BTS добавить еще поле — сейчас инструмент не решает всех возложенных на него задач.

      У нас Environment — это просто поле для свободного ввода, можно писать все, что нужно в рамках данной конкретной задачи.
  • +2
    Из воспоминаний профессиональной юности: Когда прислала подобное руководство девочке-тестеру, которая любит писать баг-репорты в стиле «Программа не работает», она перестала со мной общаться и перевелась в др. отдел. Добавила статью в избранное — теперь в случае возникновения подобной ситуации будут ненавидеть Вас :)
  • 0
    Систем, которые выполняют подобные функции и стоят копейки или даже бесплатно — кучи — JIRA, BaseCamp, HollyTask. Вот даже тут почитать: www.hollytask.com/ru_bugreport

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