Что спрашивают на собеседовании ручного тестировщика в 2026 году?

Время на прочтение: 12–14 минут

Коротко о главном

На собеседовании ручного тестировщика в 2026 году вопросы идут шестью блоками: HR-скрининг (мотивация и soft skills), ситуативные вопросы (как вы действуете, когда всё горит), технические основы (HTTP, REST API, SQL, cookies, логи), теория тестирования (тест-кейс, smoke/regression, severity/priority), практические задачи («как протестировать корзину/форму/API») и задачи на мышление тестировщика (лифт, ручка, GET vs POST). Главный сдвиг 2026 года: интервьюеры ценят не заученные определения, а ход мыслей и умение рассуждать вслух. Junior-позиций стало кратно меньше, требования ужесточились — QA теперь работает с логами, сетью, SQL и участвует в обсуждении требований до написания кода. Ниже — разборы пяти типовых вопросов с подходом, который мы используем в Quality Academy, 5 ошибок, из-за которых чаще всего сыпятся собесы, и FAQ по подготовке.

Собеседование на Manual QA в 2026 — это не проверка выученных определений, а оценка того, как вы рассуждаете, структурируете мысль и ведете себя в ситуации неопределённости. На ответ «правильный по учебнику» смотрят реже, чем на то, как вы к нему пришли.

Готовитесь к собеседованию на Manual QA и уже чувствуете, как сердце колотится? Это нормально — через это проходят все. Разберёмся, что сегодня реально спрашивают, что за этим стоит и как готовиться так, чтобы не выучить ответы, а научиться думать.

Что изменилось в собесах QA 2026 vs 2024

За два года собеседования ручного тестировщика перестали быть викториной на определения. Если в 2024 году часть компаний ещё спрашивала «дай определение severity и priority» и этого хватало, то в 2026 такой ответ «по книжке» почти всегда заканчивается уточняющим «ок, а как ты это применяешь у себя на проекте?». И вот тут обычно всё и ломается.

Несколько ключевых сдвигов, которые нужно учитывать, если вы выходите на рынок в 2026 году.

Shift-left — уже не лозунг, а требование. QA теперь обязан участвовать в обсуждении требований до написания кода, анализировать User Story на нефункциональные риски и думать о тестируемости с этапа дизайна, а не «когда разрабы доделают и скинут сборку». На собесе это проверяют сценарием «фича пришла без нормального ТЗ — с чего начнешь?».

Требования к техбазе выросли. QA теперь обязан работать с логами, сетью, SQL, понимать архитектуру и участвовать в обеспечении качества, а не «тыкать кнопки по чеклистам». Запросы «посмотри в Kibana, что пришло в сервис» — теперь норма даже для Junior.

ИИ в тестировании — фоновая тема любого собеса. По прогнозу до 80% команд к концу 2026 года будут использовать ИИ в процессах тестирования. Спрашивают не «знаешь ли ты GPT», а «как ты используешь нейросети в рутине — и где им нельзя доверять».

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

Junior-позиций стало кратно меньше. Из 225 вакансий QA на Habr Career (2025) только 9 — для кандидатов без опыта. Поэтому большинство выпускников школ целятся сразу в Middle — и соответственно, и спрашивают их как Middle.

Почему 80% кандидатов сыпятся на собеседовании QA

80% успеха в трудоустройстве — это НЕ технические навыки, а soft skills. Умение связать два слова, адекватность, открытость, честность, умение себя презентовать. Человек может отлично знать теорию — но если он сложен как человек, постоянно что-то хитрит, крутит, вертит — его не возьмут, даже если он идеально ответит на все вопросы.

Конкуренция на hh.ru в IT выросла с 3,7 кандидата на вакансию (апрель 2024) до более 5,9 (май 2025). На отдельные позиции QA приходит до 2 206 откликов за месяц. Это значит: HR листает резюме по 7 секунд, а на собесе отбирает уже не лучшего из пяти, а лучшего из пятидесяти. Старая тактика «выучу 100 вопросов и пройду» на таком рынке не работает — потому что 100 вопросов выучили все.

