Финал марафона · урок 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.
41ИногдаPlaywrightКогда использовать beforeEach, beforeAll и fixture?
Как ответить на собеседовании
beforeEach — повторяемая подготовка каждого теста, beforeAll — дорогой неизменяемый setup для группы, fixture — переиспользуемая управляемая зависимость. Общие изменяемые данные в beforeAll делают тесты связанными.
Пример из практики
В profile-flow повторяемую подготовку страницы я помещал в beforeEach. Общий изменяемый аккаунт в beforeAll не использовал бы: один тест испортит состояние для всех остальных.
42ИногдаPlaywrightЧто проверяет strict mode у locator?
Как ответить на собеседовании
Действие над locator должно однозначно указывать на один элемент. Если совпадений несколько, Playwright падает и заставляет уточнить намерение вместо случайного клика по первому.
Пример из практики
Если getByRole('button') находит три кнопки, я не ставлю first наугад. В PomidorQA уточняю accessible name или сужаю поиск карточкой пользователя — strict mode ловит неоднозначность раньше случайного клика.
43ИногдаPlaywrightКогда first или nth допустимы, а когда опасны?
Как ответить на собеседовании
Допустимы, если позиция сама является частью контракта. Если nth просто маскирует неуникальный locator, перестановка элементов незаметно направит тест не туда.
Пример из практики
nth(0) уместен, если требование говорит «первый доступный слот». Если мне нужен слот конкретного времени, я ищу его по данным, иначе сортировка незаметно изменит смысл теста.
44ИногдаPlaywrightКак работать с iframe?
Как ответить на собеседовании
Использовать frameLocator или найти конкретный Frame и искать элементы внутри него. Обычный page locator не пересекает границу iframe автоматически.
Пример из практики
В базовом PomidorQA iframe не было. Если бы, например, оплата открывалась внутри iframe, я использовал бы frameLocator и отдельно проверил результат на странице продукта.
45ИногдаPlaywrightКак проверить новую вкладку или popup?
Как ответить на собеседовании
Начать ожидать событие page или popup до клика, затем выполнить действие и дождаться новой Page. Так тест не пропустит быстрое событие.
Пример из практики
Если карточка участника открывается в новой вкладке, я сначала начинаю ждать page, затем кликаю. Иначе быстрая вкладка может открыться раньше, чем тест подпишется на событие.
46ИногдаPlaywrightДля чего нужны Playwright projects?
Как ответить на собеседовании
Описывать матрицу запусков: браузеры, устройства, окружения и зависимости setup-проектов. Один тест можно прогнать с разной конфигурацией без копирования spec-файлов.
Пример из практики
Для PomidorQA projects могли бы описывать Chromium, Firefox и WebKit или разные baseURL. Один и тот же spec остался бы один, менялась бы только конфигурация запуска.
47ИногдаPlaywrightКак тестировать загрузку файла?
Как ответить на собеседовании
Передать файл через setInputFiles либо обработать filechooser, если input создаётся динамически. После действия проверить бизнес-результат, а не только исчезновение диалога.
Пример из практики
Загрузку аватара я проверял бы через setInputFiles, а потом ждал бы изображение или ответ продукта. Сам факт выбора файла ещё не доказывает, что загрузка завершилась.
48ИногдаPlaywrightКак тестировать скачивание файла?
Как ответить на собеседовании
Начать ждать событие download до клика, получить Download, проверить имя и при необходимости сохранить файл во временный путь. В CI нельзя рассчитывать на пользовательскую папку Downloads.
Пример из практики
Для выгрузки отчёта я начал бы ждать download до клика, затем проверил имя файла и содержимое во временной директории. На папку Downloads пользователя в CI рассчитывать нельзя.
49ИногдаPlaywrightКогда использовать soft assertions?
Как ответить на собеседовании
Когда полезно собрать несколько независимых расхождений за один прогон, например проверить поля карточки. Для критичного условия продолжать тест опасно — там нужна обычная assertion.
Пример из практики
Soft assertions пригодились бы для независимых полей профиля: имя, timezone и Telegram. Но если пользователь вообще не открылся, я остановлю тест обычной assertion — дальше проверять нечего.
50ИногдаPlaywrightЗачем использовать test.step?
Как ответить на собеседовании
Чтобы отчёт показывал крупные бизнес-шаги и быстрее локализовал падение. Оборачивать каждую строку ради красоты отчёта — лишний шум.
Пример из практики
В отчёте PomidorQA я группировал бы крупные шаги: создание пользователя, бронирование, проверка у гостя. Заворачивать каждый fill в test.step не стал бы — отчёт превратится в шум.
51ИногдаPlaywrightКак подменить ответ API в браузерном тесте?
Как ответить на собеседовании
Перехватить запрос через page.route или context.route и выполнить fulfill, continue либо abort. Подмена должна служить цели теста: она не доказывает, что реальный backend работает.
Пример из практики
Чтобы проверить UI при ошибке каталога, я мог бы подменить ответ через route и показать empty/error state. Но отдельным тестом всё равно проверил бы живой backend: mock его работоспособность не доказывает.
52ИногдаPlaywrightКак проверить запрос, отправленный страницей?
Как ответить на собеседовании
Начать ждать request/response до действия, затем проверить URL, метод, payload или status. Это полезно для диагностики, но не заменяет видимую пользователю assertion, если цель сценария — UI.
Пример из практики
После сохранения профиля я могу дождаться response и проверить status для диагностики, а затем проверить видимый текст. Пользовательский сценарий должен подтверждать результат в UI, не только сетевой вызов.
53ИногдаAPI и тестовые данныеЗачем создавать данные через API для UI-теста?
Как ответить на собеседовании
Это быстрее и стабильнее, если регистрация не является предметом проверки. UI остаётся для Act и Assert, а setup не расходует время на повторение уже проверенного пути.
Пример из практики
В тесте редактирования профиля я создаю пользователя через API, потому что регистрация не является целью этого сценария. Так Act начинается сразу с нужного экрана, а тест проходит быстрее.
54ИногдаAPI и тестовые данныеЧто проверять в API-тесте кроме status code?
Как ответить на собеседовании
Тело и схему, бизнес-правила, headers, побочные эффекты и состояние данных. Ответ 200 с неверным payload всё равно является дефектом.
Пример из практики
В API-тесте создания пользователя я проверяю не только 201, но и id, role, обязательные поля и то, что пользователь действительно доступен следующим запросом.
55ИногдаAPI и тестовые данныеЧто такое storageState?
Как ответить на собеседовании
Снимок cookies, localStorage и при поддержке конфигурации IndexedDB, который можно загрузить в context. Он ускоряет авторизацию, но требует безопасного хранения и стратегии обновления состояния.
Пример из практики
В базовой версии проекта storageState не использовался. Если бы я добавлял его, сохранял бы состояние тестового аккаунта вне репозитория и отдельно решал, когда его обновлять.
56ИногдаAPI и тестовые данныеКогда нельзя делить один storageState между тестами?
Как ответить на собеседовании
Когда тесты изменяют серверное состояние одного аккаунта и могут конфликтовать при параллельности. Тогда нужны отдельные аккаунты на worker или сценарий.
Пример из практики
Один storageState для гостя нельзя бездумно раздать параллельным тестам бронирования: они начнут менять одни и те же слоты. Я бы выдавал отдельный аккаунт на worker.
57ИногдаAPI и тестовые данныеКак гарантировать cleanup, если тест упал?
Как ответить на собеседовании
Использовать fixture teardown или finally вокруг сценария. Cleanup должен быть идемпотентным и по возможности выполняться через API, иначе одно падение загрязнит следующие запуски.
Пример из практики
Удаление тестового пользователя я вызываю в finally или teardown. Даже если expect упал, следующий run не получит занятый email и мусор от предыдущего теста.
58ИногдаAPI и тестовые данныеЧто такое идемпотентность и зачем она тестировщику?
Как ответить на собеседовании
Повтор одной операции даёт тот же итоговый эффект. Идемпотентные setup/cleanup проще безопасно повторять после сетевой ошибки или retry.
Пример из практики
Мой cleanup пользователя можно вызвать повторно: если запись уже удалена, он спокойно завершится. Это полезно, когда первый запрос прошёл, а клиент потерял ответ по сети.
59ИногдаAPI и тестовые данныеКак тестировать гонку двух пользователей за один ресурс?
Как ответить на собеседовании
Создать две независимые сессии, подвести их к одному состоянию до подтверждения и контролируемо запустить конкурирующие действия. Проверить один успех, один ожидаемый отказ и итоговое состояние ресурса.
Пример из практики
Для гонки за слот я создаю гостя и хоста в независимых context, подвожу обоих к одному слоту и только потом управляю порядком подтверждений. В конце проверяю и сообщение, и итоговое состояние брони.
60ИногдаAPI и тестовые данныеЧто делать с секретами в автотестах и CI?
Как ответить на собеседовании
Хранить в secret store CI или переменных окружения, не писать в репозиторий и не печатать в логах. Давать тестовому аккаунту минимальные права и уметь ротировать ключи.
Пример из практики
Секреты тестового API я передаю через GitHub Actions Secrets и env. В README оставляю только имя переменной, а токен не печатаю в trace или логах.
61ИногдаЗапуск и масштабированиеКак Playwright запускает тесты параллельно?
Как ответить на собеседовании
Runner распределяет файлы между worker-процессами; тесты внутри одного файла по умолчанию идут последовательно. Полностью параллельный режим требует настоящей изоляции данных и состояния.
Пример из практики
В PomidorQA разные spec-файлы могут идти на разных workers, если данные изолированы. Внутри одного файла я сохраняю последовательность, пока явно не доказал, что тесты безопасно независимы.
62ИногдаЗапуск и масштабированиеПочему увеличение workers может сделать набор медленнее?
Как ответить на собеседовании
Workers начинают конкурировать за CPU, память, сеть, базу и общий стенд. Параллельность ускоряет только до точки насыщения и может проявить скрытые конфликты данных.
Пример из практики
Если поднять workers с двух до восьми на слабом runner, база и CPU могут стать узким местом. Я сравню длительность и ошибки на нескольких значениях, а не поставлю максимум наугад.
63ИногдаЗапуск и масштабированиеЧем sharding отличается от workers?
Как ответить на собеседовании
Workers распараллеливают тесты внутри одного runner, sharding делит набор между несколькими машинами или jobs. Sharding требует объединения отчётов и одинакового окружения на каждом шарде.
Пример из практики
Workers ускоряют один job, а sharding делит весь набор между jobs. Для большого PomidorQA-набора я бы использовал sharding только после того, как отчёты умеют объединяться.
64ИногдаЗапуск и масштабированиеЗачем запускать браузерные тесты в Docker?
Как ответить на собеседовании
Чтобы зафиксировать системные зависимости и приблизить локальное окружение к CI. Нужно следить за версией образа, ресурсами, правами, shared memory и сетевым доступом к приложению.
Пример из практики
В учебном проекте Docker не был обязательным, поэтому я не выдаю его за свой опыт. Если бы окружения расходились, зафиксировал бы версию Node и браузеров образом и проверил ресурсы контейнера в CI.
65ИногдаЗапуск и масштабированиеКакие тесты должны блокировать Pull Request?
Как ответить на собеседовании
Быстрые и доверенные проверки критичных рисков. Нестабильный или многочасовой regression сначала нужно стабилизировать или вынести в отдельный расписанный прогон, иначе gate потеряет доверие.
Пример из практики
Merge я блокировал бы быстрыми typecheck, lint и доверенным smoke. Длинный или нестабильный regression вынес бы отдельно, пока команда не вернёт ему надёжность.
66ИногдаЗапуск и масштабированиеКак измерять flaky rate?
Как ответить на собеседовании
Фиксировать тесты, прошедшие только после retry, и делить число таких исходов на общее число запусков за период. Метрика нужна в динамике и вместе с причинами, а не для наказания команды.
Пример из практики
Я бы считал тесты, прошедшие только после retry, и делил их на все запуски за неделю. Для PomidorQA показал бы не разовую цифру, а тренд после исправления конкретной причины.
67ИногдаЗапуск и масштабированиеКакой reporter выбрать?
Как ответить на собеседовании
Локально удобен list или HTML, в CI — HTML как артефакт и JUnit/JSON для интеграций и аналитики. Выбор зависит от того, кто читает результат и нужна ли история запусков.
Пример из практики
Локально мне удобен list или HTML-report, в Actions — HTML как артефакт и JUnit/JSON для машинной обработки. Reporter выбираю под читателя, а не потому что он модно выглядит.
68ИногдаЗапуск и масштабированиеКак отличить дефект продукта от дефекта автотеста?
Как ответить на собеседовании
Проверить trace, запросы, логи и воспроизвести наблюдаемое поведение независимо от спорного шага теста. Не переписывать assertion только потому, что сборка красная.
Пример из практики
Если бронирование упало, я сначала проверю через UI или API итоговое состояние слота. Если продукт действительно отдал неверный результат — это дефект; если сломался только locator, чиню тест.
69ИногдаLive-codingКак посчитать количество каждого символа в строке?
Как ответить на собеседовании
Пройти строку циклом и накапливать счётчик в Map или объекте: count.set(char, (count.get(char) ?? 0) + 1). Сначала уточни регистр, пробелы и Unicode.
Пример из практики
На live-coding я сначала уточню, считать ли пробелы и регистр, затем пройду строку циклом и накоплю Map. После этого проверю пустую строку и повторяющиеся символы.
70ИногдаLive-codingКак удалить дубликаты из массива?
Как ответить на собеседовании
Для примитивов — [...new Set(items)]. Для объектов нужен ключ или правило равенства, например Map по id; JSON.stringify как универсальное сравнение ненадёжен.
Пример из практики
Для массива примитивов я использую Set. Если это пользователи PomidorQA, сначала уточню критерий дубликата и соберу Map по id или email — два разных объекта могут представлять одного человека.
71ИногдаLive-codingЧем map, filter и reduce отличаются?
Как ответить на собеседовании
map преобразует каждый элемент, filter оставляет подходящие, reduce сворачивает коллекцию в одно значение. На интервью лучше выбрать самый читаемый метод, а не демонстрировать reduce везде.
Пример из практики
Список имён я преобразую через map, активных пользователей оставляю через filter, а общее число слотов считаю reduce. Если обычный цикл читается яснее, не стану насильно показывать reduce.
72ИногдаLive-codingЧто такое shallow copy объекта?
Как ответить на собеседовании
Копируется верхний уровень, а вложенные объекты остаются общими ссылками. Spread не является deep clone; для поддерживаемых типов можно использовать structuredClone.
Пример из практики
При копировании пользователя через spread вложенный объект настроек останется общей ссылкой. Если тест меняет timezone внутри settings, я сделаю явную глубокую копию поддерживаемых данных.
73ИногдаLive-codingЧто выведет код с Promise.then и setTimeout?
Как ответить на собеседовании
Сначала синхронный код, затем microtasks Promise, потом macrotask таймера. Не зубри порядок без объяснения: покажи стек, очередь microtasks и следующий цикл Event Loop.
Пример из практики
Я проговорю порядок: синхронные строки, затем Promise.then из microtask queue, потом setTimeout. На доске покажу очереди, а не просто назову готовый вывод.
74ИногдаJavaScript и TypeScriptЧто такое union type и type narrowing?
Как ответить на собеседовании
Union разрешает несколько вариантов типа, например string | null. Narrowing через typeof, in, discriminant или проверку на null доказывает компилятору, какой вариант доступен в ветке.
Пример из практики
Role пользователя я описывал бы как union guest | host, а перед использованием nullable id проверял бы его. После такой проверки TypeScript сужает тип и не требует опасного !.
75ИногдаJavaScript и TypeScriptПочему any опасен в тестовом проекте?
Как ответить на собеседовании
Он отключает проверку типов и позволяет ошибке пройти до runtime. Для неизвестных внешних данных лучше unknown с явной валидацией или конкретный тип после проверки схемы.
Пример из практики
Ответ внешнего API я сначала принимаю как unknown и валидирую. Если поставить any, опечатка вроде user.nmae спокойно дойдёт до runtime и сломает тест далеко от причины.
76РедкоПродвинутый PlaywrightЧто такое HAR и когда его replay полезен?
Как ответить на собеседовании
HAR сохраняет сетевой трафик, который Playwright может использовать для воспроизведения ответов. Это ускоряет детерминированные тесты, но запись устаревает и не проверяет живой backend.
Пример из практики
В PomidorQA HAR replay я не применял, поэтому так и скажу. Использовал бы его для стабильного воспроизведения внешнего каталога, но оставил бы отдельную проверку живой интеграции и следил за устареванием записи.
77РедкоПродвинутый PlaywrightКак тестировать время и таймеры без реального ожидания?
Как ответить на собеседовании
Использовать Clock API для управления Date, setTimeout и ходом времени. Это делает сценарий быстрее и детерминированнее, если приложение не зависит от внешнего серверного времени.
Пример из практики
Clock API в учебном проекте я не использовал. Для правила «отменить не позже чем за два часа» он позволил бы двигать время без реального ожидания, если серверное время тоже контролируется.
78РедкоПродвинутый PlaywrightЧем visual comparison отличается от обычной assertion?
Как ответить на собеседовании
Сравнивает скриншот с эталоном и ловит непредвиденные визуальные изменения. Нужны стабильные шрифты, ОС, данные, анимации и обоснованный порог различий.
Пример из практики
Visual regression в PomidorQA не входил в базовый курс. Если бы добавлял, зафиксировал бы ОС, браузер, шрифты, данные и анимации, иначе получил бы шум вместо полезного сигнала.
79РедкоПродвинутый PlaywrightЧто реально проверяет accessibility scan?
Как ответить на собеседовании
Автоматический скан находит часть нарушений правил, но не доказывает полную доступность продукта. Нужны клавиатурная навигация, screen reader и ручная оценка смысла интерфейса.
Пример из практики
Автоматический accessibility scan я в проект не добавлял. На реальной задаче совместил бы его с клавиатурной проверкой и ручным проходом screen reader — один scan не доказывает доступность.
80РедкоПродвинутый PlaywrightКогда использовать component testing вместо E2E?
Как ответить на собеседовании
Когда важно проверить компонент в браузерном рендеринге с контролируемыми props и зависимостями, не поднимая весь продукт. Он быстрее E2E, но не закрывает интеграцию реальных страниц и backend.
Пример из практики
Component testing в PomidorQA я не использовал. Для сложной модалки бронирования он мог бы быстро проверить props и состояния, но финальный пользовательский путь всё равно оставил бы в E2E.
81РедкоПродвинутый PlaywrightКак service worker может помешать network interception?
Как ответить на собеседовании
Запрос может обслуживаться service worker и не дойти до маршрута, который ожидает тест. Для диагностики проверяют владение запросом и при необходимости блокируют service workers в тестовом context.
Пример из практики
С service worker в PomidorQA я не работал. Если route не видит ожидаемый запрос, я сначала проверю, не обслуживает ли его service worker, и при необходимости отключу его в тестовом context.
82РедкоПродвинутый PlaywrightКак тестировать WebSocket?
Как ответить на собеседовании
Наблюдать соединение и frames, синхронизировать действие с ожидаемым сообщением и проверять UI или состояние. Нельзя подменять проверку бизнес-результата фактом открытия сокета.
Пример из практики
WebSocket в проекте курса не было. Для чата или live-статуса я бы дождался нужного frame, а затем проверил изменение UI — открытое соединение само по себе ещё не бизнес-результат.
83РедкоПродвинутый PlaywrightЧем worker-scoped fixture отличается от test-scoped?
Как ответить на собеседовании
Test-scoped создаётся для каждого теста, worker-scoped — один раз на worker. Второй вариант экономит дорогой setup, но ресурс должен выдерживать совместное использование тестами этого worker.
Пример из практики
Worker-scoped fixture я бы взял для дорогого неизменяемого ресурса, например отдельного аккаунта на worker. Данные конкретного бронирования оставил бы test-scoped, чтобы тесты не делили состояние.
84РедкоПродвинутый PlaywrightКак проверить поведение при offline или плохой сети?
Как ответить на собеседовании
Контролировать offline/context и задержки на уровне маршрутизации или окружения, затем проверять пользовательское состояние: retry, кеш, сообщение и восстановление. Один искусственный timeout мало что доказывает.
Пример из практики
Offline-сценарий в PomidorQA я не реализовывал. Если бы делал, проверил бы сообщение пользователю, возможность retry и восстановление после возврата сети, а не только искусственный timeout.
85РедкоАрхитектура тестовКогда Screenplay может быть лучше POM?
Как ответить на собеседовании
В большом домене с несколькими ролями и переиспользуемыми tasks/questions он лучше разделяет намерение и способ взаимодействия. Для небольшого набора цена абстракций часто выше пользы.
Пример из практики
В учебном наборе POM был понятнее и дешевле. Screenplay я бы рассматривал, если появятся десятки ролей и повторяемых задач; ради пяти страниц такая абстракция только усложнит чтение.
86РедкоАрхитектура тестовКакие два принципа SOLID особенно полезны в тестовом фреймворке?
Как ответить на собеседовании
Обычно проще защитить SRP и dependency inversion: у класса одна причина для изменения, инфраструктурные детали зависят от контрактов. Важнее показать реальный рефакторинг, чем расшифровать все буквы.
Пример из практики
В ProfilePage я применяю SRP: он отвечает за профиль, а API-клиент — за запросы. Инверсию зависимостей подключал бы там, где нужно менять реализацию клиента или окружения, а не ради названия паттерна.
87РедкоJavaScript и TypeScriptЧто такое closure и где оно встречается в автотестах?
Как ответить на собеседовании
Функция сохраняет доступ к лексическому окружению после завершения внешней функции. Так можно создавать фабрики данных, конфигурируемые helpers и счётчики, но скрытое изменяемое состояние усложняет тесты.
Пример из практики
Фабрика makeUser замыкает runId и создаёт уникальные данные без передачи одного аргумента в каждый вызов. Но изменяемый счётчик внутри closure я бы использовал осторожно — он может связать тесты.
88РедкоJavaScript и TypeScriptЧем unknown отличается от any?
Как ответить на собеседовании
unknown принимает любое значение, но не позволяет использовать его без narrowing. any отключает проверку и распространяется по коду, поэтому unknown безопаснее на границе с внешними данными.
Пример из практики
Данные JSON от внешнего сервиса я принимаю как unknown и сначала проверяю схему. any дал бы обращаться к любому полю и лишил бы меня пользы TypeScript на самой опасной границе.
89РедкоЗапуск и масштабированиеКак сбалансировать шарды, если тесты разной длительности?
Как ответить на собеседовании
Использовать исторические длительности или fullyParallel, чтобы делить работу ближе к отдельным тестам, затем сравнить время каждого шарда. Деление только по количеству файлов часто оставляет один длинный хвост.
Пример из практики
Если один файл идёт 20 минут, а остальные по минуте, деление по числу файлов даст перекос. Я бы использовал историю длительностей или более мелкое распределение и сравнил время всех шардов.
90РедкоПроект и опытКак вы бы тестировали AI-функцию с недетерминированным ответом?
Как ответить на собеседовании
Разделить детерминированные контракты и вероятностное качество: схема, безопасность и tool calls проверяются строго, качество — на датасете с метриками и порогами. Один ожидаемый текст здесь хрупок и малоинформативен.
Пример из практики
AI-функции в базовом PomidorQA нет, поэтому реального опыта не приписываю. На таком проекте я бы строго проверял схему и безопасность, а качество ответов измерял на наборе примеров с порогами, а не одним ожидаемым текстом.