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

На Хабре достаточно много написано про хороший стиль программирования, 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. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать
Метки:
Поделиться публикацией
Похожие публикации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 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 — дождь уже кончился).

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