Как подготовиться к техническому интервью QA: пошаговое руководство

Технические собеседования в QA состоят из четырёх отдельных этапов, и кандидаты проваливают каждый по разной причине: технический скрин спотыкается на пробелах в концепциях тестирования, живое кодирование ловит через панику под наблюдением, а поведенческий раунд сливают расплывчатыми ответами про прошлый опыт. Этап с живым кодированием валит больше всего людей. Знать Playwright теоретически не значит уметь писать тест когда кто-то смотрит. В этом гайде: план подготовки на 2–4 недели с разбивкой по этапам, конкретные упражнения, самые частые темы на джуниор и мид уровне и что реально оценивают интервьюеры.

Что реально проверяют на техническом QA-собеседовании

Сначала разберись с форматом. Технические собеседования QA в 2026 году обычно состоят из:

| Этап | Что проверяют | Продолжительность |

|------|---------------|-------------------|

| Скрин с рекрутером | Бэкграунд, мотивация, основы | 20–30 мин |

| Технический скрин | QA-концепции, инструменты, опыт | 45–60 мин |

| Живое кодирование / автоматизация | Написание тестов Playwright, отладка | 45–60 мин |

| Системный дизайн (для сеньоров) | Тест-стратегия, архитектура | 45–60 мин |

| Поведенческий | Прошлый опыт, мягкие навыки | 30–45 мин |

Не каждая компания делает всё это: маленькие часто объединяют этапы. Но знание категорий помогает распределить время подготовки.

Шаг 1: определи уровень на который метишь (неделя 1)

Глубина технических вопросов масштабируется с уровнем. До начала подготовки честно определи где ты.

Фокус джуниор-собеседования

• Базовый Playwright: локаторы, проверки, базовая структура тестов
• Основы составления баг-репортов
• Понимание типов тестирования (smoke, regression, sanity)
• Основы Agile
• Ручное тестирование: что, зачем, когда

Фокус мид-собеседования

• Всё выше, глубже
• API-тестирование: статус-коды, запрос/ответ, request API Playwright
• Проектирование тестов: разбиение на классы эквивалентности, анализ граничных значений
• CI/CD: GitHub Actions, тестовые пайплайны
• Page Object Model

Фокус сеньор-собеседования

• Тест-стратегия и архитектурные решения
• Построение и поддержка фреймворков автоматизации
• Тестирование на основе рисков и приоритизация при ограничениях
• Влияние на команду и улучшение процессов
• Осведомлённость о нагрузочном и безопасностном тестировании

Шаг 2: найди свои пробелы (неделя 1)

Честная инвентаризация: пройди список и отмечай: уверен / шатко / не знаю.

Playwright

• [ ] Настройка нового Playwright-проекта
• [ ] Локаторы: getByRole, getByTestId, getByLabel, getByText
• [ ] Проверки: toBeVisible, toHaveText, toContainText, toHaveValue
• [ ] test.beforeEach и test.afterEach
• [ ] Фикстуры: использование встроенных, создание кастомных
• [ ] Паттерн Page Object Model
• [ ] API-тестирование с фикстурой request
• [ ] Перехват сети с route.fulfill
• [ ] Запуск тестов в headed/headless режиме
• [ ] Чтение и интерпретация HTML-отчёта

Концепции тестирования

• [ ] Разбиение на классы эквивалентности и анализ граничных значений
• [ ] Тестирование чёрного и белого ящика
• [ ] Smoke, regression, sanity тестирование: в чём разница
• [ ] Пирамида тестов и где каждый тип находится
• [ ] Тестирование на основе рисков и приоритизация
• [ ] Shift-left тестирование
• [ ] Definition of Done с точки зрения QA

API и веб

• [ ] HTTP-методы (GET, POST, PUT, PATCH, DELETE)
• [ ] Статус-коды (200, 201, 400, 401, 403, 404, 422, 500)
• [ ] Структура запроса: заголовки, тело, query-параметры
• [ ] Что такое JWT-токен
• [ ] Как работают куки браузера

Всё «шатко» или «не знаю»: твой учебный список.

Шаг 3: учи правильные вещи (недели 1–2)

Основы Playwright

Не читай о нём. Пиши код. Запускаешь практический проект:

npm init playwright@latest

Выбираешь публичный сайт для практики (lab.becomeqa.com, the-internet.herokuapp.com, automationpractice.pl) и пишешь тесты для:

• Формы логина (корректные и некорректные данные)
• Формы с несколькими полями и валидацией
• Таблицы: проверка данных, сортировка, фильтрация
• API-эндпоинта через request