Важная оговорка. Чтобы soft skills начали работать, резюме сначала должно пройти скрининг. Больше 50% резюме без коммерческого опыта даже не открывают на скрининге. Поэтому порядок такой: сначала — сильное резюме, чтобы попасть на собес. Потом — soft skills, которые решают уже на самом интервью.

Какие вопросы задают на собеседовании QA: 6 блоков

Мы разбили все вопросы на те же 6 блоков, что используем в нашем Telegram-боте по подготовке к собесам — структура взята из реальных записей 400+ собеседований. По каждому блоку — что спрашивают, что на самом деле проверяют, и для четырёх блоков — разбор одного типового вопроса «как думать».

1. HR-скрининг и общие вопросы

Типичные вопросы (Junior/Middle):

• Расскажите о себе.
• Почему вы решили стать тестировщиком?
• Почему ушли с прошлого места?
• Сильные и слабые стороны.
• Самое значимое достижение и ваш вклад.
• Как решали сложный конфликт в команде?
• Как работаете в условиях неопределенности?

Что на самом деле проверяют: не вашу мотивацию в чистом виде, а адекватность. HR слушает, нет ли в ответе обид на прошлую работу, нет ли завышенных ожиданий, нет ли «ухода в IT от безысходности».

2. Ситуативные вопросы по процессам проекта

Типичные вопросы (Junior/Middle):

• Требования неполные или противоречивые — что делаете?
• Разработчик не согласен с багом — ваши действия?
• Нашли баг перед релизом — что будете делать?
• Как приоритизируете тестирование, когда времени в обрез?
• За 5 минут до релиза нашли критичный баг в оплате — ваши шаги?

Senior/Lead дополнительно:

• Как выстраивать процесс тестирования в команде с нуля?
• Как снижать риски при жестких сроках?
• Как работать с частыми изменениями требований?

Что на самом деле проверяют: не «правильный ответ», а структуру мышления. Умеете ли вы коммуницировать с разработчиком без конфликта, различаете ли вы «я делаю как удобно» и «я делаю как полезно проекту».

Как отвечать на ситуативный вопрос: «Разработчик говорит, что это не баг, а фича»

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

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

Как мы этому учим в школе: «Спор о баге — это спор о спецификации. Найдите место, где записано ожидаемое поведение. Если его нет — вопрос не к разработчику, вопрос к бизнес-аналитику или владельцу продукта. Ваша задача — не выиграть спор, а зафиксировать для проекта: что считаем правильным поведением, и записать это так, чтобы завтра никто не обсуждал заново». На собесе именно такая формулировка отличает Junior, который «ещё не работал в команде», от Middle, который «уже работал».

3. Технические вопросы

Типичные вопросы (Junior/Middle):

• Что такое REST API?
• Что такое HTTP и какие есть методы?
• Что такое JSON?
• Что такое SQL, и напиши простой SELECT с WHERE/JOIN.
• Что такое cookies и session, в чём разница?
• Что такое Docker (базово)?
• Что такое CI/CD?
• Как посмотреть логи на проекте?

Senior/Lead дополнительно:

• Как работает API Gateway и балансировка нагрузки?
• Микросервисная архитектура — какие риски для тестирования?
• Kafka/RabbitMQ — как тестировать очереди?
• TCP vs UDP — где это критично?
• Observability: как проверять логи/метрики/трейсы в K8s?
• CI/CD pipeline — как устроен в сложных системах?

Что на самом деле проверяют: понимаете ли вы, с чем работаете. Не «помните ли определение», а «можете ли объяснить своими словами». Если вы заученно выдали «REST — это архитектурный стиль» и замолчали — плохо. Если добавили «грубо говоря, это когда клиент шлёт запрос серверу через HTTP, каждый запрос самодостаточный, методы GET читают, POST создают, PUT обновляют, DELETE удаляют» — хорошо, дальше пойдут углубляющие.

REST API — архитектурный стиль взаимодействия клиента и сервера через HTTP-методы (GET/POST/PUT/DELETE/PATCH), где каждый запрос самодостаточен, сервер не хранит состояние клиента между запросами, а ресурсы адресуются по URL.

