На собеседовании QA Automation проверяют знание фреймворков, паттернов автоматизации и — прежде всего — умение писать тесты, которые остаются зелёными не по случайности. Ниже — частые вопросы с эталонными ответами.
К каждому вопросу — эталонный ответ, с которым можно сравнить свой.
Page Object Model оборачивает каждую страницу или компонент в класс, который отдаёт локаторы и высокоуровневые действия, поэтому тесты описывают намерение, а не клики. Он решает проблему поддержки: при изменении вёрстки правишь один page object вместо пятидесяти тестов. Ещё он убирает дублирование и делает тесты читаемыми для тех, кто их не писал.
Implicit wait — глобальная настройка, из-за которой любой поиск элемента повторяется до N секунд. Explicit wait ждёт одно конкретное условие — элемент кликабелен, текст появился — и только его. Fluent wait это explicit с настраиваемым интервалом опроса и списком игнорируемых исключений. Смешивание implicit и explicit даёт непредсказуемые суммарные таймауты, поэтому большинство команд полностью отключают implicit и используют explicit.
Предпочтительный порядок: специальный тестовый атрибут вроде data-testid, затем id, затем стабильный CSS-селектор. У XPath плохая репутация из-за абсолютных путей, которые ломаются от любого изменения DOM, и длинных относительных выражений, которые тяжело читать. Сам по себе XPath нормален и иногда незаменим — например поиск по видимому тексту или переход к родителю — проблема в хрупких XPath, а не в языке.
Flaky-тест падает и проходит без изменений в коде. Обычные причины: предположения о времени (жёсткие sleep вместо ожидания условия), общие изменяемые тестовые данные, зависимость от порядка запуска, анимации, нестабильные окружения и сторонние сервисы. Лечение: ждать явные условия, генерировать изолированные данные под каждый тест, делать тесты независимыми и идемпотентными, мокать внешние сервисы и выносить нестабильные тесты в карантин вместо перезапусков до зелёного.
Параллельность настраивается на уровне раннера и обычно сочетается с Selenium Grid или контейнерами. Проблемы связаны с общим состоянием: тесты пишут в один аккаунт или одни строки БД, конфликтуют по портам и файлам, полагаются на порядок выполнения. Решение в том, что каждый тест создаёт свои данные с уникальными идентификаторами, не трогает глобальные ресурсы в setup и никогда не предполагает, что работает один.
Playwright общается с браузером по DevTools-протоколу, автоматически ждёт готовности элемента и из коробки даёт трейсинг, перехват сети и изоляцию для параллельного запуска — поэтому ожиданий в коде почти не нужно. Selenium — стандарт W3C с самой широкой поддержкой браузеров, языков и грида, глубоко укоренённый в корпоративной инфраструктуре. Playwright берут для нового проекта под современные браузеры, Selenium — когда нужна поддержка легаси или встроиться в существующую экосистему.
Проверяют статус-коды, схему ответа, значения в теле, заголовки, обработку невалидного ввода, а также границы аутентификации и авторизации. Инструменты — Postman или Insomnia для разведки и RestAssured, Playwright APIRequest, requests или supertest для автотестов. API-тесты дешевле и намного стабильнее UI-тестов, поэтому основное покрытие должно жить именно там.
Пирамида говорит, что нужно много быстрых unit-тестов, меньше интеграционных и совсем немного end-to-end, потому что вверх растут и стоимость, и нестабильность. Часто называют пропорцию примерно 70/20/10, но важнее не цифра, а принцип: опускать каждую проверку на самый низкий уровень, где она способна поймать баг. E2E должны покрывать только критичные пользовательские сценарии, а не бизнес-логику.
Тесты запускаются на каждый pull request, обычно разделённые на быстрый smoke на каждый коммит и полную регрессию на мерж или по ночам. Пайплайн поднимает чистое окружение, гоняет наборы параллельно, публикует отчёты и артефакты вроде скриншотов и трейсов, и валит сборку при регрессии. Работает это только при правиле, что красный пайплайн блокирует мерж — иначе набор тестов деградирует.
Data-driven разделяет логику теста и данные, поэтому один тест прогоняется на множестве наборов из CSV, JSON или параметризованного провайдера. Это умножает покрытие без умножения кода и превращает добавление кейса в правку данных, а не кода. Подвох в нечитаемых падениях — всегда подставляйте входные данные в имя теста, чтобы по отчёту было видно, какой именно кейс сломался.
Автоматизируют стабильные, повторяемые и ценные проверки: регрессию, smoke, контракты API и сценарии с большим объёмом данных. Не автоматизируют быстро меняющийся UI, разовые проверки, исследовательское тестирование, оценку удобства и внешнего вида, а также всё, где написание и поддержка теста дороже ручного прогона. Решающий вопрос — сколько раз проверка отработает до того, как изменится.
Каждый тест должен сам создавать нужные данные и убирать за собой, желательно через API или сидинг базы, а не через UI — это быстрее и надёжнее. Общие фикстуры приводят к зависимости от порядка и загадочным падениям. По окружениям изоляцию дают контейнеры или эфемерные инстансы на каждый прогон; если общее окружение неизбежно, все данные нужно помечать уникальным идентификатором прогона.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью QA Automation →