Manual Testing

БЛОК 6. Работа с багами — 19. Как воспроизводить баг

📚 25 вопросовПройти тест →
Лекция

БЛОК 6. Работа с багами — 19. Как воспроизводить баг

Manual Testing

БЛОК 6. Работа с багами — 19. Как воспроизводить баг

🧭 Введение: зачем QA уметь воспроизводить баг

Найти проблему недостаточно. Если баг нельзя стабильно повторить, команда теряет время на уточнения и спорит, есть дефект или нет.
Воспроизводимость — это мост между "QA увидел странность" и "разработка может исправить". Для junior это один из самых практичных навыков в ежедневной работе.
💡 Совет:
Всегда думай: "Сможет ли другой человек повторить это по моим шагам за 2-3 минуты?"
✅ Вывод:
Хороший QA не только замечает баг, но и делает его повторяемым для команды.

⚠️ Проблема -> решение

Проблема: баг найден, но шаги неполные, данные не зафиксированы, окружение не указано. Итог: "не воспроизводится", тикет возвращают, цикл фикса тормозится.
Решение: использовать единый алгоритм воспроизведения: контекст -> шаги -> expected/actual -> повтор -> доказательства.
🟢 Если совсем просто:
Воспроизвести баг — значит показать повторяемый путь от чистого старта до той же ошибки.
🎯 Как понять, что этап прошел успешно:
Разработчик или другой QA проходит шаги и получает тот же результат.

🛠️ Чем помогает и как работает

Навык воспроизведения снижает шум в баг-трекере и ускоряет исправления. Команда получает не "жалобу", а готовый технический кейс.
Как это работает:
  • Шаг 1: зафиксировать исходное состояние.
  • Шаг 2: пройти действия в точной последовательности.
  • Шаг 3: зафиксировать expected и actual.
  • Шаг 4: повторить сценарий несколько раз.
  • Шаг 5: указать условия проявления и приложить доказательства.
✅ Вывод:
Структурное воспроизведение превращает баг в рабочую задачу для фикса.

📚 Ключевые термины (простыми словами)

  • Reproducibility — можно ли повторить дефект предсказуемо.
  • Repro steps — точные шаги, которые приводят к багу.
  • Repro rate — как часто баг повторяется (например, 5/5 или 2/10).
  • Preconditions — исходные условия, без которых баг может не проявиться.
  • Environment — где запускали проверку: окружение, build, устройство, браузер, роль.
  • Flaky bug — нестабильный баг, который проявляется не в каждом запуске.

1. Что значит "баг воспроизводится"

Эта тема часто понимается слишком узко. Воспроизводимость — это не "я один раз увидел ошибку", а "любой член команды может повторить путь к ней".
🟢 Если совсем просто:
Воспроизводимый баг можно повторить по шагам в понятных условиях.
🎯 Как понять, что этап прошел успешно:
Повтор на другом устройстве/у другого человека дает тот же сбой.
Назначение:
Отделить подтвержденный дефект от единичного наблюдения.
Простыми словами:
Один скрин без шагов — еще не воспроизводимость.
Для новичка:
Фиксируй не только "что сломалось", но и "как туда пришли".
✅ Вывод:
Воспроизводимость — это проверяемость пути к дефекту, а не просто факт ошибки.

2. Откуда начинать воспроизведение: baseline и preconditions

Одна из частых причин "не повторяется" — разные стартовые условия. Нужно явно фиксировать, с какого состояния вы начинали.
🟢 Если совсем просто:
Без preconditions даже хорошие шаги могут не сработать.
🎯 Как понять, что этап прошел успешно:
В репорте есть стартовое состояние: аккаунт, роль, данные, статус объекта, версия сборки.
Назначение:
Сделать старт сценария одинаковым для всех.
Простыми словами:
Сначала "в каком состоянии система", потом "что нажимали".
Для новичка:
Если баг зависит от роли, срока сессии или конкретных данных, укажи это до шагов.
Пример preconditions:
- Environment: staging- Build: 2.8.0- Role: operator- User has 1 active order in status "paid"- Browser: Chrome 123
✅ Вывод:
Четкий baseline экономит десятки минут на повторных уточнениях.

3. Алгоритм воспроизведения бага для junior

Нужен короткий алгоритм, который можно применять каждый день. Он снижает количество пропусков и делает работу спокойнее.
🟢 Если совсем просто:
Контекст -> шаги -> expected/actual -> повтор -> артефакты.
🎯 Как понять, что этап прошел успешно:
По алгоритму собран полный репро-кейс без "белых пятен".
Назначение:
Сделать воспроизведение системным и одинаковым между участниками команды.
Простыми словами:
Работаем по чек-ритму, а не "как получится".
Для новичка:
Если не уверен, где ошибся, проверь, не пропущен ли один из пяти этапов.
Алгоритм:
  1. Зафиксируй preconditions.
  2. Выполни действия по шагам.
  3. Сравни expected и actual.
  4. Повтори сценарий 3-5 раз.
  5. Добавь repro rate и доказательства.
✅ Вывод:
Один и тот же алгоритм повышает качество репортов всей команды.

4. Как писать шаги так, чтобы они реально работали

Шаги "нажать кнопку и всё упало" не помогают. Хорошие repro-steps должны быть конкретными и проверяемыми.
🟢 Если совсем просто:
Один шаг = одно действие.
🎯 Как понять, что этап прошел успешно:
В шагах нет двусмысленности, а expected/actual идут отдельно.
Назначение:
Сделать сценарий воспроизведения читаемым и машинально выполнимым.
Простыми словами:
Пиши так, чтобы шаги понял человек, который не знает фичу.
Для новичка:
Убирай слова "иногда", "примерно", "как обычно" — они ломают воспроизводимость.
Mini-правило хороших шагов:
  • точные;
  • короткие;
  • последовательные;
  • без предположений.
Сравнение:
СлабоСильно
"Логин ломается""После 5 неудачных попыток 6-й запрос возвращает 500"
"Нажать submit""Нажать Submit дважды с интервалом <1 секунды"
"Не работает на тесте""Staging, build 2.8.0, Chrome 123, role=manager"
✅ Вывод:
Чем точнее шаги, тем быстрее уходит баг в исправление.

5. Нестабильные (flaky) баги: как воспроизводить правильно

Не все дефекты проявляются 100% времени. Это не значит, что бага нет — это значит, что условия проявления сложнее.
🟢 Если совсем просто:
Для flaky-бага ключевые вещи: частота, условия, артефакты.
🎯 Как понять, что этап прошел успешно:
В репорте указано, когда баг проявляется, когда нет, и с какой частотой.
Назначение:
Сделать "плавающий" баг диагностируемым.
Простыми словами:
Покажи не только факт, но и паттерн проявления.
Для новичка:
Для flaky-сценариев фиксируй: сеть, время, нагрузку, параллельные действия, число повторов.
Пример:
Repro rate: 2/10Condition: network throttling (Fast 3G), retry payment in 5-10 sec windowObserved: duplicate charge appears only after timeout + retry combo
✅ Вывод:
Даже нестабильный дефект можно сделать рабочим для фикса, если правильно описать условия.

6. Минимальный набор данных для воспроизведения

Слишком короткий репорт не помогает, слишком длинный — перегружает. Нужен практичный минимум.
🟢 Если совсем просто:
Минимум = context + steps + expected/actual + repro rate + evidence.
🎯 Как понять, что этап прошел успешно:
Без созвона понятно, как и где повторить дефект.
Назначение:
Собрать достаточно данных с первого раза.
Простыми словами:
Не пиши роман, но и не оставляй баг без контекста.
Для новичка:
Проверь себя вопросом: "Если меня не будет онлайн, команда справится по этому тексту?"
Минимум для репро-пакета:
  • Environment + build + role;
  • Preconditions;
  • Steps to reproduce;
  • Expected / Actual;
  • Repro rate;
  • Вложения (скрин/видео/лог/запрос).
Мини-чеклист перед отправкой бага:
  • можно ли повторить;
  • есть ли preconditions;
  • есть ли environment;
  • есть ли repro rate;
  • есть ли доказательства;
  • понятны ли шаги.
Правило качества репро:
Если разработчик не может воспроизвести баг без созвона с QA, значит описание воспроизведения пока слабое и его нужно доработать.
✅ Вывод:
Качественный минимум лучше длинного, но размытого описания.

7. Воспроизведение vs оформление бага

Важно разделять этапы: сначала подтверждаем и стабилизируем репро, потом оформляем тикет в нужном формате.
🟢 Если совсем просто:
Воспроизведение отвечает на "как повторить", оформление — на "как передать в трекер".
🎯 Как понять, что этап прошел успешно:
Ты не путаешь этап проверки с этапом документации.
Назначение:
Сделать процесс понятным и линейным для junior.
Простыми словами:
Сначала доказали баг, затем красиво оформили.
Сравнение:
ЭтапГлавный вопросРезультат
ВоспроизведениеМожно ли повторить?Подтвержденный репро-кейс
ОформлениеКак передать команде?Структурный bug report
✅ Вывод:
Сильный QA сначала подтверждает дефект, потом оформляет его в трекере.

8. Что делать, если баг не воспроизводится

