Техническое собеседование junior QA обычно проверяет не глубину, а базу: собеседующий хочет убедиться, что вы владеете фундаментальными понятиями и умеете чётко их объяснить — а не устраивает экзамен на то, чего курс не касался. Все 30 вопросов этого урока опираются на темы, реально пройденные в главах 1-16, без подвохов сверх программы. Это финальное повторение всего курса перед главой о самом трудоустройстве: тестовом задании, разборе отказов и выходе на работу.
Чему научишься за этот урок:
— уверенно отвечать на базовые технические вопросы по всем темам курса, без подглядывания в конспект;
— формулировать ответ в формате «короткий чёткий ответ + пример из практики»;
— честно называть границы своих знаний, если вопрос выходит за рамки курса, вместо того чтобы выдумывать.
Карта вопросов по темам курса
ТОП-30 ВОПРОСОВ ТЕХНИЧЕСКОГО СОБЕСЕДОВАНИЯ JUNIOR QA ===================================================== 1. Основы тестирования (Г1-2) - 5 вопросов 2. Техническая база (Г3) - 5 вопросов 3. Тест-дизайн и документация (Г4-6) - 6 вопросов 4. Веб / API / SQL (Г7-9) - 6 вопросов 5. Исследовательское и мобильное (Г10-11) - 4 вопроса 6. Процесс, безопасность, управление (Г12-13) - 4 вопроса ----------------------------------------------------- ИТОГО 30 вопросов
Ниже — сами вопросы по категориям с эталонными короткими ответами. Не запоминайте формулировки дословно: на собеседовании вопрос почти наверняка прозвучит другими словами — важно понимать суть, а не текст.
1. Основы тестирования (5 вопросов)
- «Чем дефект отличается от отказа?» — Дефект (баг) — ошибка в коде или требованиях; отказ — видимое пользователю проявление этого дефекта в работающей системе. Не каждый дефект успевает стать отказом.
- «В чём разница между верификацией и валидацией?» — Верификация отвечает на вопрос «делаем ли мы продукт правильно» (сверка с документацией и требованиями); валидация — «делаем ли мы правильный продукт» (соответствует ли он реальным нуждам пользователя).
- «Что такое эффект пестицида в тестировании?» — Одни и те же тест-кейсы со временем перестают находить новые баги: система как будто «привыкает» к ним, как вредители к одному и тому же пестициду. Поэтому чек-листы и тест-кейсы нужно регулярно пересматривать и дополнять.
- «Чем смоук-тестирование отличается от санити?» — Смоук — быстрая поверхностная проверка новой сборки в целом («не развалилось ли всё»); санити — узкая проверка одной конкретной области сразу после небольшого изменения в ней.
- «Что такое DoR и DoD в Scrum?» — DoR (Definition of Ready) — критерии готовности задачи к взятию в спринт (требования понятны, нет блокеров); DoD (Definition of Done) — критерии, что задача реально закончена, включая тестирование, а не просто написан код.
2. Техническая база (5 вопросов)
- «Что происходит между вводом адреса в браузере и появлением страницы на экране?» — Браузер через DNS узнаёт IP-адрес сервера по доменному имени, устанавливает соединение по порту (обычно 443 для HTTPS), отправляет HTTP-запрос, сервер отвечает кодом и телом (HTML/CSS/JS), браузер строит страницу.
- «Что такое идемпотентность HTTP-метода и какие методы ей обладают?» — Идемпотентный метод — повторный вызов с теми же параметрами не меняет результат ещё раз. GET, PUT и DELETE идемпотентны; POST — нет, повторный вызов обычно создаёт ещё одну сущность.
- «Чем отличаются коды ответа 404 и 500?» — 404 — «не найдено», клиент запросил несуществующий ресурс; 500 — внутренняя ошибка сервера, проблема на стороне бэкенда, а не в запросе клиента.
- «Чем аутентификация отличается от авторизации?» — Аутентификация подтверждает личность («кто ты» — логин и пароль); авторизация проверяет права доступа («что тебе разрешено») уже после того, как личность подтверждена.
- «Какие вкладки DevTools ты используешь чаще всего и зачем?» — Network — смотреть запросы, ответы и коды статусов; Console — ошибки JS; Elements — вёрстку и применённые стили; Application — cookies и локальное хранилище.
3. Тест-дизайн и документация (6 вопросов)
- «Что такое классы эквивалентности и граничные значения — и как их применяют вместе?» — Классы эквивалентности делят входные данные на группы с одинаковым поведением системы: из каждой группы достаточно проверить одного представителя. Граничные значения проверяют «стыки» этих групп (минимум, максимум, чуть за пределами) — там чаще всего прячутся баги.
- «Чем чек-лист отличается от тест-кейса?» — Чек-лист — короткий пункт-напоминание «что проверить» без жёстко прописанных шагов и ожидаемого результата; тест-кейс — формализованный документ с шагами, входными данными и точным ожидаемым результатом.
- «Что обязательно должно быть в баг-репорте?» — Заголовок, шаги воспроизведения, фактический и ожидаемый результат, окружение (браузер/ОС/версия), severity и priority, вложения (скриншот или лог).
- «Чем severity отличается от priority дефекта?» — Severity — насколько баг серьёзен технически, влияние на систему; priority — насколько срочно его чинить, влияние на бизнес и очередь работ. Они не обязаны совпадать.
- «Когда используют таблицу решений?» — Когда результат зависит от комбинации нескольких условий одновременно (например, скидка зависит и от суммы заказа, и от статуса клиента). Таблица решений перечисляет все комбинации условий и соответствующий им результат.
- «Что ты ищешь при ревью требований (статическом тестировании)?» — Маркеры неопределённости («и т.п.», «быстро», «удобно» без цифр), противоречия между пунктами, отсутствие граничных условий — найти дефект на этапе требований дешевле, чем после разработки.
4. Веб, API и SQL (6 вопросов)
- «Как ты будешь тестировать форму регистрации?» — Позитивные и негативные значения полей (классы эквивалентности плюс граничные значения), обязательность полей, форматы (email, телефон), сообщения валидации, поведение при повторной отправке.
- «Что проверяешь при кроссбраузерном тестировании?» — Отображение вёрстки и работу функционала в разных браузерах и разрешениях экрана — расхождения в CSS-рендеринге и в поддержке JS-функций.
- «По каким осям ты проверяешь ответ REST API?» — Статус-код, схема ответа (структура и типы полей), значения полей (соответствие ожидаемым данным), время ответа.
- «Как ты используешь Swagger/OpenAPI при тестировании API?» — Как справочник по эндпоинтам, методам, обязательным параметрам и ожидаемым схемам ответа: сверяю реальный ответ с описанной в Swagger схемой, ищу расхождения.
- «Что делает SQL-запрос с JOIN?» — Объединяет строки из двух и более таблиц по общему полю (например, users и orders по user_id), позволяя получить связанные данные одним запросом.
- «Какой риск несут прямые UPDATE и DELETE в базе при тестировании?» — Можно необратимо испортить или удалить данные в реальной БД. Такие операции выполняют только в песочнице (тестовой копии базы), никогда напрямую в проде.
5. Исследовательское и мобильное тестирование (4 вопроса)
- «Чем исследовательское тестирование отличается от тестирования по тест-кейсам?» — В исследовательском тестировании тестировщик одновременно проектирует, выполняет и учится по ходу дела, без заранее прописанных шагов — опираясь на мнемоники и чит-листы, а не на фиксированный документ.
- «Что такое сессионное тестирование?» — Тайм-боксированная сессия исследовательского тестирования по заранее сформулированной хартии (что именно исследуем), с последующим отчётом о найденном.
- «Какие мнемоники применяют в исследовательском тестировании?» — CRUD (Create/Read/Update/Delete — проверка операций над данными) и SFDIPOT (Structure/Function/Data/Interfaces/Platform/Operations/Time — чек-лист областей продукта).
- «Что обязательно проверяют в мобильном тестировании, помимо самого функционала?» — Поведение при прерываниях (звонок, уведомление), запросы разрешений, потерю сети, смену ориентации экрана, размер touch-таргетов и корректность отображения при разной плотности пикселей.
6. Процесс, безопасность и управление (4 вопроса)
- «Что входит в тест-план?» — Объект тестирования, стратегия и подходы, объём (что входит и не входит), ресурсы и роли, расписание, риски, критерии входа и выхода.
- «Чем критерии входа отличаются от критериев выхода?» — Критерии входа — условия, при которых тестирование МОЖНО начинать (например, сборка развёрнута и смоук пройден); критерии выхода — условия, при которых тестирование МОЖНО завершать (например, критические баги закрыты, план выполнен).
- «Что ты сделаешь, если во время ручного тестирования заметишь признак уязвимости из OWASP Top-10?» — Зафиксирую находку и сразу эскалирую в баг-репорте с пометкой о безопасности, но не буду пытаться дальше эксплуатировать уязвимость: это выходит за границы ответственности ручного QA без специальной подготовки.
- «Какие метрики нагрузочного тестирования ты знаешь?» — Latency (время отклика), throughput (количество запросов в единицу времени), error rate (доля ошибок под нагрузкой). Отчёты таких инструментов, как JMeter, я умею читать обзорно, но сами нагрузочные сценарии не настраивал — курс давал это только на уровне обзора.
Как отвечать: формат короткого ответа
Лучший формат ответа на техническом собеседовании — короткий чёткий тезис, а не растекание мыслью. Сначала одна-две фразы с сутью ответа, и только если собеседующий просит подробнее — пример из практики. Портфолио сквозного проекта (глава 16) — отличный источник таких примеров: не «я знаю, что такое баг-репорт», а «я оформлял баг-репорты именно так на сквозном проекте — вот пример из моего портфолио».
Если попался вопрос сверх программы курса (например, детали настройки Selenium или конкретных драйверов автоматизации) — честно скажите: «этого я на курсе не проходил практически, но вот как бы стал разбираться» — и коротко опишите подход. Это работает так же, как честное признание отказа в поиске работы: выдуманный уверенный ответ на незнакомую тему рушит доверие сильнее, чем спокойное «не проходил, но готов разобраться».
Как выполнить и самопроверить (миссия):
1. Пройдите вслух все вопросы одной из шести категорий подряд, без подглядывания в эталонные ответы.
2. Засеките время на каждый ответ — цель: короткий чёткий ответ за 20-40 секунд, без пауз «эээ» дольше нескольких секунд.
3. Для 2-3 вопросов добавьте пример из портфолио сквозного проекта (глава 16).
4. Самопроверка: вы ответили без подглядывания в конспект; ответы короткие и по существу, а не пересказ всего урока; если вопрос был не по силам — вы это честно отметили, а не придумали ответ.
Контрольный вопрос. Тестировщик сверяет вёрстку экрана оплаты с макетом в Figma: совпадают ли отступы, цвета кнопок и тексты. Это верификация или валидация?
Подсказка: Вспомни, с чем именно сверяет тестировщик результат — с документом или с реальными ожиданиями пользователя.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. На собеседовании спросили: почему PUT считается идемпотентным методом, а POST — нет?
Подсказка: Вспомни определение идемпотентности — что происходит при повторном вызове метода с теми же параметрами.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. На проде кнопка «Оплатить» вообще не реагирует ни у одного пользователя — ни один платёж не проходит. Какие severity и priority логично поставить такому багу?
Подсказка: Подумай отдельно о техническом влиянии на систему (severity) и отдельно о срочности для бизнеса (priority) — здесь оба фактора совпадают.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. На собеседовании попросили одной фразой объяснить разницу между чек-листом и тест-кейсом. Какой ответ точнее?
Подсказка: Ключевое отличие — степень детализации и формализации документа, а не то, кто именно его использует.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Во время ручного тестирования формы поиска ты заметил: если ввести в поле апостроф, страница возвращает ошибку с текстом SQL-запроса — похоже на признак SQL-инъекции. Что из перечисленного правильно сделать дальше (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Глава 12.1 прямо описывает протокол работы ручного QA с находками уровня OWASP Top-10 — сверься с ним, прежде чем выбирать варианты.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется мнемоника из 4 английских букв, которую используют в исследовательском тестировании для проверки операций над данными — создание, чтение, изменение, удаление? Ответь аббревиатурой.
Подсказка: Каждая буква аббревиатуры — отдельная операция над записью данных.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На собеседовании тебя попросили назвать одну из четырёх осей проверки ответа REST API, которая отвечает именно за СКОРОСТЬ ответа сервера, а не за структуру или содержимое. Ответь двумя словами.
Подсказка: Это не про статус-код и не про содержимое ответа, а про то, сколько сервер отвечал.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. SQL-запрос объединяет данные из таблиц users и orders по полю user_id, чтобы вывести имя клиента рядом с его заказами. Как называется такой SQL-оператор? Ответь одним словом (английский термин).
Подсказка: Это оператор, который «сшивает» строки двух таблиц по общему ключу.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На собеседовании спросили: «Чем тест-сценарий отличается от тест-кейса?» Сформулируй короткий ответ (2-3 предложения) в формате из этого урока: короткий чёткий ответ плюс пример из практики (сквозной проект главы 16).
Критерий приёмки: названо, что тест-сценарий — укрупнённое описание пути пользователя без пошаговой детализации (например, «оформление заказа от каталога до оплаты»), а тест-кейс — формализованный документ с конкретными шагами и ожидаемым результатом внутри этого пути; приведён пример из практики (конкретный раздел или путь, который тестировали в главе 16).
Подсказка: Вспомни, что тест-сценарий обычно шире одного тест-кейса — он описывает целый путь, который может включать несколько тест-кейсов.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. На собеседовании задали комбинированный вопрос: «У нас есть эндпоинт GET /api/orders/{id}, который возвращает заказ пользователя. Как бы ты протестировал этот эндпоинт вручную через Postman и как бы сверился с базой данных, чтобы убедиться, что API не расходится с БД?» Опиши план ответа: 3-4 конкретных проверки API (по осям из этого урока) и 1-2 SQL-запроса для сверки, без UPDATE/DELETE, только чтение.
Критерий приёмки: названы минимум 3 из 4 осей проверки API применительно к этому эндпоинту (например: статус-код 200 для существующего заказа и 404 для несуществующего; схема ответа содержит нужные поля; значения полей соответствуют реальному заказу; время ответа в пределах нормы); предложен хотя бы один SELECT-запрос с WHERE по id заказа для сверки данных из БД с данными в ответе API; явно сказано, что для сверки используются только read-запросы (SELECT), без изменения данных.
Подсказка: Раздели ответ на две части: сначала проверки самого API-ответа по осям из главы про API, потом отдельно — как сверить те же данные через SELECT в базе, не трогая данные на запись.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Технические вопросы разобраны — они закрывают повторение всего курса. Дальше в главе «Трудоустройство» разберём практическую сторону самого найма: как выполнять тестовое задание, как честно относиться к отказам и что происходит на выходе на первую работу, вместе с глоссарием всего курса.
