Спросят термин — объяснит своими словами
Smoke, регресс, разница между severity и priority, пирамида тестирования — Vizir слышит вопрос и по ⌥↩ даёт короткое понятное определение, а не абзац из учебника.
Собеседование QA — это теория тестирования, задачки на тест-дизайн и классическое «как протестируешь поле ввода». Vizir слушает вопрос и по ⌥↩ выдаёт каркас ответа: техники, классы эквивалентности, граничные значения. Подсказки на невидимом оверлее вне браузерного шеринга — а формулируешь ответ ты сам.
Собеседование на ручного тестировщика, классический вопрос про тест-дизайн — вот как это проходит по репликам.
Smoke, регресс, разница между severity и priority, пирамида тестирования — Vizir слышит вопрос и по ⌥↩ даёт короткое понятное определение, а не абзац из учебника.
На задачу про тестирование приходит структура: классы эквивалентности, границы, позитив/негатив, UI и интеграции. Дальше добираешь кейсы сам.
Спросят про коды ответов, идемпотентность или локаторы — приходит точный ответ с примером. По коду автотеста на экране жми ⌥C для разбора.
При шеринге вкладки или окна в Meet и веб-Zoom оверлея не видно; на Windows он скрыт и в нативных клиентах (гарантий на все версии захвата нет). Нативный Zoom или Teams на macOS 15+ — подсказки переезжают на телефон-компаньон.
У ручного и автоматизирующего тестировщика общая теоретическая база, но вторая половина разговора разная: одному дают продукт и просят придумать проверки, другому — код и просят объяснить, почему тест нестабилен.
Рекрутер на 20-30 минут: опыт, инструменты, ручной или авто, деньги. Дальше техническая секция с лидом QA на час-полтора: теория, тест-дизайн вслух, разбор чужого баг-репорта, запрос к базе, чтение логов, запросы в Postman. Автоматизатору добавляют код — локаторы, ожидания, устройство фреймворка. Тестовое — найти и оформить баги на демо-стенде либо написать чек-лист на форму. Финал — с нанимающим менеджером про процессы и споры с разработкой.
Сыплют проверки в случайном порядке, не назвав ни одной техники, — и интервьюер не видит, полное ли покрытие. Путают severity и priority. В баг-репорте нет шагов, ожидаемого и фактического результата. Не спрашивают требования и тестируют собственные догадки. На автосекции не могут объяснить разницу между явным ожиданием и обычной паузой.
Подсказка выдаёт скелет тикета: заголовок «что, где, когда», окружение и версия сборки, шаги воспроизведения по одному действию, ожидаемый и фактический результат, вложения — лог и запись экрана. Отдельно напомнит указать частоту воспроизведения.
В подсказке ход ответа: сначала контракт — обязательные и необязательные поля, типы, коды ответов. Потом позитив, невалидные значения, авторизация и права, повторный вызов с тем же ключом. И проверка, что заказ реально появился в базе, а не только вернулся 200.
Vizir подсказывает не «стоп релизу», а рамку решения: оценить severity и долю затронутых пользователей, проверить, есть ли обход, отнести решение владельцу релиза с фактами. Сильный ответ заканчивается тем, что решение о выпуске принимает не тестировщик.
Готовый разбор причин по частоте: гонка с загрузкой элемента и паузы вместо ожиданий, зависимость от порядка запуска, общие тестовые данные, внешний сервис без заглушки. Дальше — как ловить: перезапуск с логами и скриншотом, изоляция данных на тест.
Подсказка даёт короткое определение — страница как класс, локаторы и действия внутри, тест дёргает только методы — и главный аргумент: при переезде вёрстки правишь одно место, а не двадцать тестов. Плюс типичная ошибка: проверки внутри страницы.
3 дня и 30 минут речи бесплатно, карта не нужна. Поставь Vizir заранее и прогони через него пробный вопрос — до собеседования, а не на нём.