Middle QA Automation — вопросы на собеседовании QA Automation

В чём разница между implicit, explicit и fluent wait?

Implicit wait — глобальная настройка, из-за которой любой поиск элемента повторяется до N секунд. Explicit wait ждёт одно конкретное условие — элемент кликабелен, текст появился — и только его. Fluent wait это explicit с настраиваемым интервалом опроса и списком игнорируемых исключений. Смешивание implicit и explicit даёт непредсказуемые суммарные таймауты, поэтому большинство команд полностью отключают implicit и используют explicit.

Какие локаторы вы используете и почему XPath часто считают плохой практикой?

Предпочтительный порядок: специальный тестовый атрибут вроде data-testid, затем id, затем стабильный CSS-селектор. У XPath плохая репутация из-за абсолютных путей, которые ломаются от любого изменения DOM, и длинных относительных выражений, которые тяжело читать. Сам по себе XPath нормален и иногда незаменим — например поиск по видимому тексту или переход к родителю — проблема в хрупких XPath, а не в языке.

Что такое flaky-тест? Назовите причины и способы устранения.

Flaky-тест падает и проходит без изменений в коде. Обычные причины: предположения о времени (жёсткие sleep вместо ожидания условия), общие изменяемые тестовые данные, зависимость от порядка запуска, анимации, нестабильные окружения и сторонние сервисы. Лечение: ждать явные условия, генерировать изолированные данные под каждый тест, делать тесты независимыми и идемпотентными, мокать внешние сервисы и выносить нестабильные тесты в карантин вместо перезапусков до зелёного.

Как организовать параллельный запуск тестов? Какие проблемы возникают?

Параллельность настраивается на уровне раннера и обычно сочетается с Selenium Grid или контейнерами. Проблемы связаны с общим состоянием: тесты пишут в один аккаунт или одни строки БД, конфликтуют по портам и файлам, полагаются на порядок выполнения. Решение в том, что каждый тест создаёт свои данные с уникальными идентификаторами, не трогает глобальные ресурсы в setup и никогда не предполагает, что работает один.

Чем Playwright отличается от Selenium? Когда выбрать каждый?

Playwright общается с браузером по DevTools-протоколу, автоматически ждёт готовности элемента и из коробки даёт трейсинг, перехват сети и изоляцию для параллельного запуска — поэтому ожиданий в коде почти не нужно. Selenium — стандарт W3C с самой широкой поддержкой браузеров, языков и грида, глубоко укоренённый в корпоративной инфраструктуре. Playwright берут для нового проекта под современные браузеры, Selenium — когда нужна поддержка легаси или встроиться в существующую экосистему.

Как вы тестируете REST API? Какие инструменты используете?

Проверяют статус-коды, схему ответа, значения в теле, заголовки, обработку невалидного ввода, а также границы аутентификации и авторизации. Инструменты — Postman или Insomnia для разведки и RestAssured, Playwright APIRequest, requests или supertest для автотестов. API-тесты дешевле и намного стабильнее UI-тестов, поэтому основное покрытие должно жить именно там.

Что такое тестовая пирамида? Какое соотношение unit/integration/e2e оптимально?

Пирамида говорит, что нужно много быстрых unit-тестов, меньше интеграционных и совсем немного end-to-end, потому что вверх растут и стоимость, и нестабильность. Часто называют пропорцию примерно 70/20/10, но важнее не цифра, а принцип: опускать каждую проверку на самый низкий уровень, где она способна поймать баг. E2E должны покрывать только критичные пользовательские сценарии, а не бизнес-логику.

Как интегрировать автотесты в CI/CD pipeline?

Тесты запускаются на каждый pull request, обычно разделённые на быстрый smoke на каждый коммит и полную регрессию на мерж или по ночам. Пайплайн поднимает чистое окружение, гоняет наборы параллельно, публикует отчёты и артефакты вроде скриншотов и трейсов, и валит сборку при регрессии. Работает это только при правиле, что красный пайплайн блокирует мерж — иначе набор тестов деградирует.

Что такое data-driven testing и как его реализовать?

Data-driven разделяет логику теста и данные, поэтому один тест прогоняется на множестве наборов из CSV, JSON или параметризованного провайдера. Это умножает покрытие без умножения кода и превращает добавление кейса в правку данных, а не кода. Подвох в нечитаемых падениях — всегда подставляйте входные данные в имя теста, чтобы по отчёту было видно, какой именно кейс сломался.

Что стоит автоматизировать, а что нет?

Автоматизируют стабильные, повторяемые и ценные проверки: регрессию, smoke, контракты API и сценарии с большим объёмом данных. Не автоматизируют быстро меняющийся UI, разовые проверки, исследовательское тестирование, оценку удобства и внешнего вида, а также всё, где написание и поддержка теста дороже ручного прогона. Решающий вопрос — сколько раз проверка отработает до того, как изменится.