HTTP — протокол уровня приложения, работающий по модели «запрос-ответ». До HTTP/2 включительно — поверх TCP, HTTP/3 — поверх UDP (через QUIC). Для тестировщика важны: методы (GET/POST/PUT/DELETE/PATCH), статус-коды (2xx — успех, 3xx — редирект, 4xx — ошибка клиента, 5xx — ошибка сервера), заголовки (Authorization, Content-Type, Cookie).

Cookies vs session: cookies — механизм хранения небольших данных на стороне клиента (в браузере), session — серверная концепция «состояния клиента». В классической схеме session-id хранится в cookie, и сервер держит состояние у себя (stateful). В stateless-подходе вместо session-id отдают JWT (подписанный токен), и сервер не хранит состояния — всё внутри токена. Для тестировщика важно: cookie — это транспорт, session / JWT — что в нём лежит.

4. Теория тестирования

Типичные вопросы (Junior/Middle):

• Что такое тест-кейс и чек-лист? В чём разница?
• Smoke, regression, sanity — что это и когда применять?
• Severity и priority — чем отличаются?
• Позитивное и негативное тестирование.
• Классы эквивалентности и граничные значения.
• Bug lifecycle — какие статусы бывают у бага.
• Что такое test plan?

Senior/Lead дополнительно:

• Как выстраивается тестовая стратегия в продукте?
• Что такое тестовая пирамида и как применять?
• Risk-based testing.
• Как определить достаточность тестового покрытия?
• Как уменьшать количество тестов без потери качества?
• Как внедрять shift-left / shift-right в процесс?

Что на самом деле проверяют: не знание определений из учебника, а понимание — зачем каждая техника существует и в какой ситуации её применять. Заученный ответ «класс эквивалентности — это диапазон значений, дающий одинаковое поведение» без примера на конкретной форме — это минус, а не плюс.

Как разбирать: «Чем severity отличается от priority»

Типичная ошибка новичка: путает местами, говорит «severity важнее» или «это одно и то же, просто разные названия».

Что хотят услышать: что вы видите эти метрики как два разных взгляда на один баг — со стороны техники и со стороны бизнеса.

Как отвечать: объясняйте через пример. Баг: на странице «О компании» опечатка в слове «юридические». Severity (техническая серьезность) — низкая, ничего не ломается. Priority (приоритет для бизнеса) — высокая, если компания завтра запускает рекламу и скриншот этой страницы пойдет в СМИ. Обратный случай: падает сервис поиска на 2 секунды под нагрузкой — severity major (функционал деградирует), priority low (пользователи ретраят, SLA держится). Вывод, который хотят услышать: «severity — про техническое влияние на систему, priority — про очерёдность фикса с точки зрения бизнеса. Решает обычно менеджер или владелец продукта, а не тестировщик единолично».

5. Практические задачи

Типичные вопросы (Junior/Middle):

• Как протестировать форму регистрации?
• Как протестировать авторизацию?
• Как протестировать корзину в интернет-магазине?
• Как протестировать API endpoint (например, POST /users)?
• Как протестировать загрузку файла?
• Как протестировать поиск?

Senior/Lead дополнительно:

• Как протестировать систему с микросервисной архитектурой?
• Как тестировать систему с высокой нагрузкой?
• Как тестировать платежную систему end-to-end?
• Как тестировать систему с очередями и асинхронностью?
• Как тестировать eventual consistency в распределенной системе?
• Как спроектировать стратегию тестирования нового продукта?

Что на самом деле проверяют: широту мышления и системность. Можете ли вы за 3–5 минут выдать не случайные кейсы, а структуру проверок: функциональность, граничные значения, негативные сценарии, безопасность, UX, производительность, совместимость.

Как разбирать: «Как протестировать форму авторизации»

Типичная ошибка новичка: выдаёт в лоб 3–5 кейсов — «ввести логин, ввести пароль, нажать войти» — и замолкает. Либо наоборот вываливает хаотичный поток кейсов без структуры.

