Дефекты и баг-репорты: вопросы для собеседования QA

Жизненный цикл дефекта — это последовательность статусов: New (зарегистрирован) → Open (подтверждён) → In Progress (в работе) → Fixed (исправлен) → Retest (на перепроверке) → Closed (закрыт). Также возможны Rejected (отклонён) и Deferred (отложен).

Severity показывает техническую тяжесть дефекта (насколько он влияет на систему), Priority — бизнес-срочность исправления. Пример: опечатка на главной странице — Severity Low, Priority High.

Из практики: если эти шкалы разделены, приоритизация становится прозрачной и быстрой — разработчик и менеджер говорят на одном языке без споров.

Я проверяю баг-репорт по простому правилу: любой человек в команде должен воспроизвести дефект без устных пояснений.

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

Из практики: перед созданием тикета всегда проверяю, достаточно ли данных для быстрого старта исправления.

Пример: опечатка в кнопке «Оплатить» на главной странице маркетинговой кампании.

Технически тяжесть низкая, но приоритет высокий, потому что ошибка заметна всем и бьёт по доверию и конверсии.

Из практики: такие дефекты часто чинят в первую очередь перед публичным запуском.

Пример: редкий сбой в фоновом расчёте отчёта для узкой роли администратора.

Серьёзность высокая, потому что нарушается корректность данных, но приоритет может быть ниже из-за маленькой аудитории и обходного пути.

Из практики: такие баги обычно планируют в ближайший релиз, но не всегда блокируют текущий.

Сначала фиксирую дефект с шагами воспроизведения и влиянием на пользователя, затем согласую серьёзность и приоритет.

После исправления обязательно делаю повторную проверку и контроль регрессии рядом с дефектной зоной.

Из практики: прозрачный цикл дефекта уменьшает споры и сокращает время от находки до закрытия.

Если баг не воспроизводится, сначала фиксирую окружение, данные, роль пользователя и точные шаги, при которых он возник.

Потом собираю артефакты: видео, логи, сетевой трейс, версию билда и время события, чтобы проверить гипотезы.

Из практики: такие дефекты часто завязаны на состояние данных, кэш или гонки, поэтому важна системная диагностика.

Смотрю на влияние на пользователя (блокирует ли ключевой сценарий), финансовый риск, частоту воспроизведения и срочность релиза.

Сначала закрываю блокеры и критичные регрессии на ключевых пользовательских путях, затем — высокий приоритет по бизнес-влиянию, потом остальное.

Из практики: если время ограничено, явно фиксирую с командой: «этот дефект выпускаем осознанно, риск принят» — это убирает претензии после релиза и делает решение прозрачным.

Сначала фиксируют известную информацию: окружение, шаги, частоту, время появления. Дальше — сужают: что общее между воспроизведениями (нагрузка, конкретный пользователь, время суток, состояние БД).

Полезно: записать видео, собрать логи приложения и сервера во время воспроизведения, использовать инструменты сетевого мониторинга. Помогают повторные прогоны автотестом с записью трасс.

Из практики: если воспроизвести стабильно не удаётся, заводят тикет с пометкой intermittent и подробной телеметрией. Без воспроизведения исправление может закрыть симптом, а не причину.

Retest — это проверка конкретного шага из тикета на сборке с фиксом. Подтверждаем, что баг больше не воспроизводится в тех же условиях.

После retest проводят таргетированную регрессию — функциональность, которая могла бы пострадать от изменения (соседние экраны, общие компоненты). Не обязательно полную регрессию, но достаточную, чтобы поймать побочки.

Из практики: если исправление точечное, регрессия маленькая. Если фикс затронул общий слой (контроллер, утилита) — регрессия шире. Глубину выбирают по риску.

Баг — это несоответствие реализации задокументированному требованию или базовому здравому смыслу (приложение упало, формула неверная, форма не отправляется). Фича-запрос — это просьба расширить функциональность.

Грань размыта, когда требований нет или они устарели. Тогда обсуждают с PM/разработкой, что считать «правильным поведением». Часто полезно классифицировать как «UX issue» — не критичный баг, но и не новая фича.

Из практики: лучше фиксировать всё и обсуждать классификацию в груминге. Это позволяет команде осознанно принять решение, а не игнорировать.

Reopened — это статус, в который переводят закрытый дефект, если он снова воспроизводится. Это сигнал, что исправление не сработало или появились новые условия.

При reopening важно описать: на какой сборке воспроизвели, что именно отличается от первого закрытия, и были ли изменены условия (другие данные, другая версия зависимости).

Из практики: количество reopened — индикатор качества исправлений. Если бьёт высокий процент — проблема в процессе (плохое retest, поспешные фиксы).

Минимум: заголовок (краткий и описательный), шаги воспроизведения, ожидаемый и фактический результат, окружение (версия приложения, ОС, устройство, версия БД и т.д.), приоритет/серьёзность, артефакты (скриншоты, видео, логи).

Дополнительно полезно: ссылка на тестовые данные, ID запроса/трассы, точное время воспроизведения, частота (всегда/иногда).

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

Триаж — это регулярный процесс (часто еженедельный) разбора накопленных тикетов: каждому проставляют приоритет, оценивают, назначают исполнителя, решают, в какую итерацию брать или откладывать.

