Топ-50 вопросов на собеседовании QA-инженера в 2026 году (с ответами)

QA-интервью проверяют три вещи: основы (можешь ли ты чётко говорить о концепциях тестирования), технические навыки (можешь ли ты писать и рассуждать о тест-коде), и суждение (принимаешь ли правильные решения когда нет очевидного ответа). Разница между слабым и сильным ответом обычно в конкретике, а не в технической глубине: "Я тестирую всё тщательно" провалится; конкретные риск-критерии которые ты реально применяешь: уже нет. Статья покрывает вопросы которые реально встречаются на QA-интервью 2026 года, сгруппированные по темам, с примерами обоих типов ответов.

Основы тестирования

В чём разница между верификацией и валидацией?

Верификация задаёт вопрос "строим ли мы продукт правильно?": проверяет соответствие продукта спецификациям, дизайнам и требованиям. Валидация задаёт вопрос "строим ли мы правильный продукт?": проверяет что продукт реально решает задачу пользователя.

Слабый ответ: "Верификация проверяет код, валидация проверяет продукт." Слишком размыто и путает понятия.

Сильный ответ: "Верификация внутренняя: соответствует ли сборка тому что было указано? Валидация внешняя: удовлетворяет ли то что мы построили реальной потребности пользователя? Продукт может пройти верификацию (точно соответствует спецификации) и провалить валидацию (спецификация ошибалась в том что нужно пользователям)."

В чём разница между тест-кейсом и тест-сценарием?

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

Объясни разницу между smoke-тестированием и регрессионным тестированием

Smoke-тестирование: поверхностная проверка самого критичного функционала после сборки. Запускается ли приложение, могут ли пользователи войти, работает ли основной флоу? Цель: быстро решить стоит ли сборка дальнейшего тестирования.

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

Что такое исследовательское тестирование?

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

В чём разница между black-box и white-box тестированием?

Black-box тестирование относится к системе как к чёрному ящику: знаешь только входные данные и ожидаемые результаты, но не внутреннюю реализацию. White-box тестирование использует знание внутреннего кода: пишешь тесты исходя из кодовых путей, ветвей и логики.

Большинство QA-инженеров занимаются black-box тестированием. Знание white-box полезно для понимания каких edge case стоит протестировать.

Проектирование тестов

Как решаешь что тестировать когда невозможно протестировать всё?

Риск-ориентированное тестирование: приоритизируй по вероятности отказа и его влиянию. Падение платёжного флоу: высокое влияние. Падение "tooltip при наведении": низкое влияние. Новая фича имеет более высокую вероятность отказа чем стабильная которая не менялась месяцами.

Слабый ответ: "Я тестирую всё тщательно." Никто не тестирует всё. Время и пайплайны не позволяют.

Сильный ответ: "Начинаю с понимания что изменилось и что несёт наибольший риск. Новый код получает больше покрытия чем неизменённый. Пользовательские флоу получают больше покрытия чем только-для-адмиов. Я бы также поговорил с разработчиком чтобы понять какие edge case вызывают наибольшую неопределённость."

Что такое классы эквивалентности и граничные значения?

Разбиение на классы эквивалентности делит входное пространство на группы где все значения в группе ведут себя одинаково. Вместо проверки каждого возможного возраста тестируешь одно значение из каждого раздела: до 18, 18–65, старше 65.

Анализ граничных значений тестирует границы этих разделов (17, 18, 65, 66) потому что баги концентрируются на границах. Код который корректно обрабатывает "18–65" часто имеет off-by-one ошибку именно на 18 или 65.

Опиши процесс написания тест-кейса для формы логина

Сильный ответ включает: happy path (валидные учётные данные → успех), негативные пути (неверный пароль, неверный логин, пустые поля, попытка SQL-инъекции, очень длинные входные данные), граничные случаи (минимальная/максимальная длина поля), нефункциональные аспекты (что если кнопка отправки нажата дважды).

Что должен содержать хороший баг-репорт?

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

Автоматизация

Когда нужно автоматизировать тест, а когда нет?

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

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

Что такое Page Object Model и зачем используется?

