На позиции Senior QA Automation проверяют не только Python и автотесты. Кандидат должен понимать API, релизный процесс, тест-дизайн и диагностику проблем в рабочем продукте. Здесь мы собрали вопросы реального собеседования, правильные ответы и практические дополнения без личных данных участников.
Что проверяли на собеседовании QA Automation?
Сначала интервьюер уточнил базу Python: списки, словари и ограничения ключей. Затем разговор перешёл к pipeline, документации, оценке задач и работе единственным тестировщиком на молодом проекте. Техническая часть включала HTTP, JWT, JSON и лайвкодинг. В конце кандидат проектировал проверки уведомлений с учётом часовых поясов и разбирал жалобы пользователей.
Это хороший профиль Senior QA: язык и автотесты соединены с процессами команды, архитектурой приложения и ответственностью за качество релиза.
Чем list отличается от dict в Python?
Короткий ответ: list — изменяемая последовательность с числовыми индексами, dict — отображение уникальных хешируемых ключей в значения.
Список подходит, когда важны порядок и перебор элементов. Словарь выбирают для быстрого доступа по смысловому ключу. Ключом словаря может быть строка, число или неизменяемый кортеж из хешируемых объектов. Список ключом быть не может, потому что его содержимое меняется.
На собеседовании не стоит называть Python-список и массив полностью одинаковыми. В CPython список хранит ссылки на объекты и может содержать значения разных типов. Типизированные массивы и структуры NumPy имеют другой формат памяти и другие ограничения.
Ограничения ключей и основные операции со словарями описаны в официальном руководстве Python. На интервью достаточно объяснить механизм и привести задачу, где доступ по ключу полезнее последовательного поиска.
Как QA должен участвовать в работе над новой функцией?
Короткий ответ: подключаться до разработки, проверять требования и риски, оценивать тестирование и заранее готовить сценарии.
Подход shift left означает, что качество обсуждают раньше. QA читает требования, находит пропущенные валидации и неоднозначные состояния, уточняет критерии приёмки и только после этого оценивает работу. На молодом проекте один тестировщик обычно начинает с критических ручных проверок, документирует систему и постепенно строит автоматизацию.
Если документации нет, её не нужно превращать в отдельный бесконечный проект. Сначала фиксируем пользовательские потоки, контракты API, тестовые данные, известные ограничения и порядок выпуска. Эти материалы сразу помогают разработчикам и следующему сотруднику.
Что должен делать CI/CD pipeline с автотестами?
Короткий ответ: создать воспроизводимое окружение, установить зависимости, запустить нужные уровни тестов, собрать отчёт и остановить поставку при значимой ошибке.
Job должен давать понятный результат. Недостаточно команды pytest: сохраняем логи и артефакты, разделяем быстрые и долгие проверки, задаём таймауты и явно управляем секретами. Стадии обычно идут от сборки и статических проверок к тестам и развёртыванию. Независимые задания можно выполнять параллельно.
В документации GitLab показаны последовательные, параллельные и DAG-pipeline. Сильный QA объясняет не название схемы, а то, какие проверки блокируют релиз и где команда увидит причину падения.
Code freeze — временный запрет на изменения перед релизом — снижает риск, но не заменяет устойчивый процесс. Релизная ветка позволяет исправлять выпуск отдельно от новой разработки, однако требует правил переноса исправлений, чтобы ветки не разошлись.
Что отвечать про HTTP, POST, PUT и код 507?
Короткий ответ: объяснить смысл метода, его идемпотентность и ожидаемые ответы, а не перечислять определения.
POST обычно создаёт подчинённый ресурс или запускает операцию. PUT задаёт полное состояние ресурса по известному адресу; одинаковый повторный запрос не должен накапливать новые изменения. Частичное обновление обычно связывают с PATCH.
В ответе отдельно проверяются статусная строка, заголовки и тело. Источник: MDN — обзор HTTP.
Семантика методов закреплена в RFC 9110. Код 507 Insufficient Storage определён в RFC 4918 и сообщает, что сервер не может сохранить представление, необходимое для выполнения запроса. В тесте мы проверяем не только число 507, но и контракт ошибки, отсутствие частично записанных данных, повтор запроса и наблюдаемость проблемы.
Чем JWT отличается от Basic Auth?
Короткий ответ: Basic Auth передаёт учётные данные в каждом запросе, а JWT переносит набор утверждений и обычно подписывается, чтобы сервис мог проверить целостность токена.
JWT не равен шифрованию: содержимое подписанного токена можно прочитать. Сервис обязан проверить подпись, допустимый алгоритм, exp, iss, aud и нужные права. Поля токена описаны в RFC 7519, а безопасная проверка алгоритма и получателя — в RFC 8725. Один формат токена упрощает авторизацию в микросервисах, но общая ошибка проверки или утечка ключа затрагивает сразу несколько сервисов.
Как сравнивать объекты JSON без нестабильного ID?
Короткий ответ: явно определить значимые поля и сравнивать нормализованные представления объектов.
Если ID создаётся заново в разных средах, тест может исключить его. Но список игнорируемых полей должен быть явным: иначе проверка начнёт пропускать реальные ошибки. Для небольшого ответа читаемое решение выглядит так:
def without_fields(item: dict, ignored: set[str]) -> dict:
# Создаём новый словарь и не меняем исходный ответ API.
return {
key: value
for key, value in item.items()
if key not in ignored
}
def contains_object(
response_items: list[dict],
expected: dict,
ignored: set[str] = {"id"},
) -> bool:
# Нормализуем ожидаемый объект один раз перед циклом.
expected_data = without_fields(expected, ignored)
# Сравниваем только согласованный набор значимых полей.
return any(
without_fields(item, ignored) == expected_data
for item in response_items
)Для пагинации продолжаем запросы, пока объект не найден или страницы не закончились. Обязательно ставим предел числа запросов и проверяем контракт пагинации: текущую страницу, общее число страниц и отсутствие повторов.
Как тестировать запрет ночных уведомлений?
Короткий ответ: проверить обе границы интервала, время внутри и снаружи запрета, часовой пояс пользователя и доставку сообщения после окончания тихого периода.
Если уведомления запрещены с 21:00 до 06:00, базовые точки — 20:59, 21:00, 21:01, 05:59, 06:00 и 06:01. Добавляем разные часовые пояса, переход даты, 12- и 24-часовой формат, изменение настроек и пользователей, которые настройку не трогали.
Важный сценарий легко пропустить: сообщение не должно исчезнуть навсегда. Нужно проверить, ставится ли оно в очередь и приходит ли утром согласно требованиям.
Если жалоба есть только у части клиентов, воспроизводим конфигурацию, проверяем сохранённые настройки, запрос мобильного приложения, очередь сообщений и логи backend-сервисов. Несколько одинаковых жалоб — повод искать общую причину, а не списывать проблему на действия одного пользователя.
Получил ли кандидат оффер?
Да. Кандидат показал реальный опыт: объяснял работу с требованиями, релизами, API и логами, предлагал несколько решений и честно отмечал их минусы. В лайвкодинге он не ограничился одной проверкой JSON, а обсудил гибкость, производительность и пагинацию.
Именно такой ответ отличает заученную теорию от инженерного мышления. Кандидат не всегда начинал с идеальной формулировки, но уточнял задачу и уверенно доводил рассуждение до рабочего решения — после интервью он получил оффер.
Источники
частые вопросы
Короткие ответы
Что повторить перед собеседованием QA Automation на Python?
Повторите коллекции Python, HTTP и REST, авторизацию, работу с JSON, тест-дизайн, CI/CD, SQL и диагностику по логам. Подготовьте примеры, где вы улучшали процесс тестирования, а не только писали автотесты.
Чем список отличается от словаря в Python?
Список — изменяемая последовательность, элементы которой доступны по числовому индексу. Словарь хранит пары ключ — значение; ключи уникальны и должны быть хешируемыми.
В чём разница между POST и PUT?
POST обычно отправляют коллекции или обработчику для создания ресурса или выполнения действия. PUT обращается к известному URI и задаёт полное новое состояние ресурса; повтор одинакового PUT должен приводить к тому же результату.
Получил ли кандидат оффер QA Automation?
Да. Кандидат прошёл собеседование и получил оффер. Сильными сторонами стали практический опыт, подробные примеры и спокойное обсуждение ограничений решений.