Что хотят услышать: что вы сначала фиксируете структуру, а потом наполняете её кейсами. На Middle это принципиальная разница.

Как отвечать: держите такой порядок.

1. Уточняющие вопросы. «Форма какая — для веба, мобилки? Есть ли регистрация через соцсети? Есть ли 2FA? Есть ли восстановление пароля? Требования к паролю?» Это сразу +10 к оценке — показывает, что вы не «ныряете в кнопки», а думаете как проектировщик.
2. Функциональные проверки. Успешный вход. Неверный логин. Неверный пароль. Неверные оба. Пустые поля. Несуществующий пользователь.
3. Граничные значения. Минимальная/максимальная длина логина и пароля. Граничные на единицу: min−1, min, max, max+1.
4. Негативные сценарии. Спецсимволы, SQL-инъекции в поля (‘ OR 1=1), XSS (<script>), очень длинная строка (10 000 символов), Unicode, emoji.
5. Безопасность. Блокировка после N неудачных попыток (rate limiting + капча). Защита от brute-force и credential stuffing. Передача пароля только по HTTPS. Отсутствие пароля в логах, URL и DevTools Network. Тайм-аут сессии (idle + absolute). Ротация session-id после успешного логина (защита от session fixation). 2FA/MFA, если есть: SMS, TOTP, push, WebAuthn. Cookies с флагами HttpOnly, Secure, SameSite. CSRF-защита на POST /login.
6. UX. Сообщения об ошибках понятны, но не раскрывают существование пользователя? Плохо, когда на неверный логин и неверный пароль приходят разные ответы («пользователь не существует» vs «неверный пароль») — это user enumeration: злоумышленник по откликам системы узнаёт, какие логины валидны. Хорошо — единое обобщенное «Неверный логин или пароль». Работает ли Tab между полями? Enter отправляет форму?
7. Совместимость. Разные браузеры, мобильные устройства, разные разрешения.
8. Интеграция. Что происходит при падении сервиса авторизации? При медленной сети? При оффлайне после логина?

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

6. Задачи на мышление тестировщика

Блок, который часто называют «логическими задачами» — но на реальных собесах QA задач в духе Монти Холла или «волка-козы-капусты» практически не бывает. Это задачи на продуктовых/аналитических собесах в Google 2014 года. На QA спрашивают задачи на мышление тестировщика — когда нужно быстро декомпозировать незнакомую систему и прикинуть, как её проверить.

Классика, которую задают реально:

• Как протестировать лифт. (Функциональность: поехал/остановился/открыл двери. Граничные: первый/последний этаж, перегруз, одновременные вызовы. Безопасность: аварийная остановка, пожар, отключение электричества. UX: кнопки, подсветка, звук. Совместимость: разные пользователи — взрослые, дети, инвалидные коляски.)
• Как протестировать ручку (шариковую или дверную — уточнить, какую). Проверяет, задаете ли вы уточняющие вопросы прежде чем бросаться в ответ.
• Как протестировать отображение длинного текста в ограниченном поле. (Что с переносом? Обрезка? Есть ли «...»? Что при копировании из Word? При вводе emoji, спецсимволов, RTL-языков?)
• Что будет, если GET и POST поменять местами — популярный вопрос на понимание идемпотентности HTTP-методов. GET по спецификации (RFC 9110) — safe (не меняет состояние сервера) и идемпотентный (повторный вызов даёт тот же результат). POST — не safe и по умолчанию не идемпотентный: каждый новый POST /orders создаёт новый заказ. Если поменять их местами, ломается кэширование (GET-ответы кэшируются прокси и браузерами), логика «обновил страницу → создал дубль заказа» и семантика REST. На Middle плюсом ждут упоминание заголовка Idempotency-Key — через него POST можно сделать идемпотентным (классический приём в банках и платежах).
• Как бы ты проверил поиск в Яндекс / мессенджере — задача на широту мышления и декомпозицию на подсистемы.
• Чем тестирование отличается от проверки — вопрос на философию профессии. Проверка — убедиться, что работает. Тестирование — найти, где не работает. Хороший QA не «проверяет кнопки», а «ищет точки нарушенного равновесия».