POM: паттерн проектирования который оборачивает взаимодействия со страницей в класс. Вместо вызова page.getByLabel('Username').fill(email) в каждом тесте создаёшь класс LoginPage с методом login(email, password). Тесты вызывают метод; когда форма логина меняется, правишь в одном месте.

Объясни пирамиду тестов

Юнит-тесты в основании: много, быстрые, дёшево писать и запускать. Тестируют отдельные функции и компоненты. Интеграционные тесты в середине: меньше, тестируют взаимодействия между компонентами. End-to-end тесты наверху: меньше всего, самые медленные, тестируют полные пользовательские флоу через UI.

Форма пирамиды важна. Её инверсия (в основном E2E тесты) даёт медленную обратную связь, высокие затраты на поддержку и флакающие сьюты.

Почему тест становится флакающим и как это исправить?

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

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

Playwright

Как работает auto-waiting в Playwright?

Каждое действие Playwright автоматически ждёт пока целевой элемент достигнет "actionable" состояния перед выполнением. Для click(): элемент должен быть видимым, стабильным и включённым. Для fill(): элемент должен быть редактируемым. Ожидание происходит автоматически с настраиваемым таймаутом (по умолчанию 30 секунд).

В чём разница между page.locator() и page.getByRole()?

Как обрабатывать аутентификацию в Playwright-тестах без входа в каждом тесте?

Используй storageState. Войди один раз в setup-файле, сохрани auth cookie и localStorage браузера в JSON-файл, затем настрой каждый тест загружать это состояние:

// Global setup: логинится и сохраняет auth state
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: {
  storageState: 'auth.json'
}

Каждый тест стартует уже аутентифицированным без прохождения через UI логина.

Что такое фикстура request и когда её использовать?

Agile и процессы

Как QA вписывается в спринт?

QA должен участвовать с самого начала: ревьюить требования и критерии приёмки на планировании, задавать уточняющие вопросы на грумминге, писать или ревьюить тест-кейсы до начала разработки. Тестирование не должно начинаться только когда разработка "завершена". Это создаёт узкое место в конце спринта.

Что такое shift-left тестирование?

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

Разработчик говорит что твой баг-репорт не баг. Как реагируешь?

Приноси доказательства: точные шаги воспроизведения, ожидаемое поведение из требований или дизайна, и фактическое поведение. Если это реально неоднозначно (нет в спеке), эскалируй к продукт-оунеру который решит приемлемо ли текущее поведение. Не спорь. Документируй.

Что делаешь когда находишь критичный баг за час до релиза?

Оцени влияние: кого затрагивает, как часто происходит, есть ли обходной путь? Немедленно эскалируй тимлиду и продукт-оунеру с оценкой влияния. Не держи релиз в тихую. Решение релизить, откладывать или делать хотфикс принадлежит продукт-оунеру, а не QA. Твоя работа: чётко и быстро обозначить риск.

Карьера и ситуационные вопросы

В чём разница между QA Engineer и SDET?

QA Engineer фокусируется на тест-стратегии, выполнении тестов и процессах качества. SDET (Software Development Engineer in Test): более инженерно-тяжёлая роль. Построение тест-фреймворков, тест-инфраструктуры, CI/CD пайплайнов и тест-инструментария. SDETs пишут код продакшн-качества для систем тестирования, а не просто тест-скрипты.

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

Расскажи о случае когда нашёл критичный баг поздно в процессе

Структурируй по STAR: Situation (что выпускалось), Task (твоя роль), Action (как нашёл, что сделал), Result (что произошло). Будь конкретен: цифры, таймлайны, реальное влияние. "Я нашёл баг который затронул бы всех пользователей checkout и мы отложили релиз чтобы исправить его" лучше чем "однажды я нашёл важный баг."

Как следишь за новыми QA-инструментами и практиками?

Называй конкретные вещи: блоги которые читаешь (Ministry of Testing, changelog Playwright), конференции (TestBash), рассылки, курсы которые прошёл. Общее "читаю статьи онлайн": слабый ответ. Конкретные источники и примеры: сильный.