Вопросы на собеседовании: QA-инженер

Неявные и явные ожидания работают на разных уровнях, поэтому я их не смешиваю.

• Неявное ожидание глобально опрашивает каждый поиск элемента, а явное опрашивает одно условие в конкретной точке.
• При смешивании суммарное время становится непредсказуемым из-за взаимодействия опросов драйвера и явного условия.
• Я ставлю неявное ожидание в ноль и использую явные условия, которые показывают, чего ждёт тест.

Playwright автоматически ждёт готовности элемента к действию, но готовность приложения может требовать отдельного сигнала.

• Перед кликом он ждёт, пока элемент будет в DOM, видим, стабилен, доступен и не перекрыт.
• Этого мало, если данные ещё загружаются, отложенное действие не сработало или проверка зависит от фонового запроса.
• Я жду реальный сигнал через проверку, конкретный ответ сети или состояние интерфейса, появляющееся после готовности данных.

Я выбираю стабильные и осмысленные локаторы, а длинные XPath-цепочки оставляю только для неизменяемого легаси-DOM.

• Первый выбор это согласованный тестовый атрибут вроде data-testid, устойчивый к изменениям стилей и текста.
• Затем идут роль и доступное имя, после них стабильные ID или короткие CSS-селекторы.
• Длинные позиционные XPath-цепочки описывают вёрстку вместо смысла и ломаются при обычном рефакторинге DOM.

Page Object должен описывать страницу и действия пользователя, но не владеть ожиданиями и сценарием теста.

• В нём находятся локаторы страницы, осмысленные действия и навигация с возвратом следующего Page Object.
• Проверки, выбор тестовых данных и логика сценария остаются в тесте, чтобы его цель была видна.
• Я держу объекты компактными и делю большие страницы на компоненты вроде шапки, таблицы и модального окна.

Сложные предусловия я создаю через самый быстрый надёжный путь без UI, оставляя интерфейс для проверяемого поведения.

• Вызовы API или фабрика данных через сервисный слой могут подготовить подписку и прошлые заказы до теста.
• Подготовка через регистрацию и оформление заказа замедляет тесты и позволяет одному раннему сбою сломать много несвязанных кейсов.
• Прямые вставки в базу я использую только при отсутствии API, поскольку они обходят бизнес-правила и могут создать невозможное состояние.

Selenium, Cypress и Playwright я выбираю по архитектуре, экосистеме и ограничениям проекта.

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

Я жду положительный признак готовности приложения, а не просто исчезновение индикатора загрузки.

• Надёжным сигналом служат видимые данные, конкретный питающий экран ответ или состояние вроде data-loaded.
• Исчезновение спиннера ненадёжно, поскольку между цепочками запросов может возникнуть ложный момент готовности.
• Фиксированные паузы ещё хуже: на медленном окружении их не хватает, а на быстром они тратят время.

StaleElementReferenceException означает, что сохранённый элемент ссылается на заменённый или отсоединённый DOM-узел.

• Изменения состояния во фреймворках вроде React часто заменяют поддеревья и делают кешированные ссылки устаревшими.
• Правильный фикс ищет элемент в момент взаимодействия и повторяет поиск при устаревании, а не кеширует ссылку между действиями.
• Локаторы Playwright разрешаются заново для каждого действия, и обёртки Selenium могут следовать тому же подходу.

Независимые тесты дают понятные падения, поддерживают параллельный запуск и выполняются по отдельности.

• Зависимости вызывают каскадные сбои и превращают одну регрессию во множество ложных красных тестов.
• Каждый тест сам создаёт данные с уникальными идентификаторами и не полагается на предыдущий тест или общий аккаунт.
• Случайный порядок выполнения в CI выявляет скрытые связи до того, как они станут привычной практикой.

Я переиспользую состояние авторизации по ролям, чтобы логин не занимал основное время E2E-набора.

• Я вхожу через API или один раз через UI, сохраняю cookies либо storage state и передаю их в контекст теста.
• Сам UI-сценарий входа остаётся в небольшом отдельном наборе и не повторяется в каждом тесте.
• Я учитываю истечение токена и выдаю параллельным воркерам разных пользователей, чтобы они не мешали друг другу.

Iframe и shadow DOM требуют явно учитывать разные границы поиска элементов.

• Selenium переключается в iframe и обратно, а Playwright обращается к нему через frameLocator.
• Открытые shadow root доступны современным CSS-запросам Playwright и Selenium, но для закрытых нужен тестовый хук от разработчиков.
• Работу с фреймами и shadow root я прячу в Page Object, чтобы код сценария оставался понятным.

Файловые сценарии я автоматизирую через API браузера и проверяю сам артефакт, а не только видимое действие.

• Для загрузки передаю небольшую фикстуру из репозитория в input через setInputFiles или sendKeys, а выбор файла перехватываю лишь для кастомных виджетов.
• Для скачивания отключаю запрос подтверждения, жду событие загрузки и проверяю имя и размер файла.
• Форматы вроде CSV или PDF я разбираю и проверяю по содержимому, поскольку появление файла не доказывает его корректность.

Каждое падение UI-теста в CI должно автоматически сохранять достаточно данных для удалённой диагностики.

• Я собираю скриншот падения, видео прогона, консоль браузера, сетевые логи и по возможности трейс Playwright.
• Трейс или видео показывают состояние UI, консоль выявляет клиентские ошибки, а сеть отделяет сбой интерфейса от ошибки бэкенда.
• Автоматический сбор артефактов обязателен, иначе падения только в CI приходится долго воспроизводить локально.

Для каждого риска я выбираю самый дешёвый уровень тестирования, который надёжно его обнаружит.

• Юнит- и интеграционные тесты покрывают бизнес-логику и границы, а контрактные и API-тесты проверяют валидацию, права и ошибки сервиса.
• На уровне E2E остаются несколько путей, доказывающих, что части вместе завершают критичные процессы вроде оформления и оплаты.
• Так не возникает перевёрнутая пирамида из медленных UI-тестов, повторяющих миллисекундные проверки нижних уровней.

Я автоматизирую сценарии, где повторяемость и риск регрессии оправдывают стоимость разработки и поддержки.

• Основные успешные пути, границы и права на уровне API, а также проверки каждого релиза обычно стоит автоматизировать.
• Одноразовое исследование, быстро меняющийся UI и субъективную оценку внешнего вида часто дешевле и лучше проверять вручную.
• Я объясняю, что автоматизация является сопровождаемым кодом, а исследовательское тестирование остаётся полноценной частью плана.

Жёсткие или мягкие проверки я выбираю по тому, сохраняют ли смысл следующие шаги после сбоя.

• Жёсткая проверка сразу останавливает тест, когда дальнейшие действия зависят от проваленного предусловия.
• Мягкие проверки собирают независимые расхождения, например по нескольким полям формы или колонкам отчёта, и выводят их вместе.
• Если фреймворк требует финальный assert-all, я обеспечиваю его через фикстуру, чтобы забытый вызов не дал ложный успех.

Единый механизм конфигурации на основе профилей позволяет запускать один набор без правок на разных окружениях.

• Один переключатель выбирает базовые URL, ссылки на учётные данные, фичефлаги и таймауты из переменных окружения или файлов профиля.
• CI получает секреты из защищённого хранилища, а локальный запуск использует игнорируемый env-файл.
• Тесты обращаются к логическим именам вроде администратора или платёжной песочницы и не содержат значений конкретного окружения.

Визуальное регрессионное тестирование сравнивает снимки интерфейса с утверждёнными эталонами и требует осознанного охвата.

• Инструменты используют попиксельное или визуальное сравнение, пороги и исключённые зоны для динамического содержимого перед ручным ревью.
• Подход окупается для стабильных дизайн-систем, библиотек компонентов и важных страниц, где случайные изменения CSS критичны.
• Я стабилизирую данные и анимации, избегаю изменчивых полных страниц и проверяю обновления эталонов в PR.

Матрицу мобильного покрытия я строю по типу продукта и реальным рискам использования, а не по всем возможным устройствам.

• Адаптивный веб широко проверяется эмуляцией браузера, а небольшой прогон на реальных устройствах покрывает сенсорный ввод и особенности рендеринга.
• Нативные и гибридные приложения в основном тестируются на эмуляторах, а перед релизом на популярных реальных устройствах из фермы.
• Реальные устройства покрывают пробелы вроде производительности старого железа, диалогов разрешений и прерываний звонками.

Широкое функциональное покрытие я запускаю в одном основном браузере, а кросс-браузерные проверки направляю на реальные различия движков.

• Полный набор обычно работает в Chromium, поскольку большинство функциональных дефектов не зависит от браузера.
• Критичные пути и чувствительные к браузеру случаи рендеринга, ввода или API дополнительно идут в Firefox и WebKit.
• Матрицу определяет продуктовая аналитика, а браузеры с малой долей получают задокументированный смоук или не покрываются.