Пользователь
0,0
рейтинг
25 октября 2012 в 11:06

Разработка → Распространенные ошибки при составлении баг-репортов из песочницы

На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?

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

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


1. Очень общий заголовок баги


Пример такой баги: Не могу создать аккаунт.
Кажется, система полностью неработоспособна. Что может оказаться при более подробном изучении проблемы:

  • Такой аккаунт уже существует (или в имени аккаунта введены недопустимые символы), а проблема в том, что сообщение об ошибке не отобразилось (возможно, что только на определенной версии браузера);
  • Аккаунт создался, но не пришло подтверждение по почте;
  • Другие варианты.

Кстати, все эти подробности (версия браузера, локализация) в шагах воспроизведения могут быть не указаны.

2. Очень подробные pre-steps, очень краткое описание.

Пример: Я забил гвоздь в стену. Потом работал с болтами, гайками и листовым железом. Проблема: космолет не летает.

Дефект начинают описывать как былину: Все действия, сделанные с самого утра, и с максимальной подробностью. Через пару абзацев это надоедает, и дописывают весьма кратко. Да, описание проблемы есть, оно достаточно большое, но совершенно бесполезное как программисту, который будет фиксить, так и тестировщику, которому попадет на проверку.

3. На каждое проявление ошибки создать отдельный баг-репорт


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

4. Большое количество аттачей и ссылок


У такой баги обычно есть только заголовок. Шаги воспроизведения представляют собой ссылку на test-case (кстати, возможно у программиста нет прав доступа на такой ресурс), ожидаемый результат — ссылка (или аттач) 50-страничной документации. В комментарии может быть приписка что шаги воспроизведения подробно расписаны в дефекте № NNN. В качестве дополнения — лог. Весь. За все 2 недели тестирования. Все 50 мегабайт. Ну и скриншоты каждого шага бонусом.

5. Не указано, в чем именно ошибка.


Да, бывает и такое. Редко (по-этому и не первое в списке), но бывает

Пример:
Заголовок: Javascript ошибка на странице. Далее идут шаги, как добраться до этой самой страницы, но нигде не указано само сообщение об ошибке и даже нет скриншотов.

6. Использование специфических сокращений и аббревиатур


Сокращенные названия сущностей, специфических для определенной части системы могут быть не понятны даже для людей, достаточно давно работающих на проекте. Также большое количество аббревиатур в тексте делает его трудным для восприятия. Время, потраченное на разбор такого дефекта значительно превышает время, которое было сэкономлено на написании отчета об ошибке. Можно использовать общепринятые аббревиатуры и сокращения, но не стоит этим злоупотреблять.

7. Обо всем и ни о чем


Коментарий от 57DeD: Не вошёл в список наиболее распространённый (по крайней мере из тех, с которыми я работал) горе-багрепорт: «У вас программа медленно грузится, иконка не того цвета, при вводе текста ошибка случается, пункт меню — не скажу какой-именно — не работает. Да и погода к тому же плохая — дождь идёт». (видимо, от разработчкаи требуется написать Not Reproduced — дождь уже кончился)

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

1 Правильно настроить обязательные для заполнения поля в баг-трекинговой системе, запретить аттачить большие файлы (если это не видео воспроизведения ошибки)
2. По аналогии с code-review: Просите иногда коллег посмотреть на свежесозданный отчет об ошибке. Возможно, они подскажут, что стоит добавить и/или исключить из описания бага.
3. Проверяйте багобазу перед созданием нового отчета — возможно, такой «зверь» уже записан.
4. Золотая середина нужна везде. Пытайтесь писать не пропуская важных шагов, но и не разжевывая очевидные вещи
5. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать
@Allenary
карма
11,0
рейтинг 0,0

Похожие публикации

Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +5
    Так дайте же пример корректно составленого дефекта. Раз уж пошел разговор о правилах.
  • 0
    Мы у себя придерживаемся определенного шаблона, что, как минимум, упрощает восприятие багов. Вот пример шаблона.. Конечно, детальность описания варьируется в зависимости от тривиальности ошибки.
  • 0
    Пример такой баги: Не могу создать аккаунт.

    а как стоило бы написать заголовок, чтобы он не был общим?
    • 0
      Писать так как есть :)
      «Не могу создать аккаунт» — значит, что аккаунт создать невозможно. Вообще никак. Вообще лучше звучит «Невозможно создать аккаунт».
      Если существуют ошибки в процедуре создания аккаунта, например у автора

      Такой аккаунт уже существует (или в имени аккаунта введены недопустимые символы), а проблема в том, что сообщение об ошибке не отобразилось (возможно, что только на определенной версии браузера);

      то название ошибки «Создание аккаунта. Не отображается сообщение об ошибке при вводе ошибочных данных в поле „Логин“».

      А вообще у ошибок есть атрибуты:
      — идентификатор;
      — название;
      — суть ошибки;
      — условия воспроизведения;
      — критичность.
    • 0
      Замечательная картинка про баги :)
  • +9
    Если в трекере полно репортов с вышеуказанными признаками, то виной тому обычно три причины:
    — информационная (тестер сам не понял как он этого добился, соответственно не может дать подробного описания);
    — методологическая (тестер не был обучен работе с трекером);
    — орнитологическая (тестер дятел).
  • 0
    Основные косяки в описании дефектов обычно не от тестеров, а от самих программистов :)
    Обычно дело: короткое описание и кусок кода в подробностях.
    Ну и с пунктом 5 не совсем согласен. Понятие «приятности» очень субъективно же.
  • 0
    << Очень подробные pre-steps, очень краткое описание.
    Не согласен. Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.

    << На каждое проявление ошибки создать отдельный баг-репорт
    Если пользователь, нашедший ошибку, эту систему не писал — скорее всего, он не сможет УГАДАТЬ, связаны ли проблемы. Лучше будут два тикета, а разработчики разберутся (разберемся:) ).

    << Использование специфических сокращений и аббревиатур
    Об этом вообще в первый раз слышу. Есть такая проблема? Чтобы пользователь сокращения использовал?
    • 0
      В общем, я не согласен с советами в общем случае. Если человек — тестировщик, да, часть советов имеет смысл. Но если это обычный пользователь? Он заметил баг, решил прислать, а тут — 10-20 полей, обязательных для заполнения, а еще нужно пробежаться по всей базе (в поиске могут быть фильтры, но например, он может не знать, к какому модулю это относится. Этим грешат в phpstorm), а еще — максимально коротко, но достаточно длинно…

      Главное — скриншот, чтобы видеть проблему, максимально много информации (но не заставлять пользователя ее писать, иначе он вообще тикет не создаст), и описание проблемы «как ее видит пользователь».
    • 0
      > Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.
      А у нас вот кодеры ругаются, когда в описании видят простыню текста — они её читают по диагонали и делают основные выводы о баге из его заголовка. Всё же краткость — сестра таланта. Но только когда она рука об руку с ясностью изложения, конечно.

      > Чтобы пользователь сокращения использовал?
      Вы именно про пользователей продуктом или про пользователей баг-трекером (тестировщиков)? Я довольно часто в некоторых проектах использую. Стараюсь делать это только в тех случаях, когда сокращения очевидны. Например, при тестировании админского клиента для приложения могу использовать AC (Admin Client).
      • 0
        Я говорил про общий случай, когда трекером пользуется пользователь приложения/сервиса (да и тестировщик). В любом случае, не представляю, чтобы такие люди использовали сокращения. Вот кодеры — да, это беда.
        • 0
          Ну, я тестировщик.

          Есть у нас один проект, например. Грубо говоря, там есть три различных клиентских приложения — Admin Client, Cashier Client и User Client. При описании какой-нибудь хитрой длинной баги я вполне могу начать называть их AC, CC и UC соответственно. Вероятно, о подобных (но менее очевидных) случаях и идёт речь в статье.

          Всё же зависит от проекта в первую очередь, мне думается.
    • 0
      Об этом вообще в первый раз слышу. Есть такая проблема? Чтобы пользователь сокращения использовал?

      У нас, например, карточная игра. Точнее, карточные игры. И вот, игроки, случается, используют аббревиатуры. Например, ХС (читается ХаСэ) — это Хозяин Склепа, а вот ХоСу — Хозяин Судеб. Если сам не играешь, поди догадайся, что ХС это именно хозяин склепа, а не судеб :).
      • 0
        Дело в том, что в таком случае все, кто работают с системой эти аббревиатуры знают, так что, это не проблема.

        … что-то у меня с запятыми
  • +1
    Тестировщиков — новичков я обычно прошу прочитать старенькую статью Джоэла Спольски
    «Работа над ошибками малой кровью» (по-русски или по-английски).

    Там в общем-то довольно очевидные вещи написаны:

    "… Каждое хорошее описание ошибки должно содержать ровно три вещи:
    Какие шаги привели к ошибке.
    Что вы ожидали увидеть.
    Что вы в самом деле увидели..."

    Обычно после прочтения качество баг репортов заметно повышается.
  • 0
    На старой работе мы немного переработали нашу систему интеграционных тестов, и в конце-концов заставили каждого тестера в ней разобраться и изучить, как писать тесты.

    В итоге, в багах было просто краткое описание проблемы и название теста. Нам же оставалось только обновить тестовую ветвь и запустить у себя в IDE тест.

    Правда, специфика системы была такова, что все действия пользователя легко эмулировались.
  • +1
    Не вошёл в список наиболее распространённый (по крайней мере из тех, с которыми я работал) горе-багрепорт: «У вас программа медленно грузится, иконка не того цвета, при вводе текста ошибка случается, пункт меню — не скажу какой-именно — не работает. Да и погода к тому же плохая — дождь идёт». (видимо, от разработчкаи требуется написать Not Reproduced — дождь уже кончился).

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