Что на самом деле проверяют: способность на незнакомом предмете за 3–5 минут показать системный подход. Ответы должны быть не «правильными», а структурированными.

5 ошибок, из-за которых собеседование QA не случается или проваливается

Ошибка 1. Учат ответы, а не учатся думать. Это самая массовая проблема. Человек может дословно воспроизвести определение, но при уточняющем вопросе «а на вашем проекте как это было?» — пустота. Интервьюер это моментально считывает. Лечится одним: учитесь не отвечать по шпаргалке, а рассуждать вслух. Даже если вы не уверены — проговаривайте, как вы идете к ответу. На собесе это почти всегда зачтут.

Ошибка 2. Перфекционизм и «я ещё не готов». Ученики убеждают себя, что надо «ещё один курс», «еще один сертификат», «еще месяц подготовки» — и прячутся в бесконечную учебу вместо выхода на рынок. По факту в этот момент они уже подготовлены лучше 70% кандидатов с «5 годами опыта», которые нажимали две кнопки. На работу берут не тех, кто больше знает, а тех, кто умеет решать задачи. Работодателю нужны работники, а не студенты.

Ошибка 3. Невнятная самопрезентация. Человек 40 минут рассказывает о себе вместо 2–3 нужных. Или наоборот: «Меня зовут Иван, хочу быть тестировщиком, всё». Оба варианта — провал. Тренируйте 2-минутный рассказ: кто вы, какой у вас опыт (пусть с легендой), что делаете на прошлом проекте, почему ищете новое, что ищете. Запишите себя на видео, пересмотрите. Первые 5 раз будет стыдно — это нормально.

Ошибка 4. «Неизвестные известные» — зоны, которые кандидат не видит. Человек на собесе отвечает технически верно, но его тон, интонация, манера, формулировки считываются как «неприятный», «неуверенный», «надменный». Лечится только внешним взглядом: ментор, тренировочные собесы с записью, разбор вашего поведения со стороны.

Ошибка 5. Один канал и одно резюме. Многие откликаются только на hh.ru с одним резюме и удивляются, почему из 50 откликов 0 приглашений. По практике наших учеников: пара тысяч откликов, 5–7 вариантов резюме под разные типы вакансий, уникальные сопроводительные письма (не через нейросеть — ценится человечность), все площадки — hh, Habr Career, Хабр-чаты, Telegram-чаты, LinkedIn для зарубежных компаний. И это норма, а не «слишком много».

Как готовиться к собеседованию QA в 2026

Мы не верим в «чеклист из 7 пунктов» — верим в систему, которую мы отстроили в школе и которая показала результат: 100+ выпускников, средний срок от нуля до оффера 6 месяцев. Вот что реально работает, по опыту:

1. Насмотренность живых собеседований. Выучить теорию — мало. Надо увидеть, как реальные люди отвечают, где запинаются, как интервьюер развивает тему, как возвращает кандидата на основную ветку. У нас открыта часть базы — плейлист живых мок-собеседований Junior и Middle QA на нашем YouTube-канале (до 24 тысяч просмотров у отдельных выпусков). Есть отдельный плейлист провальных собесов — там особенно видно, как не надо.

2. Проговаривание вопросов вслух каждый день. Мы сделали Telegram-бот по подготовке к собесам —@quality_academy_interview_bot Там 5000+ реальных вопросов, разбитых по 6 блокам (как в этой статье) и по грейдам (Junior / Middle / Senior / Lead). Подключён ИИ-помощник, который сразу дает разбор вашего ответа. Бесплатно.

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

4. Подготовка к собесам — параллельно учёбе, а не после. Это принцип нашей школы: тиры (тренировки на вопросах) и практические разборы идут 3 раза в неделю с самого начала обучения, а не «когда доучитесь». Иначе теория забывается за 2 месяца до момента, когда вы сядете на первый собес.

5. Записывайте свои собесы и пересматривайте. Через неделю пересмотрите — найдёте 10 вещей, которые сами не услышали: длинные паузы, «э-э-э», перескоки с темы на тему, оборонительная интонация при уточняющих вопросах. Только так вы сможете корректироваться.