5–10 Playwright-тестов с нуля на реальном сайте ставят тебя впереди большинства кандидатов.

Составление баг-репортов

Будь готов написать баг-репорт на ходу. Практикуй написание:

• Чёткого заголовка (не «логин не работает», а «Кнопка Login не реагирует когда email содержит заглавные буквы»)
• Шагов воспроизведения (пронумерованных, точных)
• Ожидаемого и фактического поведения
• Окружения (браузер, ОС, версия)
• Severity и Priority

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

Знай хотя бы один пример применения разбиения на классы эквивалентности и анализа граничных значений. Пример с полем возраста (0, 1, 17, 18, 120, 121): хороший чтобы выучить наизусть.

Словарный запас теории тестирования

Умей объяснить понятно (без заученных определений):

• Что такое регрессионное тестирование?
• Разница между severity и priority
• Чем тест-кейс отличается от тест-сценария?
• Что такое shift-left тестирование?
• Что значит «флакующий тест» и почему это происходит?

Шаг 4: практикуй этап живого кодирования (недели 2–3)

Здесь большинство кандидатов теряют очки. Знают Playwright теоретически, но замирают когда нужно написать тест в реальном времени.

Интервьюеры ценят мышление, а не только результат.

Частые сценарии живого кодирования

1. Написать Playwright-тест для формы логина

2. Написать тест который вызывает API и проверяет ответ

3. Отладить падающий тест (показывают код с багом)

4. Добавить тест для конкретного edge case который они описывают

Что делать когда застрял

Скажи что-то вроде «не уверен в точном синтаксисе, но подход был бы такой...» или «нужно проверить в доках Playwright эту конкретную проверку, но знаю что она есть...».

Признать неуверенность с достоинством гораздо лучше чем угадать неверно и защищать это.

Шаг 5: подготовь свои истории (неделя 3)

Поведенческие вопросы требуют конкретных примеров. До собеседования записываешь краткие заметки о:

1. Критическом баге который нашёл до релиза

2. Ситуации когда не согласился с разработчиком по поводу бага (и разрешил профессионально)

3. Тестировании в условиях давления времени: что приоритизировал

4. Улучшении процесса которое внедрил или предложил

5. Пропущенном баге который ушёл в прод (и чему научился)

Если нет 5 лет опыта, используй учебные проекты, личные проекты или даже джуниорские ситуации. Важна конкретность, а не старшинство.

Шаг 6: исследуй компанию (недели 3–4)

Общие ответы дают общие результаты. По каждой компании:

• Что делает их продукт? (Попробуй до собеседования)
• Какой стек упоминает описание вакансии?
• Фокус на вебе, мобайле, API или нагрузочном тестировании?
• Что их инженерный блог или LinkedIn говорят о процессе?

Адаптировать хотя бы один-два ответа под контекст компании показывает вовлечённость.

День собеседования

Технический скрин: советы по коммуникации

• Думай вслух. Молчание хуже неидеального мышления.
• Задавай уточняющие вопросы: «Предположить что пользователь уже залогинен?» «Тестируем это изолированно или сквозным тестом?»
• Если не знаешь, скажи об этом и объясни что сделал бы чтобы найти ответ.
• После ответа добавляй: «Есть что-то конкретное по этому вопросу на что вы хотите пойти глубже?»

Живое кодирование: советы по настройке

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

Вопросы которые стоит задать интервьюеру

Они сигнализируют о стратегическом мышлении, а не только о технических знаниях:

• «Как QA-команда сейчас обрабатывает регрессионное тестирование: автоматически, вручную или оба варианта?»
• «Какой сейчас главный вызов качества который стоит перед командой?»
• «Как QA-инженеры взаимодействуют с разработчиками? Тестирование встроено в definition of done?»
• «Как выглядит пирамида тестов для вашего продукта?»

Что реально оценивают интервьюеры

За техническими вопросами интервьюеры оценивают:

Таймлайн 4 недель вкратце

| Неделя | Фокус |

|--------|-------|

| 1 | Оцени пробелы, повтори основы Playwright, напиши 3–5 практических тестов |

| 2 | Глубокое изучение слабых мест, практика объяснения концепций вслух |

| 3 | Практика живого кодирования, подготовка поведенческих историй, исследование компаний |

| 4 | Мок-собеседования, ревью, точечное освежение шатких тем |

Кандидатов которые получают офферы обычно не те кто знает больше всех, а те кто хорошо коммуницирует, думает системно и искренне вовлечён в качество как ремесло. Подготовка ведёт туда.