Информация о всех багах и дефектах программы содержится в баг-трекинговой системе, от которой и зависят требования к составлению баг-репортов. Конечно, в любой компании есть и свои внутрикорпоративные правила создания баг-репортов. Однако в силу некоторых технических и человеческих факторов в этих отчетах могут появляться описания багов, совершенно непонятных вашим коллегам.
Давайте рассмотрим, какие основные ошибки могут появляться при составлении баг-репортов и как их избегать?
Пример заголовка: «Не получается создать аккаунт».
Сразу можно предположить, что баг кроется в самой системе. Однако, если изучить проблему более детально, то причина может быть в другом.
Например:
К примеру, вы описываете все свои действия в четкой последовательности и с максимальной подробностью, но по сути это может быть абсолютно бесполезно. Описание большое, а вот выделить важные детали, на которые и будет обращать внимание программист при исправлении багов, у вас не получилось.
Некоторые баги могут быть одинаковыми, просто проявляются в разных местах и в разное время. В таком случае, их лучше группировать, чтобы не было неразберихи и сверять с базой уже имеющихся багов.
Описание бага с такой ошибкой выглядит таким образом: заголовок, ссылка на тест-кейс, чтобы показать шаги воспроизведения или пакет скриншотов, ссылка на ожидаемый результат (скриншот или многостраничный аттач-файл) и лог бонусом. И это все за несколько недель тестирования.
Такое редко, но тоже бывает. Пример: Заголовок бага - «Javascript ошибка на странице». Дальше расписаны шаги действий до этого сообщения, но нет указания, в чем именно ошибка, и нет скриншотов.
Большое количество сокращений и аббревиатур делают текст сложным для восприятия. Особенно, когда нужно понять, в чем суть проблемы. Если вы используете общеизвестные сокращения и аббревиатуры, старайтесь не перенасыщать ими текст. А от сокращений ради экономии времени и текста лучше отказаться. Иначе у разработчика уйдет больше времени на разбор этих сокращений, чем на исправление бага.
Вот, например, как разработчику реагировать на такое описание дефекта: «Программа медленно грузится, иконка не того цвета, названия пункта меню не совпадают с информацией в нем и вообще много недочетов»? Так вот в том то и дело, девелопер хочет знать конкретно, где и в чем эти недочеты проявляются!
Теперь давайте определимся, какие рекомендации помогут вам избегать ошибок при составлении баг-репортов:
Понравилось? Расскажите друзьям:
Наши Адреса:
ПРАВЫЙ БЕРЕГ:
м Шулявка, ул. Довженко, 3, Киев, Украина
ЛЕВЫЙ БЕРЕГ:
м Левобережная, ул. Раисы Окипной, 2, Киев, Украина
Телефон: +38 (068) 597-15-77
E-mail: info@QaLabs.com.ua
Все права защищены © 2016-2017 Курсы тестировщиков Киев - QaLabs.com.ua