Если у вас уже есть база, но результата нет — и это продолжается месяц, два, три — значит, проблема не в технике. Проблема выше по уровням: самопрезентация, убеждения, резюме, стратегия откликов. Внешний взгляд в этой ситуации нужен — мы свои слепые пятна по определению не видим сами. У нас есть карьерный центр «Буст до оффера», заточенный именно под это: точечная работа с резюме, самопрезентацией, стратегией откликов, серия тестовых собеседований с разбором. Отбор: анкета + интервью с техническим специалистом — берём тех, у кого техническая база уже в порядке.

FAQ по собеседованию QA

Сколько вопросов могут задать на собеседовании Junior QA?

В среднем 20–40 вопросов за технический этап длиной 45–60 минут. Но считать вопросы бесполезно — один вопрос с 3 уточнениями может занять 10 минут и решить судьбу всего собеса. Важно не количество, а качество ваших ответов.

Нужно ли знать SQL джуну в 2026?

Да, это обязательный must-have. Минимум — SELECT, WHERE, JOIN (inner/left), GROUP BY, простые агрегаты (COUNT, SUM, MAX). Это есть в любом списке требований к Junior QA, и это спросят почти на каждом собесе. Не обязательно писать сложные запросы с CTE и window-функциями — но читать чужой запрос и править простой должны уметь.

Обязательно ли знать автоматизацию, чтобы пройти на Middle?

Нет. Вакансий на Middle Manual QA на рынке РФ сотни, и в них можно попасть без автотестов. При этом автоматизация — это +20–40% к зарплате, и многие Middle-вакансии идут с пометкой «автоматизация — преимущество». Если есть интерес — учите. Если нет — сначала добейтесь сильной ручной базы, резюме и soft skills: в 80% случаев проблема соискателя не в отсутствии автотестов.

Что важнее — теория или практика?

Практика. Теория — фундамент, без которого вы не сможете объяснить, что делаете. Но без практических задач она мёртвая. На собесе с вероятностью 80% попросят «как бы ты протестировал X» — и это практика, а не определения. Оптимальная пропорция в подготовке: 30% теория, 70% практика и разборы.

Можно ли пройти собеседование без опыта?

Сложно, но реально. Больше 50% резюме без коммерческого опыта не просматриваются на скрининге. Но на Middle-позиции с хорошо проработанной легендой, убедительным резюме и отработанной самопрезентацией — устроиться можно. Из наших учеников это делают регулярно. Главное: по знаниям и навыкам после обучения вы реально соответствуете Middle, разница только в количестве повторений в бою.

Какие soft skills важнее всего?

Адекватность, честность, умение связать два слова, открытость, стрессоустойчивость, умение задавать уточняющие вопросы вместо того, чтобы «нырять в ответ». Аналитическое мышление, исследовательский интерес. Коротко: с вами должно быть приятно и понятно работать.

Как готовиться, если собеседование через неделю?

Приоритеты такие. Первые 2 дня — прогнать 6 блоков из этой статьи и закрыть провалы в базовой теории (HTTP, REST, SQL, cookies, severity/priority, классы эквивалентности). Следующие 2 дня — 3–5 тренировочных собесов вслух: лучше с напарником или через наш бот с ИИ-разбором. Последние 2 дня — собрать 2-минутный рассказ о себе, прогнать 10 ситуативных вопросов, подготовить 3–5 хороших вопросов к интервьюеру. Последний день — выспаться, не зубрить, не паниковать.

Если статья помогла — поделитесь с теми, кто готовится к собесам. А если хотите подготовиться системно — приходите, посмотрим вместе, что подходит именно вам: https://quality-academy.ru/main

Контакты

Телеграм-бот для связи: https://t.me/quality_academy_bot

Телеграм-канал школы: https://t.me/quality_academy

Отзывы учеников: https://t.me/+C2yITW3SfQ05ZjJi

Сайт школы: https://quality-academy.ru/main

Помощь в трудоустройстве: https://quality-academy.ru/career