Баг-репорт — это документ, который тестировщик заводит при обнаружении дефекта, чтобы разработчик мог однозначно понять, что сломалось, как это повторить и в каком виде система должна была себя вести вместо этого. Хороший баг-репорт содержит минимум пять обязательных элементов: заголовок, шаги воспроизведения, ожидаемый результат, фактический результат и окружение — без любого из них разработчику придётся возвращаться к тестировщику с уточняющими вопросами, теряя время обоих.
Зачем нужен баг-репорт, если можно просто написать разработчику в чат?
Сообщение в духе «там кнопка не работает» технически передаёт информацию о проблеме, но не даёт разработчику ничего, с чем можно сразу начать работать: неясно, какая именно кнопка, на какой странице, при каких условиях, что значит «не работает» — не нажимается, нажимается, но ничего не происходит, или происходит не то. Баг-репорт — это структурированная форма той же самой жалобы, где ответы на все эти вопросы заданы заранее и в одном и том же порядке для любого дефекта в проекте. Это резко сокращает количество итераций «уточни, пожалуйста» между тестировщиком и разработчиком и делает дефект воспроизводимым не только автором репорта, но и любым другим членом команды.
Из каких полей состоит баг-репорт?
Баг-репорт строится вокруг пяти элементов, обязательных для однозначности (заголовок, шаги воспроизведения, ожидаемый и фактический результат, окружение), и дополняется ещё двумя, которые ускоряют сортировку и разбор дефекта в команде (severity/priority, вложения):
— Заголовок (Summary) — короткая, конкретная формулировка проблемы с указанием места и сути: «Кнопка "Оплатить" не активна при пустой корзине с одним удалённым товаром», а не просто «Ошибка на странице оплаты».
— Шаги воспроизведения (Steps to Reproduce) — пронумерованная, максимально короткая последовательность действий, которая гарантированно приводит к дефекту у любого, кто её повторит.
— Ожидаемый результат (Expected Result) — как система должна была себя повести согласно требованиям, документации или здравому смыслу.
— Фактический результат (Actual Result) — что произошло на самом деле, максимально конкретно, без интерпретаций и оценочных слов вроде «плохо» или «неправильно».
— Окружение (Environment) — браузер и его версия, ОС, разрешение экрана, тестовый стенд или билд приложения — всё, что может влиять на воспроизводимость именно в этих условиях.
— Severity и Priority — насколько дефект серьёзен по своим последствиям и насколько срочно его нужно чинить — два разных параметра (подробнее — в следующем разделе).
— Вложения (Attachments) — скриншоты, видео, логи, дамп сетевого запроса — всё, что помогает разработчику увидеть проблему без необходимости самому её воспроизводить.
— Заголовок (Summary) — короткая, конкретная формулировка проблемы с указанием места и сути: «Кнопка "Оплатить" не активна при пустой корзине с одним удалённым товаром», а не просто «Ошибка на странице оплаты».
— Шаги воспроизведения (Steps to Reproduce) — пронумерованная, максимально короткая последовательность действий, которая гарантированно приводит к дефекту у любого, кто её повторит.
— Ожидаемый результат (Expected Result) — как система должна была себя повести согласно требованиям, документации или здравому смыслу.
— Фактический результат (Actual Result) — что произошло на самом деле, максимально конкретно, без интерпретаций и оценочных слов вроде «плохо» или «неправильно».
— Окружение (Environment) — браузер и его версия, ОС, разрешение экрана, тестовый стенд или билд приложения — всё, что может влиять на воспроизводимость именно в этих условиях.
— Severity и Priority — насколько дефект серьёзен по своим последствиям и насколько срочно его нужно чинить — два разных параметра (подробнее — в следующем разделе).
— Вложения (Attachments) — скриншоты, видео, логи, дамп сетевого запроса — всё, что помогает разработчику увидеть проблему без необходимости самому её воспроизводить.
Как правильно оформить шаги воспроизведения?
Шаги воспроизведения описывают поведение системы, а не действия самого тестировщика — правильно писать «Сообщение об ошибке отобразилось», а не «Я увидел сообщение об ошибке»: первая формулировка описывает объективный факт, который любой другой человек может проверить и получить тот же результат, вторая — личное наблюдение, которое ничего не гарантирует стороннему читателю. Хорошие шаги воспроизведения — это инструкция, где на каждом шаге результат детерминирован и не оставляет пространства для двух разных толкований: если шаг допускает несколько вариантов действия («перейти в раздел настроек» — а если разделов настроек несколько?), дефект может не воспроизвестись у того, кто трактует шаг иначе, чем автор репорта. Шаги также стоит сокращать до минимально необходимого набора действий — если дефект воспроизводится за 3 шага, а не за 10, разработчику нужны именно эти 3, без лишнего контекста, который не влияет на результат.
Чем ожидаемый и фактический результат отличаются от описания самого бага?
Ожидаемый и фактический результат — это не пересказ заголовка другими словами, а конкретные, проверяемые утверждения о состоянии системы. «Ожидаемый результат: кнопка "Оплатить" активна, если в корзине остался хотя бы один товар» и «Фактический результат: кнопка "Оплатить" неактивна (disabled), хотя в корзине остался один товар» — это два самостоятельных факта, каждый из которых можно проверить независимо от другого. Формулировка «должно работать корректно» в качестве ожидаемого результата — типичная ошибка новичков: она не говорит, что именно считается «корректным», и вынуждает разработчика додумывать критерий самому.
Чем severity отличается от priority?
Severity (серьёзность) и priority (приоритет) отвечают на два разных вопроса и почти всегда заполняются разными людьми: severity описывает объективное техническое влияние дефекта на систему (насколько сильно он ломает функциональность) и обычно выставляется тестировщиком, priority описывает, насколько срочно бизнесу нужно, чтобы дефект починили именно сейчас, и обычно определяется менеджером или продуктовой командой с учётом текущих приоритетов проекта. Дефект может быть высокой severity, но низкой priority (критичный краш в редко используемой административной функции, которую почти никто не открывает) — и наоборот, низкой severity, но высокой priority (опечатка в названии продукта на главной странице перед важной презентацией инвесторам, технически безобидная, но требующая немедленного исправления).
Какие уровни severity и priority стоит запомнить?
— Blocker — полностью останавливает работу с системой или тестирование, обхода нет. Типичный priority: Highest.
— Critical — ломает ключевую функциональность, обход есть, но неудобный или рискованный. Типичный priority: High.
— Major — заметно нарушает работу отдельной функции, есть приемлемый обход. Типичный priority: Medium.
— Minor — небольшое неудобство, не мешает выполнить задачу. Типичный priority: Low.
— Trivial — косметический дефект (опечатка, смещение пикселя), не влияет на функциональность. Типичный priority: Low или Lowest.
Соответствие между severity и priority здесь — типичный случай, а не жёсткое правило: реальный приоритет всегда может отличаться от «ожидаемого» по severity, если у бизнеса другие соображения (сроки, видимость дефекта для конкретного клиента, приближающийся релиз).
— Critical — ломает ключевую функциональность, обход есть, но неудобный или рискованный. Типичный priority: High.
— Major — заметно нарушает работу отдельной функции, есть приемлемый обход. Типичный priority: Medium.
— Minor — небольшое неудобство, не мешает выполнить задачу. Типичный priority: Low.
— Trivial — косметический дефект (опечатка, смещение пикселя), не влияет на функциональность. Типичный priority: Low или Lowest.
Соответствие между severity и priority здесь — типичный случай, а не жёсткое правило: реальный приоритет всегда может отличаться от «ожидаемого» по severity, если у бизнеса другие соображения (сроки, видимость дефекта для конкретного клиента, приближающийся релиз).
Какие вложения стоит добавлять к баг-репорту?
Скриншот нужен почти всегда, если дефект визуальный — он показывает состояние экрана без необходимости разработчику воспроизводить баг самостоятельно, чтобы просто увидеть, о чём речь. Видео полезно для дефектов, которые проявляются в динамике или последовательности действий (анимация, drag-and-drop, race condition), где статичный скриншот не передаёт сути проблемы. Логи (консоль браузера, серверные логи, ответ API) особенно ценны для дефектов, где визуально всё выглядит нормально, но под капотом что-то идёт не так — например, запрос вернул 500-ю ошибку, а интерфейс тихо проглотил её и показал пустой экран вместо явного сообщения об ошибке.
Какие вопросы про баг-репорты чаще всего задают на собеседованиях?
Нужно ли заводить баг-репорт на каждую мелочь, даже опечатку? Да, но опечатка обычно получает низкую severity и priority, а не пропускается вовсе — если не завести репорт, дефект просто нигде не зафиксирован и может быть забыт до следующего релиза, где его снова придётся искать заново. Массовые мелкие визуальные дефекты (например, десятки одинаковых отступов) иногда группируют в один репорт со списком мест, а не заводят по одному — это решение команды, а не универсальное правило.
Что делать, если баг не воспроизводится стабильно? Указать в репорте частоту воспроизведения максимально честно («воспроизводится 3 из 10 попыток») вместо того, чтобы писать шаги как гарантированно рабочие, если это не так. Для нестабильных (флаки) дефектов особенно важны логи и видео с момента, когда баг всё же проявился, — без них разработчику будет крайне сложно найти причину методом чтения кода.
Кто должен определять severity — тестировщик или разработчик? Обычно тестировщик выставляет первоначальную severity при создании репорта, основываясь на объективном техническом влиянии дефекта, а разработчик или тимлид может скорректировать её при ревью, если видит нюанс, не учтённый тестировщиком (например, что затронутый код на самом деле не используется в проде). Priority чаще выставляет менеджер или владелец продукта, а не тестировщик — потому что приоритет завязан на бизнес-контекст, который тестировщику может быть не виден полностью.
Можно ли объединять несколько разных дефектов в один баг-репорт? Не стоит, даже если они найдены на одном экране почти одновременно — каждый дефект должен чиниться и проверяться независимо, а один репорт на несколько разных проблем неизбежно создаёт путаницу: разработчик исправит одну часть, репорт формально остаётся открытым, потому что вторая часть не решена, и непонятно, что именно осталось проверить при повторном тестировании (ретесте).
Чем баг-репорт отличается от фича-реквеста (feature request)? Баг-репорт фиксирует несоответствие: система ведёт себя не так, как должна согласно требованиям или здравому смыслу. Фича-реквест — это предложение добавить новую возможность или изменить поведение, которое и раньше было задумано именно таким, дефектом не является. Разница важна практически: баг обычно уходит в текущий спринт на исправление, а фича-реквест — в бэклог продукта на приоритизацию и обсуждение с продакт-менеджером. Если тестировщик сомневается, к какой категории отнести находку, стоит завести именно баг-репорт с пометкой «на уточнение» — разработчик или аналитик при ревью может переклассифицировать его в фича-реквест, если увидит, что поведение было осознанным.
Как быстро научиться писать баг-репорты так, чтобы их сразу понимали разработчики? Быстрее всего — не по теории, а на практике: написать десяток репортов на реальных багах и получить обратную связь от того, кто их читает (ментора, лида, самого разработчика) — какие формулировки были неоднозначными, какие шаги пришлось уточнять. Собственный чек-лист из повторяющихся замечаний обычно закрывает 90% типичных ошибок быстрее, чем чтение любого количества шаблонов.
Что делать, если баг не воспроизводится стабильно? Указать в репорте частоту воспроизведения максимально честно («воспроизводится 3 из 10 попыток») вместо того, чтобы писать шаги как гарантированно рабочие, если это не так. Для нестабильных (флаки) дефектов особенно важны логи и видео с момента, когда баг всё же проявился, — без них разработчику будет крайне сложно найти причину методом чтения кода.
Кто должен определять severity — тестировщик или разработчик? Обычно тестировщик выставляет первоначальную severity при создании репорта, основываясь на объективном техническом влиянии дефекта, а разработчик или тимлид может скорректировать её при ревью, если видит нюанс, не учтённый тестировщиком (например, что затронутый код на самом деле не используется в проде). Priority чаще выставляет менеджер или владелец продукта, а не тестировщик — потому что приоритет завязан на бизнес-контекст, который тестировщику может быть не виден полностью.
Можно ли объединять несколько разных дефектов в один баг-репорт? Не стоит, даже если они найдены на одном экране почти одновременно — каждый дефект должен чиниться и проверяться независимо, а один репорт на несколько разных проблем неизбежно создаёт путаницу: разработчик исправит одну часть, репорт формально остаётся открытым, потому что вторая часть не решена, и непонятно, что именно осталось проверить при повторном тестировании (ретесте).
Чем баг-репорт отличается от фича-реквеста (feature request)? Баг-репорт фиксирует несоответствие: система ведёт себя не так, как должна согласно требованиям или здравому смыслу. Фича-реквест — это предложение добавить новую возможность или изменить поведение, которое и раньше было задумано именно таким, дефектом не является. Разница важна практически: баг обычно уходит в текущий спринт на исправление, а фича-реквест — в бэклог продукта на приоритизацию и обсуждение с продакт-менеджером. Если тестировщик сомневается, к какой категории отнести находку, стоит завести именно баг-репорт с пометкой «на уточнение» — разработчик или аналитик при ревью может переклассифицировать его в фича-реквест, если увидит, что поведение было осознанным.
Как быстро научиться писать баг-репорты так, чтобы их сразу понимали разработчики? Быстрее всего — не по теории, а на практике: написать десяток репортов на реальных багах и получить обратную связь от того, кто их читает (ментора, лида, самого разработчика) — какие формулировки были неоднозначными, какие шаги пришлось уточнять. Собственный чек-лист из повторяющихся замечаний обычно закрывает 90% типичных ошибок быстрее, чем чтение любого количества шаблонов.
Где отработать написание баг-репортов на практике?
Теория про поля и severity/priority — база, но реальный навык появляется только тогда, когда сам разбираешь баги на настоящем проекте и получаешь обратную связь от ментора, а не оцениваешь себя сам. В Quality Academy на курсе «Инженер по ручному тестированию» баг-репорты — часть практики с первых недель: 75+ домашних заданий в Jira с проверкой ментора, тиры трижды в неделю с теоретическими и практическими разборами.
-------
Полезные ссылки школы
Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena