Финал марафона · урок 18
90 вопросов на собеседование автоматизатора
Пройти собеседование с котом Борисом
Пять вопросов голосом или текстом, уточнения и разбор каждого ответа. Без входа.
Повторяются минимум в половине изученных источников.
Встречаются в отдельных интервью или зависят от проекта.
Узкие темы — готовь после основной базы или под вакансию.
1ЧастоСтратегия автоматизацииЧто стоит автоматизировать в первую очередь?
Как ответить на собеседовании
Сценарии с высоким бизнес-риском, частыми повторами и стабильными требованиями. Сначала оцени цену ошибки, частоту прогона и стоимость поддержки, затем выбери самый дешёвый подходящий уровень проверки.
Пример из практики
В PomidorQA я сначала закрыл регистрацию и бронирование: без них продукт теряет основной пользовательский путь. Редактирование второстепенных полей профиля добавлял уже после критичного сценария.
2ЧастоСтратегия автоматизацииЧто не стоит автоматизировать?
Как ответить на собеседовании
Одноразовые проверки, быстро меняющийся UI, сценарии без понятного ожидаемого результата и проверки, чья поддержка дороже ручного прогона. Отказ от автоматизации тоже должен быть инженерным решением.
Пример из практики
На PomidorQA я не стал автоматизировать каждую визуальную деталь календаря. Вёрстка менялась, а бизнес-правило про доступность слота надёжнее проверялось ниже и не требовало хрупких скриншотов.
3ЧастоСтратегия автоматизацииКак выбрать между unit, API и UI-тестом?
Как ответить на собеседовании
Проверяй поведение на самом низком уровне, где ещё виден нужный риск. Unit дешевле и быстрее, API хорошо проверяет бизнес-контракт, UI оставляют для критичных пользовательских путей и интеграции слоёв.
Пример из практики
В проекте правило отмены бронирования я бы проверял на API-уровне, а через UI оставил бы один критичный путь: пользователь нажал «Отменить» и увидел правильный итог на обеих сторонах.
4ЧастоСтратегия автоматизацииПочему UI-тестов должно быть меньше, чем API и unit?
Как ответить на собеседовании
Они медленнее, дороже в поддержке и зависят от большего числа компонентов. Пирамида не задаёт магическое соотношение, но напоминает: одну и ту же ошибку выгоднее ловить ниже, если это возможно.
Пример из практики
В PomidorQA через UI я оставил сквозные пути регистрации, профиля и бронирования. Проверки отдельных правил и подготовку данных уносил ниже, иначе regression быстро разросся бы и стал медленным.
5ЧастоСтратегия автоматизацииЧем smoke отличается от regression?
Как ответить на собеседовании
Smoke быстро отвечает, пригодна ли сборка для дальнейшей проверки, и покрывает несколько критичных путей. Regression шире проверяет, что изменения не сломали существующее поведение, поэтому обычно идёт дольше.
Пример из практики
Для PomidorQA в smoke я включил бы вход и одно успешное бронирование. Полный regression дополнительно проверял бы профиль, каталог, отмену, занятый слот и негативные сценарии.
6ЧастоСтратегия автоматизацииКак оценить пользу автоматизации?
Как ответить на собеседовании
Смотри на время обратной связи, стабильность, найденные регрессии, стоимость поддержки и покрытие рисков или требований. Простое количество тестов почти ничего не говорит об их ценности.
Пример из практики
В своём репозитории я показываю не только число тестов, а N покрытых требований из 50, время полного прогона X минут и результат CI. Эти цифры объясняют пользу набора лучше, чем фраза «написал много автотестов».
7ЧастоПроект и опытРасскажите о своём проекте автоматизации за три минуты.
Как ответить на собеседовании
Дай контекст продукта, риск, свою задачу, ключевое решение и измеримый результат. Для PomidorQA: стек, уровни тестов, матрица требований, CI, один найденный дефект и личный вклад без выдуманного коммерческого опыта.
Пример из практики
Я автоматизировал PomidorQA — сервис коротких встреч для QA. Лично работал над [своими сценариями], связал тесты с N из 50 требований и настроил проверку в CI; самый сложный случай был [ваш случай], его я разобрал по trace и логам.
8ЧастоПроект и опытКакой самый сложный технический вопрос вы решили в проекте?
Как ответить на собеседовании
Выбери один конкретный случай. Опиши симптом, собранные данные, отвергнутые гипотезы, исправление и проверку результата; фраза «починил флаки» без причины и цифр слабая.
Пример из практики
В моём проекте самым сложным был [реальный случай]. Сначала я увидел [симптом], затем проверил [артефакты], нашёл [причину] и подтвердил исправление несколькими повторными прогонами.
9ЧастоПроект и опытЧто в проекте вы сделали лично, а что взяли готовым?
Как ответить на собеседовании
Раздели стартовый код курса, свою реализацию и помощь ИИ. Сильный ответ показывает решения, которые ты проверял и менял сам, а не пытается присвоить весь репозиторий.
Пример из практики
Стартовые booking-flow и правила проекта я взял из курса. Самостоятельно я добавил [свои тесты], переработал [свой Page Object/helper] и исправил [конкретную проблему]; помощь ИИ отдельно отметил в README.
10ЧастоПроект и опытЧто бы вы переделали в своём фреймворке сейчас?
Как ответить на собеседовании
Назови одну реальную слабость, её последствия и следующий шаг. Например: убрать UI-регистрацию в API Arrange, разделить перегруженный Page Object или добавить измерение flaky rate.
Пример из практики
Сейчас я бы первым делом [ваше улучшение]. Например, в PomidorQA часть подготовки через UI можно перенести в API Arrange — тесты станут короче, а причина падения будет понятнее.
11ЧастоPlaywrightПочему команда выбрала Playwright, а не Selenium или Cypress?
Как ответить на собеседовании
Объясняй через требования проекта: нужные браузеры, изоляция через contexts, auto-waiting, trace, параллельный запуск и единый runner. Не говори, что один инструмент всегда лучше — важны ограничения команды и системы.
Пример из практики
Для PomidorQA был важен современный web UI, несколько независимых пользователей и разбор падений через trace. Поэтому Playwright с BrowserContext и встроенным runner подошёл лучше, но для команды с готовой Selenium-инфраструктурой выбор мог бы быть другим.
12ЧастоPlaywrightЧто такое Locator в Playwright?
Как ответить на собеседовании
Это ленивое описание способа найти элемент. Перед каждым действием Playwright заново разрешает locator в актуальный DOM, поэтому он устойчивее сохранённого ElementHandle при перерисовках.
Пример из практики
В ProfilePage я храню locator поля имени, а не найденный DOM-элемент. После сохранения React может перерисовать форму, и при следующем действии Playwright найдёт уже актуальный элемент.
13ЧастоPlaywrightКакой порядок приоритета локаторов вы используете?
Как ответить на собеседовании
Сначала пользовательские признаки: role с accessible name, label, text. Если нужен явный контракт — test id. Длинные CSS и XPath оставляю последним вариантом, потому что они часто привязаны к структуре DOM.
Пример из практики
Кнопку входа в PomidorQA я нахожу через getByRole с именем, поле email — через label, а data-testid оставляю для элементов без устойчивой семантики. XPath по цепочке div здесь только добавил бы хрупкость.
14ЧастоPlaywrightКогда getByTestId лучше getByRole?
Как ответить на собеседовании
Когда видимый текст нестабилен, элемент трудно однозначно описать через доступность или команда договорилась о тестовом контракте. Если семантика кнопки важна пользователю, getByRole одновременно проверяет более полезный сигнал.
Пример из практики
В календаре PomidorQA текст и структура могли меняться, поэтому для ключевого действия договорённый data-testid был надёжнее. А обычную кнопку «Войти» я всё равно искал через getByRole — там важна доступная семантика.
15ЧастоPlaywrightЧто такое auto-waiting?
Как ответить на собеседовании
Перед действием Playwright ждёт набор проверок actionability: элемент должен быть найден однозначно, видим, стабилен, получать события и, для части действий, быть enabled или editable. Это не ожидание любого бизнес-результата после клика.
Пример из практики
Перед кликом по слоту Playwright сам ждёт, что элемент станет видимым и доступным для действия. Но появление модалки бронирования я проверяю отдельным expect — auto-waiting не знает, какой бизнес-результат мне нужен.
16ЧастоPlaywrightЧем auto-waiting отличается от web-first assertion?
Как ответить на собеседовании
Auto-waiting готовит элемент к действию. Web-first assertion повторно проверяет ожидаемое состояние до таймаута, например появление текста после запроса; одно не заменяет другое.
Пример из практики
После нажатия «Сохранить» действие могло завершиться, а запрос ещё выполнялся. Поэтому я не добавлял паузу, а ждал сообщение об успешном обновлении профиля через web-first assertion.
17ЧастоPlaywrightПочему нельзя лечить падение waitForTimeout?
Как ответить на собеседовании
Фиксированная пауза не связана с реальным состоянием приложения: на быстрой машине она зря тормозит, на медленной всё равно может не хватить. Жди наблюдаемое состояние UI, ответа или события.
Пример из практики
Если модалка иногда появляется за 300 мс, а иногда за две секунды, waitForTimeout(3000) всегда тратит три секунды. В PomidorQA я жду саму модалку или итоговый текст — тест идёт ровно столько, сколько нужно.
18ЧастоPlaywrightЧем browser, context и page отличаются друг от друга?
Как ответить на собеседовании
Browser — процесс браузера, BrowserContext — изолированная сессия с собственными cookies и storage, Page — вкладка внутри контекста. Нескольких пользователей удобно моделировать отдельными contexts.
Пример из практики
Гостя и хоста в сценарии бронирования я открывал в разных BrowserContext. Так cookies не смешивались, а каждая Page оставалась вкладкой своей пользовательской сессии.
19ЧастоPlaywrightКак проверить негативный сценарий?
Как ответить на собеседовании
Воспроизвести валидные предусловия, выполнить запрещённое или ошибочное действие и подтвердить конкретный наблюдаемый результат: сообщение, статус, неизменность данных или отсутствие перехода. Падение шага само по себе не является проверкой.
Пример из практики
Для занятого слота я не считаю ошибкой само падение click. Я довожу второго гостя до подтверждения и проверяю конкретное сообщение, а затем убеждаюсь, что успешная бронь осталась только у первого.
20ЧастоPlaywrightВ чём разница между toBeVisible и isVisible?
Как ответить на собеседовании
toBeVisible — retrying assertion: ждёт ожидаемое состояние и даёт диагностичное падение. isVisible возвращает boolean текущего снимка состояния и полезен для ветвления, но легко создаёт гонку, если использовать его как проверку.
Пример из практики
В PomidorQA я использую toBeVisible для сообщения после сохранения — оно умеет подождать. isVisible оставляю только для осознанного ветвления, например если необязательный диалог действительно может появиться.
21ЧастоJavaScript и TypeScriptЧто такое Promise?
Как ответить на собеседовании
Объект, представляющий будущий результат асинхронной операции. Он проходит состояния pending, fulfilled или rejected; результат обрабатывают через await либо then/catch.
Пример из практики
В helper регистрации запрос возвращает Promise: пользователь появится не сразу. Я жду результат через await и только после этого передаю полученные данные в следующий шаг.
22ЧастоJavaScript и TypeScriptЧто делает async/await?
Как ответить на собеседовании
async заставляет функцию возвращать Promise, а await приостанавливает именно эту async-функцию до завершения Promise. Поток JavaScript целиком не блокируется.
Пример из практики
Мой registerUser объявлен async и возвращает Promise. await останавливает только эту функцию до завершения регистрации, поэтому runtime продолжает обслуживать другие задачи.
23ЧастоJavaScript и TypeScriptЧто произойдёт, если забыть await перед click или expect?
Как ответить на собеседовании
Тест продолжит выполнение, не дождавшись операции. Это создаёт гонку, необработанный Promise или ложнозелёный тест, особенно если runner завершит тест раньше assertion.
Пример из практики
В одном из первых тестов забытый await перед expect мог оставить проверку незавершённой. После исправления runner действительно ждал результат, и тест перестал быть ложнозелёным.
24ЧастоJavaScript и TypeScriptКогда использовать Promise.all?
Как ответить на собеседовании
Когда операции независимы и безопасны для параллельного ожидания. В Playwright типичный случай — одновременно начать ждать событие и запустить действие, которое это событие вызывает; последовательные пользовательские шаги в Promise.all класть нельзя.
Пример из практики
В PomidorQA я применял Promise.all, когда одновременно начинал ждать событие и нажимал кнопку, которая его вызывает. Шаги заполнения формы туда не складывал: они должны идти в пользовательском порядке.
25ЧастоJavaScript и TypeScriptЧем const отличается от let?
Как ответить на собеседовании
const запрещает переназначить саму переменную, let разрешает. Содержимое объекта или массива под const всё ещё можно менять, если объект отдельно не заморожен.
Пример из практики
Данные пользователя я объявляю через const: ссылку на объект переназначать не собираюсь. При этом поля объекта всё ещё можно изменить, поэтому const сам по себе не делает данные неизменяемыми.
26ЧастоJavaScript и TypeScriptЧем == отличается от ===?
Как ответить на собеседовании
== выполняет приведение типов, === сравнивает без него. В тестовом коде обычно используют ===, чтобы не скрывать несовпадение типов данных.
Пример из практики
Если API вернул строку "1", а я ожидал число 1, === сразу покажет расхождение контракта. С == такое различие могло бы тихо потеряться из-за приведения типов.
27ЧастоJavaScript и TypeScriptЗачем TypeScript в автотестах?
Как ответить на собеседовании
Он ловит часть ошибок до запуска: неверные поля данных, аргументы helpers, имена fixtures и результаты API. Типы упрощают рефакторинг, но не проверяют реальное поведение приложения во время выполнения.
Пример из практики
Интерфейс User в PomidorQA ловил опечатку в role или отсутствие email ещё до запуска теста. Но корректность самой регистрации я всё равно подтверждал реальным запросом и assertion.
28ЧастоJavaScript и TypeScriptЧем interface отличается от type?
Как ответить на собеседовании
Оба описывают формы данных. Interface удобно расширять и он поддерживает declaration merging; type умеет unions, intersections и алиасы примитивов. Для простой модели пользователя оба варианта допустимы — важна договорённость проекта.
Пример из практики
Для User я мог выбрать interface, а для role — union вроде "guest" | "host". Я не спорю, что один синтаксис всегда лучше: беру тот, который точнее выражает модель и принят в проекте.
29ЧастоАрхитектура тестовЗачем нужен Page Object Model?
Как ответить на собеседовании
Он прячет детали взаимодействия со страницей и уменьшает дублирование локаторов. POM полезен, пока методы описывают понятные действия; огромный класс со всей бизнес-логикой становится новой точкой сложности.
Пример из практики
В ProfilePage я собрал локаторы и действия профиля. Когда разметка поля изменилась, мне не пришлось исправлять пять spec-файлов — хватило одного места.
30ЧастоАрхитектура тестовЧто должно остаться в spec-файле, а что вынести?
Как ответить на собеседовании
В spec должен читаться сценарий и его проверка. Повторяемые технические шаги, локаторы, API-клиенты и фабрики данных выносят в pages/helpers/fixtures, но важные бизнес-assertions не прячут без причины.
Пример из практики
В spec PomidorQA у меня остаётся понятный сценарий: открыть профиль, изменить данные, проверить результат. Селекторы, генерацию пользователя и API-запросы я вынес в pages и helpers.
31ЧастоАрхитектура тестовЧто такое fixture в Playwright Test?
Как ответить на собеседовании
Управляемая зависимость теста с подготовкой и teardown. Fixture может дать page object, авторизованный context или тестовые данные и гарантированно убрать ресурсы после использования.
Пример из практики
Я бы оформил создание пользователя как fixture: она отдаёт тесту готовые данные, а после теста удаляет аккаунт. Тогда cleanup сработает и при падении assertion.
32ЧастоАрхитектура тестовКак организовать тестовые данные?
Как ответить на собеседовании
Генерировать уникальные данные на тест или worker, создавать их через надёжный слой и удалять в finally/teardown. Общие изменяемые аккаунты — частая причина зависимостей и флаков.
Пример из практики
Для каждого теста PomidorQA я генерировал уникальный email с runId. Это убрало столкновения параллельных запусков и зависимость от старого состояния общего аккаунта.
33ЧастоАрхитектура тестовПочему тесты должны быть независимыми?
Как ответить на собеседовании
Любой тест должен проходить отдельно и в другом порядке. Зависимость от результата соседа затрудняет локализацию падения, мешает параллельности и превращает один дефект в каскад красных тестов.
Пример из практики
Я проверял отдельный spec командой напрямую и менял порядок файлов. Если тест требует, чтобы сосед сначала создал запись, он не независим — такой setup нужно перенести внутрь теста или fixture.
34ЧастоСтабильность и CIЧто такое flaky test?
Как ответить на собеседовании
Тест, который на одной версии кода и данных может то пройти, то упасть. Причина бывает в тесте, продукте, данных или инфраструктуре — слово flaky не означает автоматически «плохой тест».
Пример из практики
У меня был бы flake, если один и тот же код на одном стенде то проходил, то падал. Я бы не называл его сразу ошибкой теста: сначала проверил бы продукт, данные и ресурсы runner.
35ЧастоСтабильность и CIКак расследовать тест, который падает только в CI?
Как ответить на собеседовании
Сначала сохранить trace, screenshot, video, логи и сетевые данные. Затем сравнить версии, env, secrets, timezone, ресурсы, данные и параллельность; менять timeout до диагностики — плохой первый шаг.
Пример из практики
Если PomidorQA падает только в Actions, я сначала открываю trace и артефакты этого run. Затем сравниваю Node, браузер, env, timezone, workers и тестовые данные с локальным запуском.
36ЧастоСтабильность и CIПочему retries не исправляют flaky test?
Как ответить на собеседовании
Retry снижает шум одного запуска и помогает собрать данные, но причина остаётся. Повторные прогоны могут скрыть регрессию, увеличить время CI и приучить команду игнорировать красный результат.
Пример из практики
Retry может сделать второй прогон зелёным, но первый красный никуда не исчез. В PomidorQA я использовал бы retry как временную страховку, а причину — например конфликт общего слота — исправлял отдельно.
37ЧастоСтабильность и CIКакие причины флаков встречаются чаще всего?
Как ответить на собеседовании
Ненаблюдаемые ожидания, хрупкие локаторы, общие данные, зависимость от порядка, гонки, нестабильные внешние сервисы и перегруженный CI. Сильный ответ даёт пример и способ подтвердить причину.
Пример из практики
На PomidorQA я бы начал с четырёх гипотез: пропущенный await, хрупкий locator, общий пользователь и перегруженный CI. Каждую проверял бы по trace и данным, а не правил всё подряд.
38ЧастоСтабильность и CIЧто должен делать pipeline с автотестами?
Как ответить на собеседовании
Воспроизводимо установить зависимости, проверить типы и lint, запустить нужные уровни тестов и сохранить отчёты даже при падении. Критичные проверки блокируют merge, advisory-инструменты не должны случайно становиться gate.
Пример из практики
В моём pipeline сначала идут typecheck и lint, потом тесты, а отчёт сохраняется даже при падении. Для Pull Request это даёт один понятный сигнал вместо ручного запуска на ноутбуке.
39ЧастоСтабильность и CIКакие артефакты нужны после падения Playwright-теста?
Как ответить на собеседовании
Как минимум понятный reporter и trace; по политике проекта — screenshot, video, логи и JUnit/JSON. Артефакты должны быть доступны из CI и содержать достаточно данных для разбора без локального повтора.
Пример из практики
При падении E2E я сохраняю trace и HTML-report, а screenshot или video включаю по политике проекта. Так коллега может разобрать run без моего компьютера и фразы «у меня локально работает».
40ЧастоСтабильность и CIКак ускорить медленный UI-набор?
Как ответить на собеседовании
Сначала измерить длительность и найти узкие места. Затем убрать лишний UI Arrange, перенести подходящие проверки ниже, безопасно распараллелить, сократить повторные логины и только потом добавлять runners или sharding.
Пример из практики
Если regression PomidorQA стал медленным, я сначала посмотрю длительность тестов. Потом уберу повторную UI-регистрацию в API Arrange и только после изоляции данных увеличу workers.