Мок-собеседование тестировщика 2026: 20 вопросов Junior и Middle QA
Это не список терминов для заучивания, а репетиция технического интервью. Поставь таймер, отвечай вслух и только потом открывай разбор. У каждого вопроса есть критерии сильного ответа и типичная ошибка кандидата.
Как пройти мок-собеседование с пользой
На реальном интервью важно не только знать ответ, но и собрать его без долгой паузы. Дай себе 90 секунд на теоретический вопрос и до пяти минут на ситуационный. Говори вслух: мысленный ответ почти всегда кажется стройнее, чем произнесённый.
Не пытайся повторить формулировку из разбора. Сверяй структуру: обозначила ли цель, риск, конкретную проверку, ожидаемый результат и доказательство. Именно этот ход мысли отличает рабочий ответ от выученного определения.
- Уточнить контекст и ограничения
- Назвать главный риск
- Предложить конкретные проверки
- Объяснить ожидаемый результат
Засчитывай вопрос, только если сначала ответила вслух, а потом открыла разбор.
- 0 Нет ответа или перечислены случайные термины без связи с вопросом. 0 · пробел
- 1 Есть верное определение, но нет примера, ожидаемого результата и приоритета. 1 · теория
- 2 Есть структура, конкретные проверки и ожидаемый результат, но мало рисков и доказательств. 2 · Junior+
- 3 Ответ учитывает контекст, риск, компромиссы, наблюдаемость и объясняет выбор. 3 · Middle
Junior QA: база, которую проверяют через примеры
На junior-уровне ждут не энциклопедию, а устойчивую базу: тест-дизайн, понятный багрепорт, HTTP, клиент-сервер и способность увидеть негативный сценарий.
1 Что такое тестирование и может ли оно доказать отсутствие багов?
Разбор сильного ответа
Тестирование даёт информацию о качестве и снижает риск, но не доказывает отсутствие дефектов. Полный перебор невозможен почти всегда, поэтому проверки выбирают по требованиям, рискам, техникам тест-дизайна и истории продукта. Результат работы QA — не обещание «багов нет», а понятная картина проверенного и оставшегося риска.
Что оценивают: понимание цели тестирования, ограниченности покрытия и связи с риском.
Красный флаг: «QA гарантирует, что продукт полностью работает» или пересказ определения без практического смысла.
2 Как бы ты протестировала форму входа?
Разбор сильного ответа
Сначала уточню способы входа, правила email и пароля, блокировку, восстановление и роли. Затем проверю успешный вход, каждое поле отдельно, пустые и граничные значения, регистр и пробелы, неверную пару логин-пароль, защиту от перебора, сообщения об ошибках, создание и завершение сессии. После входа проверю прямой доступ к защищённой странице, logout, истечение сессии и вход под другим пользователем.
Что оценивают: уточняющие вопросы, группировка проверок и переход от UI к сессии и безопасности.
Красный флаг: бессвязный список из десятков полей без приоритета и без проверки того, что происходит после входа.
3 Чем severity отличается от priority? Приведи пример.
Разбор сильного ответа
Severity описывает влияние дефекта на систему или пользователя, priority — когда бизнесу выгодно его исправить. Потеря данных в редко используемом внутреннем отчёте может иметь высокую severity, но не самый высокий priority. Опечатка в названии компании на главной перед рекламной кампанией имеет низкую severity, но высокий priority. Конкретные шкалы и право выставлять поля зависят от процесса команды.
Что оценивают: разделение технического ущерба и бизнес-очерёдности, пример с несовпадающими значениями.
Красный флаг: «severity ставит QA, priority ставит менеджер» как универсальное правило без объяснения смысла.
4 POST /orders вернул 201. Можно считать тест успешным?
Разбор сильного ответа
Нет. 201 проверяет только часть контракта. Нужно проверить тело и заголовки ответа, схему и значения заказа, Location при наличии, запись в базе или последующий GET, изменение остатка и суммы, отсутствие лишних побочных эффектов. Затем повторить запрос и понять, должен ли он создать второй заказ или быть идемпотентным. Успешный статус с неверной суммой остаётся дефектом.
Что оценивают: умение видеть статус, контракт, данные и побочный эффект как разные слои проверки.
Красный флаг: «201 значит Created, всё хорошо» или проверка только цвета статуса в Postman.
5 В чём разница между аутентификацией и авторизацией?
Разбор сильного ответа
Аутентификация подтверждает, кто пользователь: пароль, токен, сессия. Авторизация решает, что этому пользователю разрешено. Для проверки нужны как минимум запрос без токена, с неверным или истёкшим токеном, с правильным токеном, с другой ролью и с id объекта другого пользователя. По HTTP-семантике отсутствие действительных учётных данных обычно ведёт к 401, а известный пользователь без права — к 403, хотя приватный объект иногда намеренно скрывают за 404.
Что оценивают: различие identity и permissions, проверки ролей и владения объектом.
Красный флаг: проверить только наличие кнопки в интерфейсе и не отправить запрещённый запрос напрямую.
6 Чем тест-кейс отличается от чек-листа и исследовательской сессии?
Разбор сильного ответа
Тест-кейс фиксирует предусловия, данные, шаги и ожидаемый результат: он полезен для критичного повторяемого сценария, передачи работы и аудита. Чек-лист короче и оставляет исполнителю выбор конкретных шагов, поэтому удобен для знакомой области и быстрой регрессии. Исследовательская сессия строится вокруг цели, риска и временного ограничения; тестирование, обучение и проектирование проверок идут одновременно, а результатом становятся заметки, находки и вопросы. Формат выбирают по риску, зрелости продукта и цене воспроизводимости, а не по привычке.
Что оценивают: понимание назначения артефактов и способность выбрать уровень детализации под задачу.
Красный флаг: называть исследовательское тестирование случайным нажатием кнопок или считать подробный тест-кейс обязательным для любой проверки.
7 Какие HTTP-методы считаются безопасными и идемпотентными?
Разбор сильного ответа
Безопасный метод предназначен только для чтения: GET, HEAD, OPTIONS и TRACE не должны менять состояние по намерению клиента. Идемпотентный метод при одинаковом повторе должен иметь тот же ожидаемый эффект на сервере, что и один вызов: к ним относятся safe-методы, а также PUT и DELETE. POST и PATCH не получают такую гарантию от стандарта. При этом повтор DELETE может вернуть другой статус, а логирование каждого GET допустимо: идемпотентность относится к запрошенному эффекту, а не к буквальному равенству всех ответов и внутренних событий.
Что оценивают: различие safe и idempotent, практический смысл retry и отсутствие механического правила «одинаковый ответ».
Красный флаг: утверждать, что любой POST всегда создаёт дубль, либо что DELETE обязан каждый раз возвращать один статус.
8 Как различать 400, 401, 403, 404, 409 и 422?
Разбор сильного ответа
400 подходит, когда сервер не может обработать запрос из-за общей клиентской ошибки или некорректного синтаксиса. 401 означает отсутствие действительных учётных данных и требует challenge в WWW-Authenticate. 403 — сервер понял запрос, но отказывается его выполнять. 404 — ресурс не найден либо намеренно скрыт. 409 — конфликт с текущим состоянием ресурса, например версия устарела или email уже занят. 422 — синтаксис и тип содержимого понятны, но инструкции семантически не проходят валидацию. Точный выбор закрепляет API-контракт; QA проверяет не любимый код, а последовательность контракта.
Что оценивают: семантику кода, связь с контрактом и примеры, где соседние коды действительно различаются.
Красный флаг: считать любой 4xx взаимозаменяемым или ожидать 401 для пользователя, который уже аутентифицирован, но не имеет права.
9 Как проверить сессию и logout, кроме клика по кнопке?
Разбор сильного ответа
Сначала определю, где хранится идентификатор сессии и как он передаётся. Проверю создание новой сессии после входа, атрибуты cookie Secure, HttpOnly и SameSite, отсутствие токена в URL, доступ к защищённому ресурсу до и после logout, повтор старого запроса, второе устройство, idle и absolute timeout. Logout должен не только перенаправить UI, но и сделать серверную сессию или refresh token непригодными по принятой модели. Очистка localStorage сама по себе не доказывает отзыв доступа.
Что оценивают: переход от интерфейса к жизненному циклу сессии, повтору запроса и нескольким клиентам.
Красный флаг: проверить только исчезновение имени пользователя из шапки или требовать одновременно хранить один токен и в cookie, и в localStorage.
10 Как найти дубликаты email в SQL и что проверить после результата?
Разбор сильного ответа
Базовый запрос: SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) FROM users GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1. Нормализация зависит от бизнес-правил: нельзя автоматически считать регистр или пробелы незначимыми, пока это не подтверждено. После списка групп нужен второй запрос за конкретными строками, чтобы сравнить статус, tenant, deleted_at и время создания. Затем проверю ограничение уникальности на записи и гонку двух параллельных регистраций: поиск уже существующих дублей не доказывает, что новые невозможны.
Что оценивают: GROUP BY и HAVING, осознанную нормализацию и переход от анализа данных к причине появления дубля.
Красный флаг: использовать DISTINCT, который скрывает повтор, но не показывает его количество, или удалить данные до выяснения бизнес-правила.
Middle QA: приоритеты, неопределённость и влияние на продукт
Middle отличается не числом терминов. От него ждут решений при неполных требованиях, ограниченном времени и конфликтующих рисках, а также ясной коммуникации этих решений команде.
11 API вернул 202 Accepted. Как тестировать результат асинхронной операции?
Разбор сильного ответа
202 означает, что запрос принят, но обработка ещё не завершена. Проверю идентификатор задачи или ссылку на status endpoint, переходы queued → processing → completed/failed, допустимое время, повторный polling и финальный бизнес-эффект. Нужны сценарии ошибки воркера, повторной доставки сообщения, двух одинаковых команд и недоступной зависимости. Отдельно проверю, что промежуточный ответ не обещает успех раньше времени, а финальная ошибка видна пользователю и доступна в логах по correlation id.
Что оценивают: различие принятия и завершения, eventual consistency, наблюдаемость и повторную доставку.
Красный флаг: закончить проверку на 202 или использовать фиксированный sleep вместо наблюдения за состоянием с timeout.
12 Backend меняет поле API. Как проверить обратную совместимость?
Разбор сильного ответа
Сначала определю потребителей и обещанный контракт: обязательность, тип, формат, nullable, enum и семантика поля. Прогоню старый клиент против нового backend и новый клиент против старой версии, если такой rollout возможен. Добавление необязательного поля обычно совместимо, а удаление, переименование, смена типа или новый обязательный enum ломают клиентов. Проверю сериализацию, неизвестные поля, значения по умолчанию, versioning и contract-тесты. План миграции должен включать период совместимости, метрику использования старого поля и явный срок удаления.
Что оценивают: мышление через потребителей, направление совместимости и стратегию постепенного rollout.
Красный флаг: считать любое добавление безопасным, не проверив строгий парсер, либо тестировать только текущий web-клиент.
13 Автотест нестабилен: иногда красный без изменения продукта. Что делать?
Разбор сильного ответа
Сохраню trace, screenshot, network и логи конкретного запуска, сравню успешный и упавший прогон. Затем классифицирую причину: ожидания и race condition, общие данные, зависимость от порядка, сеть, внешняя система, время или реальный плавающий дефект продукта. Повторный запуск помогает оценить частоту, но не является исправлением. Тест можно временно изолировать с владельцем и сроком, сохранив видимость проблемы. Лечить нужно условие: ждать наблюдаемое состояние, создавать независимые данные, стабилизировать контракт, а не добавлять безусловный sleep.
Что оценивают: диагностику по доказательствам, различие flaky test и flaky product, ответственность за quarantine.
Красный флаг: бесконечный retry до зелёного результата или немедленное удаление теста без анализа.
14 Как тестировать функцию под feature flag?
Разбор сильного ответа
Составлю матрицу: flag off/on, новая и существующая учётная запись, роли или сегменты, web и API, кэш и несколько инстансов. При off старое поведение должно сохраниться; при on проверяются новый путь и миграция данных. Важны переключение без деплоя, rollout по проценту, отсутствие утечки функции неподходящему сегменту, метрики и rollback. После полного запуска flag нужно удалить вместе с мёртвой веткой и тестами старого состояния, иначе количество комбинаций будет расти бесконечно.
Что оценивают: оба состояния, сегментацию, согласованность, наблюдаемость и жизненный цикл флага.
Красный флаг: проверить только on в одном браузере или забыть старые данные и откат.
15 Какие проверки QA делает после выкладки в production?
Разбор сильного ответа
До релиза согласую короткий production smoke без изменения или с безопасными тестовыми данными, дашборды, пороги и план отката. После выкладки проверю health и версию, ключевой пользовательский путь, ошибки 4xx/5xx, latency, очереди, бизнес-метрику и логи по correlation id. Сравню с базовой линией и разделю сигнал релиза от обычного шума. Для опасного действия использую synthetic account или read-only проверку. Результат — время, версия, выполненные проверки, наблюдения и решение продолжать rollout либо откатывать.
Что оценивают: production safety, метрики технического и бизнес-уровня, заранее определённые критерии остановки.
Красный флаг: ручной эксперимент на данных реального клиента или фраза «страница открылась, релиз успешен».
16 Релиз завтра, полная регрессия занимает два дня. Что будешь делать?
Разбор сильного ответа
Соберу изменения и зоны влияния, уточню критичные бизнес-пути и выберу проверки по вероятности и ущербу. Сначала smoke, изменённая функциональность, деньги, доступ, потеря данных, интеграции и области с частыми дефектами. Параллельно обозначу, что не покрыто, почему и какой остаточный риск принимает команда. Если риск неприемлем, предложу уменьшить scope релиза или перенести его, а не молча имитировать полное покрытие.
Что оценивают: risk-based подход, прозрачность покрытия и способность предложить варианты решения.
Красный флаг: «останусь и проверю всё» без оценки осуществимости либо произвольное сокращение чек-листа.
17 Баг воспроизводится примерно один раз из десяти. Как его расследовать?
Разбор сильного ответа
Зафиксирую окружение, аккаунт, данные, время и точную последовательность; проверю логи, Network и correlation id. Буду менять по одному фактору: браузер, сеть, повтор действия, объём данных, параллельность. Сравню успешный и неуспешный запросы и посчитаю частоту на серии повторов. Даже без стабильных шагов заведу наблюдение с доказательствами и вероятным условием, если влияние достаточно велико.
Что оценивают: дисциплина эксперимента, сбор доказательств и отсутствие выдуманной причинности.
Красный флаг: закрыть находку как «не воспроизводится» после двух попыток или указать предполагаемую причину как факт.
18 Требование звучит: «поиск должен быть быстрым и удобным». Как тестировать?
Разбор сильного ответа
Сначала превращу прилагательные в измеримые критерии: какой объём данных, допустимое время ответа, какие поля ищутся, нужен ли частичный поиск, регистр, раскладка, опечатки, сортировка и пустой результат. До уточнения могу исследовать текущее поведение и риски, но не объявлять субъективное ожидание дефектом. Итогом будет список вопросов владельцу продукта и черновой набор проверок с явно записанными допущениями.
Что оценивают: работа с тестируемостью требований и отделение вопроса от подтверждённого дефекта.
Красный флаг: самостоятельно решить, что «быстро» равно двум секундам, и оформить любое отклонение как баг.
19 Менеджер CRM видит карточку клиента другого менеджера. Как проверить и оформить?
Разбор сильного ответа
Создам два аккаунта одинаковой роли и объект владельца A. С токеном B запрошу тот же id через UI и напрямую через API, затем проверю чтение и изменение. Зафиксирую оба аккаунта, роли, id, запрос и ответ, исключив реальные персональные данные из вложений. Это потенциальный Broken Object Level Authorization: высокий риск утечки или изменения чужих данных, поэтому находку нужно быстро эскалировать по принятому security-процессу.
Что оценивают: горизонтальная авторизация, воспроизводимость и аккуратная работа с чувствительными данными.
Красный флаг: назвать проблемой только видимую кнопку или приложить в общий трекер неотредактированные персональные данные.
20 После двойного клика создаются два платежа. Что проверять кроме кнопки?
Разбор сильного ответа
Проверю несколько быстрых кликов, повтор одного HTTP-запроса, retry после timeout, одинаковый и новый idempotency key, параллельные запросы и повтор из другого устройства. На каждом шаге сравню ответ API, число операций и итоговый баланс. Блокировка кнопки полезна для UX, но защита должна быть на backend: клиентский запрос можно повторить без интерфейса.
Что оценивают: понимание идемпотентности, гонок и разделения UI-защиты от серверной гарантии.
Красный флаг: ограничиться disabled-состоянием кнопки и не проверить повтор запроса напрямую.
Практическая задача по API на 10 минут
Требование: менеджер может читать только своих клиентов. Не меняя данные на сервере, составь минимальный набор запросов, который проверит это правило. Потом открой пример разбора.
GET /api/clients/{id}\nAuthorization: Bearer {token}\n\nmanager_a owns client 481\nmanager_b owns client 927
Хороший ответ покрывает не один чужой id, а границы самой модели доступа:
- A запрашивает 481: ожидаем 200 и данные клиента A.
- B запрашивает 927: ожидаем 200 и данные клиента B.
- A запрашивает 927 и B запрашивает 481: ожидаем 403 или 404 по контракту.
- Запрос без токена и с битым токеном: ожидаем 401.
- Несуществующий id: проверяем согласованный 404 и отсутствие утечки различий между чужим и несуществующим объектом.
Показать, как оценивать ответ
Минимальный набор — два позитивных и два перекрёстных запроса. Сильный кандидат добавит отсутствие аутентификации, несуществующий id, попытку изменения через PATCH/DELETE и проверку лишних полей в ответе. Очень сильный сначала уточнит, должен ли чужой объект отвечать 403 или маскироваться под 404, и не станет придумывать контракт.
План подготовки на 7 дней
Частые вопросы о подготовке
Сколько длится техническое собеседование QA?
Часто от 45 до 90 минут, но формат зависит от компании: теория, обсуждение опыта, ситуационные задачи, API/SQL или отдельное тестовое. Уточнить структуру у рекрутера заранее нормально.
Нужно ли junior-тестировщику знать SQL и Postman в 2026 году?
Для многих manual QA вакансий достаточно уверенной базы: прочитать JSON, отправить запрос с параметрами и auth, проверить ответ, написать SELECT с WHERE и простой JOIN. Важно уметь применить это к задаче, а не только назвать команды.
Можно ли говорить «не знаю»?
Да. Сильнее честно обозначить границу знания и показать способ разобраться: уточнить контракт, посмотреть документацию, воспроизвести запрос, проверить лог. Выдуманный уверенный ответ опаснее пробела.
Как понять, что я готова к собеседованию?
Если ты можешь без конспекта объяснить решение, назвать ожидаемый результат и задать уточняющие вопросы к незнакомому кейсу, база готова. Не нужно отвечать идеально на все возможные вопросы.
Хорошая подготовка заканчивается не тогда, когда ты прочитала сто ответов, а когда можешь вслух разобрать незнакомую задачу: уточнить условия, выбрать риск, предложить проверку и назвать доказательство.