Такое бывает даже у опытных QA. Главное — не скрывать неопределенность и не отправлять сырой дефект как "точный".
🟢 Если совсем просто:
Если баг не повторяется, фиксируй как "intermittent / cannot reproduce yet" с условиями наблюдения.
🎯 Как понять, что этап прошел успешно:
В тикете честно зафиксировано: где увидели, сколько раз повторяли, какие условия пробовали.
Назначение:
Снизить ложные спорные баги и оставить полезный след для дальнейшей проверки.
Простыми словами:
Лучше честный "нужна дополнительная проверка", чем уверенный, но недоказанный дефект.
Для новичка:
Если не повторяется:
  1. перепроверь preconditions,
  2. попробуй другой браузер/роль/данные,
  3. добавь артефакты первого наблюдения.
✅ Вывод:
Невоспроизводимый баг тоже можно оформить полезно, если честно описать контекст и попытки повтора.

📌 Must-know факты

  • Воспроизводимость — обязательная часть качественного баг-цикла.
  • Preconditions так же важны, как и сами шаги.
  • Шаги должны быть точными, без двусмысленных слов.
  • Хорошее описание позволяет разработчику повторить дефект без участия QA в созвоне.
  • Для flaky-багов критичны repro rate и условия проявления.
  • Минимальный репро-пакет должен быть достаточным для повтора без созвона.

❗ Частые мифы

❌ Миф: Если QA один раз увидел ошибку, этого уже достаточно.
✅ Как правильно: Нужно подтвердить повторяемость и условия проявления.
📎 Почему это важно: Иначе баг быстро получает статус "не воспроизводится".
❌ Миф: Чем длиннее шаги, тем лучше.
✅ Как правильно: Нужны не длинные, а точные и проверяемые шаги.
📎 Почему это важно: Лишний шум усложняет повтор дефекта.
❌ Миф: Flaky-баги бессмысленно заводить.
✅ Как правильно: Их нужно заводить с repro rate и условиями проявления.
📎 Почему это важно: Такие дефекты часто становятся критичными в продакшене.
❌ Миф: Окружение можно не указывать, и так понятно.
✅ Как правильно: Environment, build, роль и данные обязательны.
📎 Почему это важно: Разные условия часто дают разный результат.

💬 Часто спрашивают на собеседованиях

❓ Вопрос: Что значит "баг воспроизводится"? ✅ Ответ: Это значит, что другой человек может повторить дефект по указанным шагам в описанных условиях.
❓ Вопрос: Какие данные обязательны для воспроизведения? ✅ Ответ: Окружение, версия сборки, роль/данные, preconditions, шаги, expected/actual и частота воспроизведения.
❓ Вопрос: Что делать с плавающим багом? ✅ Ответ: Указать repro rate, условия проявления и приложить артефакты, даже если баг проявляется не всегда.
❓ Вопрос: Почему preconditions так важны? ✅ Ответ: Без одинакового стартового состояния даже корректные шаги могут не дать тот же результат.
❓ Вопрос: Как понять, что шаги качественные? ✅ Ответ: Когда другой инженер без дополнительных вопросов повторяет дефект с первого захода.

🚨 Типичные ошибки

Ошибка 1: Нет исходных условий

Было:
Есть шаги, но не указан пользователь, роль и состояние данных.
Стало:
Перед шагами добавлены preconditions и environment.
Объяснение:
Разные стартовые условия дают разные результаты.

Ошибка 2: Шаги слишком общие

Было:
"Открыть страницу и попробовать оплатить".
Стало:
Четкая последовательность действий с конкретными полями и кнопками.
Объяснение:
Общие фразы не позволяют повторить дефект.

Ошибка 3: Не указан repro rate

Было:
"Иногда падает".
Стало:
"Repro rate: 3/10, проявляется при throttling и повторном submit".
Объяснение:
Частота и условия помогают поймать флейки.

Ошибка 4: Нет expected/actual

Было:
Описана только ошибка на экране.
Стало:
Expected и actual вынесены отдельными блоками.
Объяснение:
Без сравнения сложно понять, что именно нарушено.

Ошибка 5: Нет доказательств

Было:
Только текстовый комментарий.
Стало:
Добавлены скрин/видео/ответ API.
Объяснение:
Артефакты ускоряют диагностику.

✅ Best Practices

  • Перед воспроизведением всегда фиксируй preconditions.
  • Пиши шаги так, чтобы их выполнил человек без контекста.
  • Разделяй expected и actual на разные блоки.
  • Для flaky-багов всегда указывай repro rate и условия.
  • Добавляй минимальный набор доказательств сразу при обнаружении.
  • Если баг не повторяется, честно фиксируй попытки и условия.
  • Держи фокус на "повторить дефект", а не на длинном тексте.

🏁 Заключение

Воспроизводимость — это центр работы QA с дефектами. Именно она переводит проблему из наблюдения в рабочий кейс для исправления.
Если ты умеешь стабильно воспроизводить баг, команда быстрее чинит, меньше спорит и увереннее выпускает релизы.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 6. Работа с багами — 19. Как воспроизводить баг»

Пройти тест →