Участвуют обычно PM, лид разработки, лид QA. Это снижает риски «горы тикетов в бэклоге» и помогает увидеть тенденции (где больше всего багов, повторяющиеся темы).

Из практики: без регулярного триажа бэклог багов превращается в свалку, где половина уже неактуальна или дублирует другие.

Регрессионный баг — это дефект в ранее работавшей функциональности, появившийся после изменений в смежной или общей логике.

Признаки: ещё вчера работало, проявляется после релиза/мерджа определённой ветки. Часто выявляется регрессионным набором или жалобой пользователей.

Из практики: при заведении такого бага полезно найти и указать коммит/PR, в котором сломалось (git bisect помогает). Это ускоряет исправление и анализ причин.

Цель — оставить только те шаги, без которых баг не воспроизводится. Метод половинного деления: убираем половину шагов, проверяем; если воспроизводится — продолжаем убирать, если нет — возвращаем.

Также проверяют, не зависит ли баг от данных (другой пользователь, чистая БД), от окружения (другая версия браузера), от последовательности (что если шаги в другом порядке).

Из практики: качественно минимизированный тикет иногда укладывается в 3 шага вместо 10 первоначальных. Это сильно ускоряет разработку и снижает риск пропустить причину.

Кеш в браузере или CDN (получают старую версию ассета), несвежие тестовые данные, неверная среда (тестировал на dev, а запрос пошёл к stage), фича-флаги выключены/включены некстати, неверные права у тестового пользователя.

Также: некорректное ожидание тестировщика (требование уже изменилось), неполная установка фикса (часть подмодулей не обновлена).

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

Сначала проверить, нет ли реального недоразумения: возможно, не хватает шагов, видео, окружения, или требование действительно неоднозначно. Уточнить требования у PM или показать пользовательский сценарий.

Если разногласие остаётся — эскалировать спокойно, через тимлида или продакт-менеджера. Цель — не «доказать», а вместе принять решение: фиксить, отложить, переформулировать требование.

Из практики: помогают записанные видео и факты («10 пользователей упомянули в support»). Эмоциональный спор продуктивен редко.

Heisenbug — баг, который исчезает или меняется при попытке отладки. Причины: race condition, чувствительность к таймингу, влияние логирования/отладчика.

Стратегия: меньше менять окружение, использовать неинвазивное логирование (структурированные логи), записывать состояние без приостановки.

Из практики: в asyncio, многопоточном коде, реактивных системах heisenbugs встречаются часто. Помогает chaos-engineering и стресс-тестирование.

Bohrbug — стабильно воспроизводимый баг (антоним heisenbug). Назван по модели атома Бора — детерминированный.

Это «обычные» баги — есть чёткие шаги, всегда падает. Самый частый вид и самый удобный для разработчика.

Из практики: ваша цель — превратить heisenbug в bohrbug через сужение условий воспроизведения.

Подход: формулируем гипотезу о возможном баге, целенаправленно её проверяем. Не «протестируй всё», а «проверим, что произойдёт, если ...».

Часто помогает интуиция, опыт, обсуждение с разработчиком. Эффективно для исследования рисков и пограничных случаев.

Из практики: на встрече с разработчиком обсуждается, где он сомневается — там и проверяют.

Чек-лист: пустое, пробелы, очень длинная строка, специальные символы, юникод (эмодзи, RTL), HTML/JS-инъекции, числа за пределами диапазона, отрицательные, нули, leading zeros.

Также: вставка из буфера, autofill, формат (email с/без точки, телефон с/без + и пробелов).

Из практики: формы — кладезь багов. Чек-лист накапливается с опытом и помогает не упускать.

Часовые пояса (хранение/отображение), летнее время (DST), високосный год/секунда, 31 декабря/1 января (конец года), начало эпохи (1970), пограничные времена (полночь).

Также: разные форматы (DD.MM vs MM-DD), локализация месяцев, неделя начинается с понедельника или воскресенья.

Из практики: типовые баги — отображение времени в неправильном поясе, накопление расхождений из-за DST, год 2038 (32-bit timestamp).

Валюты с разным числом знаков (JPY — без копеек, KWD — 3 знака), округление, маленькие суммы (1 копейка), большие (миллионы), отрицательные (refund), смена валюты.

Также: двойное списание, отмена в середине, успех на банке/неуспех у нас, сетевые проблемы.

Из практики: платежи — самая опасная зона. Тестируют через песочницы провайдеров, чек-лист включает десятки сценариев.

Разные алфавиты, RTL (арабский, иврит), длина переводов (немецкий шире), форматы дат и чисел, валюты, имена (только латинские буквы — антипаттерн), культурные особенности (имя/фамилия).

Также: SMS-валидаторы только под русские номера, поля адреса без поддержки иностранных форматов.

Из практики: pseudo-локализация (Тëśт Łèńğìвàĝê) помогает находить нелокализованные строки и проблемы с длиной.

После нахождения бага задают вопрос: «А где ещё может быть похожая проблема?». Если в этой функции — может ли быть в смежной с похожей логикой?

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

Из практики: нашли утечку в одном экране — проверьте все экраны со схожей логикой. Найденная инъекция в одной форме — повод проверить все формы.