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

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

Давайте рассмотрим, какие основные ошибки могут появляться при составлении баг-репортов и как их избегать?

1. Неконкретизированный заголовок бага

Пример заголовка: «Не получается создать аккаунт».

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

Например:

  • Аккаунт с таким логином уже существует;
  • При регистрации были введены недопустимые символы;
  • На почту не пришла ссылка для подтверждения аккаунта.

2. Очень подробное описание preconditions, но мало описания самой проблемы

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

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

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

4. Много ссылок и аттачей

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

5. Неконкретизировано, в чем заключается баг

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

6. Сокращения и аббревиатуры

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

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

Вот, например, как разработчику реагировать на такое описание дефекта: «Программа медленно грузится, иконка не того цвета, названия пункта меню не совпадают с информацией в нем и вообще много недочетов»? Так вот в том то и дело, девелопер хочет знать конкретно, где и в чем эти недочеты проявляются!

Теперь давайте определимся, какие рекомендации помогут вам избегать ошибок при составлении баг-репортов:

  1. Баг-репорт – это не сочинение. Поэтому пишите кратко, но по существу. И максимально уделяйте внимание важным деталям.
  2. Иногда можно попросить коллегу тестировщика просмотреть ваш отчет свежим взглядом. Возможно, он подскажет, что стоит добавить, а что, наоборот, исключить.
  3. Перед созданием нового баг-репорта, проверяйте уже существующие баги. Убедитесь, что таковых еще нет в уже описанных ранее.
  4. Настройте все необходимые поля для заполнения в баг-трекинговой системе. Запретите аттачить большие файлы и использовать нестандартизированные сокращения.
  5. Составляйте баг-репорт так, чтобы, в первую очередь, вам было приятно его читать.

Понравилось? Расскажите друзьям:

ОСТАЛИСЬ ВОПРОСЫ?

?

НАШ МЕНЕДЖЕР СВЯЖЕТСЯ

С ВАМИ В БЛИЖАЙШЕЕ ВРЕМЯ

и ответит на все Ваши вопросы

Отправка формы… На сервере произошла ошибка. Форма получена.

Наши Адреса:

ПРАВЫЙ БЕРЕГ:

м Шулявка, ул. Довженко, 3, Киев, Украина

ЛЕВЫЙ БЕРЕГ:

м Левобережная, ул. Раисы Окипной, 2, Киев, Украина

Телефон: +38 (068) 597-15-77

E-mail: info@QaLabs.com.ua

QaLabs

Все права защищены © 2016-2017 Курсы тестировщиков Киев - QaLabs.com.ua