Ekaterina Vikulova
Jun 13, 2018 · 4 min read

Каждый день мы фиксируем баги и рано или поздно это перерастает в привычку, которая отрабатывается в полуавтоматическом режиме. Внимательность снижается, глаз “замыливается”. Мы начинаем терять контекст и слишком сокращаем описание. Часто заведенный баг понятен только тому, кто его оформил, а не тому, кто должен его исправить.

1. То, что мы держим в голове сегодня, наверняка оттуда вылетит уже завтра.

2. Разработчику баги на исправление могут поступить через месяц после того, как он сделал задачу и подробности давно забыты. А тестировщику, которому выпадет проверить фикс, и вовсе задача никогда не попадалась на глаза.

3. Если мы знаем, что раздел «Бабушкины запасы» находится на 7 шаге в разделе «Сахар», то разработчик, получивший баг на исправление, такой информацией может не обладать и на поиски уйдёт драгоценное время.

Старайтесь абстрагироваться и почаще задавайтесь вопросом “можно ли по мною описанным шагам повторить проблему? Не упустил ли я какой-то шаг?”. Это не означает, что нужно описывать каждый клик, но важные детали должны быть учтены.

В описании должна быть указана вся необходимая информация, которой располагает тестировщик. Лучше сразу приложить больше данных, чем потом по запросу разработчика или коллеги-тестировщика лихорадочно вспоминать “а что там было?..” и воспроизводить.

Краткий, чёткий, рассказывает ровно о проблеме.

Пример хорошего заголовка: <tittle> is broken at Dashboard: wrong symbols

Пример плохого заголовка: <tittle> is broken on the Dashboard page, when users tried to refresh the page three times in a row at midnight while the moon is shining

Пример нормально заголовка: <tittle> is broken at Dashboard

Далее в теле репорта уже будет раскрыта интрига возникновения ошибки и описаны стабильные шаги воспроизведения. Не нужно дублировать их в заголовке.

Разумеется, на разных проектах в разных компаниях приняты свои стандарты оформления задач, но идея у всех одинаковая.

Безусловно, самая важная часть заведения баг-репорта. Основная структура:
1) необходимые условия (логин, пароль / версия браузера / номер сборки и пр.)
2) прямая ссылка, где ловится проблема;
3) шаги воспроизведения;
4) фактический результат;
5) как необходимо исправить или ожидаемый результат (если известно).

Рассмотрим их всех подробней:

1. Необходимые условия
Если баг воспроизводится в одном браузере — это нужно указать.

Если он находится в Личном кабинете, то необходимо указать с какими доступами туда можно попасть, например, user@user.com / 12345.

Если для воспроизведения необходимо использовать промо-код или что-то подобное — они должны быть упомянуты в задаче в явном виде, например, “Использована промо-кампания SOcheapPleAseBUYit1111!!!!”.

Если есть какие-то другие предварительные условия — не забудьте про них написать.

2. Прямая ссылка
Будь то банальная главная сайта или специфическая страница внутри Личного кабинета — указывать ссылку в обоих случаях. По указанной ссылке разработчику будет проще отловить проблему, а тестировщику впоследствии проверить её фикс.

3. Шаги воспроизведения
Должны быть четкие, однозначные. Для профилактики попробуйте следовать написанным шагам дословно и посмотрите куда это приведёт.

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

4. Фактический результат
Давайте немного поиграем в “Отгадайку”:

1) Пример первый:
1. Открыть главную страницу.
2. Попробовать что-нибудь найти.
3. Вообще ничего не работает.

2) Пример второй:
1.Открыть www.thebestsearchingwebsite.com.
2.Ввести текст «!»№%321123» в строку поиска.
3. Появляется ошибка на странице [текст ошибки].
С сервера приходит 409 [ответ сервера из Developer tools].
Кнопка становится disabled и теряет цвет [скриншот].
cURL для примера: [cURL].
Ответ сервера: [текст ответа из запроса].

Как думаете, по какому описанию проще установить причину проблемы и быстро исправить? И почему? Обоснуйте. :)

На что обратить внимание при локализации проблемы:
1) изучить что уходит в запросе на сервер;
2) посмотреть на ответ с сервера;
3) проверить консоль на errors и warnings;
4) обязательно зафиксировать скриншотом что видит клиент при возникновении ошибки;
5) проанализировать полученные результаты.

Developer tools браузера должны быть открыты постоянно. Это “лучший” друг в тестировании веба.

Приложите в баг-репорт всю информацию, которую удалось собрать (скриншот с проблемой, ответ сервера, текст ошибки, curl и т.д.). Возможно, вам эта информация покажется незначительной, но разработчику может чётко указать на проблемное место, а тестировщику даст явные подсказки для воспроизведения проблемы при проверке фикса.

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

К сожалению, нам не всегда известно как именно нужно исправить тот или иной дефект, поэтому пункт с “ожидаемым результатом” иногда можно упустить.

Однако, если есть четко поставленная задача и обнаружена однозначная проблема, противоречащая постановке — необходимо подробно описать что не так и на что нужно исправить.

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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade