11 вопросов по теме «QA: Баги и процессы» на собеседовании

Короткий ответ: Severity — это техническое влияние дефекта на систему (насколько всё сломано), его выставляет QA. Priority — бизнес-срочность фикса (насколько быстро надо чинить), его выставляет PM или лид. Это две независимые оси: баг может быть одновременно очень серьёзным и совсем не срочным.

Подробно:

1. Severity (важность) — объективная характеристика: краш, потеря данных, блокировка функции против косметики. Ставит тестировщик.
2. Priority (приоритет) — субъективная бизнес-оценка: сколько пользователей задето, репутация, дедлайны релиза. Ставит PM/владелец продукта.
3. Почему разделяют — ресурсы ограничены, и очередь на фикс выстраивают по Priority, а не по Severity.

⚠️ Частая ошибка: путать оси или считать, что высокая Severity автоматически означает высокий Priority. Интервьюер слушает именно то, кто какую ось решает: Severity — QA, Priority — бизнес.

Короткий ответ: New → Assigned → In Progress → Fixed → Retest → Closed. Это основной поток, но у него есть важные ветвления: Reopened (баг вернулся после фикса), Rejected (не баг), Duplicate (уже заведён), Deferred (отложен). Ключ в ответе — назвать не только линию, но и ветки, и кто выполняет каждый переход.

Подробно:

1. New — тестировщик завёл баг.
2. Assigned → In Progress — лид назначил разработчика, тот взял в работу.
3. Fixed — разработчик починил и передал на проверку.
4. Retest → Closed — тестировщик перепроверил на новом билде и закрыл.
5. Ветки — Reopened (тестировщик), Rejected/Duplicate (разработчик или лид), Deferred (PM отложил на потом).

 New ──► Assigned ──► In Progress ──► Fixed ──► Retest ──► Closed
 (QA)     (лид)         (dev)         (dev)     (QA)       (QA)
           │                                      │ не прошёл
           ▼                                      ▼
 Rejected / Duplicate (dev, лид)           Reopened ──► снова в работу
 Deferred (PM отложил)

⚠️ Частая ошибка: назвать только прямую линию New→Closed и забыть про ветки Reopened/Rejected/Duplicate/Deferred — именно они показывают, что вы работали с реальным трекером.

Короткий ответ: Понятный заголовок, окружение (ОС/браузер/билд), предусловия, шаги воспроизведения, ожидаемый и фактический результат, severity/priority и вложения (скриншот, лог, видео). Хороший репорт разработчик воспроизводит без единого уточняющего вопроса.

Подробно:

⚠️ Частая ошибка: самое частое упущение — не разделить «ожидаемый vs фактический». Без явного ожидаемого результата разработчик не понимает, баг это или так и задумано, и репорт превращается в спор.

Короткий ответ: Definition of Done (DoD) — это общий, согласованный командой чек-лист критериев, при выполнении которых задача считается готовой. QA-часть DoD должна быть конкретной и измеримой: тест-кейсы написаны и выполнены, нет открытых critical/high багов, регрессия пройдена.

Подробно:

1. DoD общий для команды — код-ревью пройдено, тесты зелёные, задокументировано, задеплоено на stage.
2. QA-ворота в DoD — конкретные пункты, за которые отвечает тестирование:

[ ] Тест-кейсы написаны и покрывают acceptance criteria
[ ] Все тест-кейсы выполнены на нужном окружении
[ ] Нет открытых багов Critical / High
[ ] Регрессия затронутых областей пройдена
[ ] Баги заведены и приняты разработкой

3. Зачем — DoD убирает споры «готово / не готово» и не даёт протащить недотестированную задачу в релиз.

⚠️ Частая ошибка: расплывчатая формулировка «тестирование завершено» без измеримых критериев. «Завершено» — это сколько кейсов, какая регрессия, какой порог по багам? Без чисел DoD не работает.

Короткий ответ: Не гадать молча, а действовать проактивно: уточнить у BA/PM/аналитика, зафиксировать допущения письменно в тест-плане и поднять неоднозначность как можно раньше — на этапе ревью требований, а не когда баг уже нашли на проде.

Подробно:

1. Уточнить у источника — задать конкретные вопросы аналитику, PM или владельцу продукта, а не соседу-тестировщику.
2. Зафиксировать допущения — если ответа нет сразу, записать своё предположение в тест-план и явно пометить его как допущение.
3. Поднять рано — противоречие, найденное на ревью требований, стоит дёшево; найденное в тестировании — дорого; на проде — очень дорого.
4. Задокументировать — оставить след в тикете/чате, чтобы решение было прослеживаемо.

Неясное требование
   │
   ├─► Вопрос BA/PM ──► Ответ ──► Тестируем по ответу
   │
   └─► Нет ответа ──► Допущение в тест-план ──► Флаг команде

⚠️ Частая ошибка: пассивно жаловаться «требования плохие» и потом молча угадывать поведение в ходе выполнения. Интервьюер проверяет проактивность, а не умение терпеть.

Короткий ответ: Спорить не мнениями, а доказательствами: показать требование, спеку или acceptance criteria, которым поведение противоречит, и объяснить влияние на пользователя и бизнес. Если консенсуса нет — арбитр PM/BA, а несогласие документируется. Интервьюер проверяет зрелость коммуникации, а не то, кто технически прав.

Подробно:

1. Сверить со спекой — есть ли явное требование или acceptance criteria? Если да — это баг, вопрос закрыт.
2. Показать влияние — на пользователя, конверсию, данные; факты вместо «мне кажется».
3. Спека молчит — значит неоднозначность требований: это отдельная проблема для BA/PM.
4. Эскалация к арбитру — решение принимает PM/владелец продукта, а не громкость голоса.
5. Задокументировать — зафиксировать решение в тикете, чтобы не спорить об этом снова.

Спор ──► Спека/AC? ──да──► Баг, чиним
            │
            нет
            ▼
     Влияние на юзера? ──► PM/BA арбитр ──► Решение в тикет

⚠️ Частая ошибка: уйти в личный спор «баг / не баг» на эмоциях или молча закрыть тикет. Правильно — вернуться к требованиям и эскалировать через процесс, сохранив рабочие отношения.

Короткий ответ: Отвечать по STAR и честно: взять ownership без перевода стрелок, разобрать root cause и — главное — назвать конкретное изменение процесса, которое родилось из этого случая (новый регрессионный чек, лучшие тест-данные, мониторинг). Оценивают не сам баг, а вашу реакцию на него.

Подробно:

S — Situation: релиз оплаты, пятница, узкое релизное окно.
T — Task: за мной был регресс чекаута.
A — Action: я не проверил комбинацию «скидка + иностранная карта».
R — Result: 3 часа падали ~8% платежей; откатили, зафиксили.
           Урок: добавил этот кейс в регресс + алерт на error-rate.

1. Ownership — «я пропустил», а не «разработчик написал баг» или «мало времени дали».
2. Root cause — почему пропустил: пробел в тест-дизайне, не покрытая комбинация, нестабильное окружение.
3. Изменение процесса — новый кейс в регрессии, мониторинг/алерты, ревью тест-данных. Это и есть суть ответа.

⚠️ Частая ошибка: рассказать драматичную историю без вывода — что именно изменилось после. Баг без изменения процесса звучит так, будто он повторится завтра.

Короткий ответ: В Waterfall тестирование — отдельная поздняя фаза после того, как вся разработка закончена. В Agile тестирование идёт непрерывно в каждом спринте, а QA встроен в процесс с этапа требований — это и есть shift-left. Тестировщик перестаёт быть «последним рубежом» и становится частью команды с первого дня.

Подробно:

⚠️ Частая ошибка: не назвать shift-left или описать под словом «Agile» ту же водопадную модель — «сначала всё разработали, потом за спринт до релиза протестировали». Суть Agile именно в раннем и непрерывном вовлечении QA.

Короткий ответ: Не давать одно число «на глаз», а декомпозировать работу и оценивать техниками. Planning Poker — командная оценка стори-поинтами: каждый втайне выбирает карту из ряда Фибоначчи (1, 2, 3, 5, 8, 13…), затем все вскрывают одновременно — это убирает якорение на мнении самого громкого.

Подробно:

1. Декомпозиция — разбить фичу на области/типы тестов (функционал, регресс, интеграция), оценивать по частям.
2. Planning Poker — карты Фибоначчи, одновременное вскрытие; расхождение оценок обсуждают, а не усредняют вслепую.
3. Триангуляция — сравнить с похожей прошлой задачей: «эта примерно как та, что заняла 3 дня».
4. Запас на риски — нестабильное окружение, новые интеграции, неполные требования — закладываем буфер.

⚠️ Частая ошибка: назвать одно число без декомпозиции и без учёта рисков. Оценка — это диапазон и обоснование, а не пальцем в небо.

Короткий ответ: Error (mistake) — ошибка человека; defect (bug, fault) — её материальный след в коде или другом артефакте; failure — проявление дефекта при выполнении, когда система ведёт себя не так, как ожидалось. Это цепочка причин и следствий по терминологии ISTQB.

Подробно:

1. Error — человек ошибся: неверно понял требование, опечатался в формуле.
2. Defect — эта ошибка воплотилась в артефакте: строка кода, пункт спеки, тест-кейс.
3. Failure — дефект сработал в рантайме: пользователь увидел неверный результат или краш.

Error            Defect              Failure
(человек)   ──►  (в коде/артефакте) ──►  (при выполнении)
не понял         баг в строке          система упала
требование       или спеке             / выдала не то

⚠️ Частая ошибка (и бонус к ответу): думать, что каждый дефект неизбежно приводит к failure. Не приводит: дефект в мёртвом коде или на недостижимой ветке никогда не выполнится и failure не породит.

Короткий ответ: Сразу после сборки и деплоя, до глубокого тестирования — как быстрый gate. Smoke проверяет, что критичное ядро вообще работает (приложение поднялось, логин проходит, главные экраны открываются). Красный smoke блокирует дальнейшие стадии пайплайна, чтобы не гонять часовую регрессию по заведомо мёртвому билду.

Подробно:

1. Момент запуска — сразу после build/deploy, первым автоматическим шагом.
2. Роль gate — зелёный smoke = билд достаточно живой, чтобы тестировать глубже; красный = стоп, дальше нет смысла.
3. Что покрывает — только базовые критичные пути, быстро (минуты, не часы); это не регрессия.

 build ──► deploy ──► SMOKE ──зелёный──► регрессия / e2e
                        │
                     красный
                        ▼
                  билд отклонён, пайплайн стоп

⚠️ Частая ошибка: пересказать определение «smoke — это поверхностная проверка» и не привязать её к конкретному моменту пайплайна. Сильный ответ называет именно «сразу после деплоя, как gate перед глубоким прогоном».