Home

Оригинальная публикация: http://bytextest.ru/2017/02/15/bug-report-kak-pisat/#more-4457

Вы когда-нибудь видели под вашим багом комментарий “it is not reproducible”? Чувствовали, как екает сердце от статуса “waive requested”? Иногда команда разработчиков «разворачивает» баг, который вы так трепетно лелеяли и выхаживали. Ну, может не так уж и трепетно, раз его все таки не смогли воспроизвести.

Нажмите на картинку, чтобы увеличить изображение

Представьте ситуацию, когда, например, баг был заведен в Mozilla Firefox. Допустим, на сайте не работает кнопка «login». Так и запишем, попутно забыв указать в STR (шагах воспроизведения) — какой именно браузер и какую его версию мы использовали. А вот разработчик использует, допустим, Edge. И в их среде кнопка работает нормально. Соответственно, баг отклоняют за невозможностью воспроизведения и комментарием: «Может быть, проблема в вас?» Вы, как порядочный тестировщик, перепроверяете ошибку, находите ее и переоткрываете баг. Чем все закончится — непонятно.

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

Такое поведение плохо влияет, в первую очередь, на вас, как на специалиста. Фактически, вы впустую потратили оплачиваемое время — как свое, так и специалистов команды разработчиков. Помните об этом, начиная работать, ведь, как говорится, «встречают по одежке».

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

Нажмите на картинку, чтобы увеличить изображение

В первую очередь, давайте обозначим какие поля должен содержать этот самый «хороший баг-репорт».
Их количество может варьироваться, но на всякий случай, будьте готовы перечислить любой из следующих: Defect ID (присваиваемый багу номер), Reporter Name (кто завел баг), Defect Reported Date (дата заведения бага), Who Detected (кто нашел баг), Project Name (название проекта), Release/Build Version (версия билда, в котором найден баг), Defect/Enhancement (сам баг), Environment (среда), Priority (приоритет), Severity (критичность), Status (статус), Description (описание), Steps To Reproduce (шаги воспроизведения), URL (ссылка), Expected Result (ожидаемый результат), Actual Result (действительный результат). Сразу готовьтесь к большому количеству странных слов на английском. А лучше подучите язык так, чтобы они стали понятны, потому что даже отечественные разработчики пользуются западной терминологией, коверкая слова и смешивая языки, что можно было понять еще из названия статьи.

Итак, первое, что необходимо сделать ДО заведения бага — воспроизвести его два-три раза, воспроизвести на различных конфигурациях и выявить наиболее актуальный STR. Тестировщику не менее, чем разработчику важно понимать суть проблемы и ее приоритет.

Когда убедились, что баг не случаен, проверьте, что его уже не запостили до вас. Пробегитесь поиском по баг-трекеру, используя ключевые слова. Если дубликатов не нашлось, можно начинать…

Или нет!

Не забудьте проверить, аффектит (проявляется) ли баг в других модулях. Условно, проверьте каждую кнопку «login» на сайте, определите, где она работает, а где — нет. Это сильно поможет разработчикам, а заодно сократит ваше время и повысит КПД.

Нажмите на картинку, чтобы увеличить изображение

Теперь начните оформлять баг-репорт, упоминая все детали и заполняя все указанные выше поля. Не забудьте написать детальные шаги для воспроизведения!
Примерно вот так выглядит пустой простенький баг-репорт. Естественно, такие поля как Labels и Components должны быть проставлены. Строки Status и Resolution предназначены для разработчиков, в Attachments добавляются видео и фото доказательства.
Советуем всегда держать под рукой чеклист, который будет резюмировать нашу статью.

1. Воспроизвел баг 2-3 раза
2. Проверил баг на дубликаты в баг-трекере
3. Проверил баг на всех возможных модулях
4. Написал подробный и понятный STR
5. Сделал подробное описание бага
6. Приложил понятный скриншот/видео с багом
7. Не пропустил указанные поля

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

Обсудить в форуме.