Сценарий

ИИ на собеседовании тестировщика: теория, тест-дизайн и «как протестируешь» — ответ под рукой

Собеседование QA — это теория тестирования, задачки на тест-дизайн и классическое «как протестируешь поле ввода». Vizir слушает вопрос и по ⌥↩ выдаёт каркас ответа: техники, классы эквивалентности, граничные значения. Подсказки на невидимом оверлее вне браузерного шеринга — а формулируешь ответ ты сам.

Как это выглядит

Пример по репликам

Собеседование на ручного тестировщика, классический вопрос про тест-дизайн — вот как это проходит по репликам.

ИнтервьюерКак ты протестируешь поле ввода возраста пользователя?
VizirРешение → «Классы эквивалентности и границы: валидные 0–120, границы 0, 1, 120, 121, отрицательные, ноль, дробные, буквы, спецсимволы, пустое поле, очень длинное число. Плюс негативные: SQL-инъекция, пробелы, копипаст. И UI: реакция на ошибку, обрезка ввода.»
ТыРазбиваю на классы эквивалентности и границы — 0, 1, 120, 121, отрицательные, дробные, буквы, пустое, спецсимволы. Отдельно негативные и проверку сообщения об ошибке.
ИнтервьюерКакие техники тест-дизайна ты здесь применил?
VizirОбъяснение → «Эквивалентное разбиение — делим ввод на валидные и невалидные классы. Анализ граничных значений — проверяем края диапазона. Предугадывание ошибок — негативные кейсы из опыта.»
ТыЭто эквивалентное разбиение плюс анализ граничных значений, а негативные кейсы — это уже предугадывание ошибок.

Что делает Vizir в этом сценарии

Теория по запросу

Спросят термин — объяснит своими словами

Smoke, регресс, разница между severity и priority, пирамида тестирования — Vizir слышит вопрос и по ⌥↩ даёт короткое понятное определение, а не абзац из учебника.

Тест-дизайн

«Как протестируешь…» — каркас кейсов

На задачу про тестирование приходит структура: классы эквивалентности, границы, позитив/негатив, UI и интеграции. Дальше добираешь кейсы сам.

API и автотесты

Вопросы про REST, статусы, селекторы

Спросят про коды ответов, идемпотентность или локаторы — приходит точный ответ с примером. По коду автотеста на экране жми ⌥C для разбора.

Вне шеринга

Вне браузерного шеринга

При шеринге вкладки или окна в Meet и веб-Zoom оверлея не видно; на Windows он скрыт и в нативных клиентах (гарантий на все версии захвата нет). Нативный Zoom или Teams на macOS 15+ — подсказки переезжают на телефон-компаньон.

Формат

Как устроено это собеседование

У ручного и автоматизирующего тестировщика общая теоретическая база, но вторая половина разговора разная: одному дают продукт и просят придумать проверки, другому — код и просят объяснить, почему тест нестабилен.

Этапы

Скрининг, техсекция, тестовое, финал

Рекрутер на 20-30 минут: опыт, инструменты, ручной или авто, деньги. Дальше техническая секция с лидом QA на час-полтора: теория, тест-дизайн вслух, разбор чужого баг-репорта, запрос к базе, чтение логов, запросы в Postman. Автоматизатору добавляют код — локаторы, ожидания, устройство фреймворка. Тестовое — найти и оформить баги на демо-стенде либо написать чек-лист на форму. Финал — с нанимающим менеджером про процессы и споры с разработкой.

На чём сыплются

Список кейсов вместо системы

Сыплют проверки в случайном порядке, не назвав ни одной техники, — и интервьюер не видит, полное ли покрытие. Путают severity и priority. В баг-репорте нет шагов, ожидаемого и фактического результата. Не спрашивают требования и тестируют собственные догадки. На автосекции не могут объяснить разницу между явным ожиданием и обычной паузой.

Что спрашивают и как звучит подсказка

Баг-репорт

«Приложение падает при загрузке аватара — оформи баг»

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

API

«Как протестируешь метод создания заказа?»

В подсказке ход ответа: сначала контракт — обязательные и необязательные поля, типы, коды ответов. Потом позитив, невалидные значения, авторизация и права, повторный вызов с тем же ключом. И проверка, что заказ реально появился в базе, а не только вернулся 200.

Процесс и риск

«Релиз через два часа, ты нашёл баг. Что делаешь?»

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

Автотесты

«Тест то падает, то проходит. Как разберёшься?»

Готовый разбор причин по частоте: гонка с загрузкой элемента и паузы вместо ожиданий, зависимость от порядка запуска, общие тестовые данные, внешний сервис без заглушки. Дальше — как ловить: перезапуск с логами и скриншотом, изоляция данных на тест.

Устройство фреймворка

«Что такое Page Object и зачем он нужен?»

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

ИнтервьюерРазработчик закрывает твой баг с комментарием «не баг, так и задумано». Что делаешь?
VizirОтвет → «Не спорить в тикете, а вернуться к источнику: что говорит требование или макет. Если требования нет — это не спор с разработчиком, а вопрос к аналитику или владельцу продукта, они и решают. Заодно опиши, что увидит пользователь — это чаще всего и снимает спор.»
ТыСмотрю требование или макет. Если там пусто — иду не спорить, а к аналитику: пусть решит владелец продукта. И в тикете дописываю, что видит пользователь.
ИнтервьюерВерно, решает не разработчик и не тестировщик.

Частые вопросы

Поможет и с теорией, и с практическими задачами?
Да. На теорию (виды тестирования, severity/priority, пирамида) приходит короткое определение, на практику («как протестируешь…») — каркас тест-кейсов по техникам.
А по автотестам и API спросят — потянет?
Да. Selenium/Playwright-локаторы, коды ответов REST, идемпотентность методов — приходит ответ с примером. Код автотеста с экрана разбирается по ⌥C.
Если задачу дают голосом, без экрана?
Транскрипт ловит вопрос на слух: по ⌥↩ Vizir соберёт ответ из услышанного. Скриншот нужен, только когда код или интерфейс видны на экране.

Иди на собеседование QA с каркасом ответа под рукой

3 дня и 30 минут речи бесплатно, карта не нужна. Поставь Vizir заранее и прогони через него пробный вопрос — до собеседования, а не на нём.

Другие сценарии