На собеседовании QA Automation на Python кандидату предложили протестировать форму перевода, объяснить уровни тестов, сравнить архитектуры и ответить на вопросы по API, токенам и SQL. Заявленный уровень был Junior, но глубина некоторых ответов соответствовала более опытному специалисту.
Как протестировать форму перевода через СБП
Начать нужно с уточнения требований: допустимые номера, сумма и лимиты, авторизация, комиссия, повторная отправка, статусы операции и поведение при недоступном банке. Пароль как единственное второе поле выглядит нетипично для реальной СБП-формы, поэтому это тоже повод уточнить условие, а не молча достраивать систему.
Удобно разделить проверки:
- Валидные и невалидные форматы номера и суммы.
- Минимальный, максимальный и превышенный лимит.
- Двойной клик и повтор одного запроса.
- Тайм-аут, отказ банка и потеря сети после отправки.
- Успешный, отклонённый и неопределённый статус операции.
- Маскирование чувствительных данных в интерфейсе и логах.
Главный риск платёжной формы — не красная рамка у поля, а двойное списание или потерянный статус. Поэтому позитивный сценарий дополняют проверками повторов и восстановления после сбоя.
Что означает пирамида тестирования
Пирамида предлагает много быстрых низкоуровневых тестов, меньше интеграционных и небольшой набор дорогих end-to-end проверок. Это ориентир для сбалансированного набора, а не строгий список из трёх или четырёх обязательных этажей. В практическом разборе Мартина Фаулера основной принцип сформулирован просто: чем выше уровень, тем меньше таких тестов должно быть.
Чем выше тест, тем шире сценарий и дороже обратная связь. Источник: The Practical Test Pyramid.
Реальные устройства нужны для рисков, которые эмуляция передаёт плохо: производительность, сенсоры, разрешения, особенности ОС и производителя. Для веба отдельно проверяют движки Chromium, Gecko и WebKit, а не каждый существующий браузер без приоритета.
Чем отличается тестирование монолита и микросервисов
Монолит разворачивает основные части приложения вместе. Микросервисная система разделяет их по процессам и сетевым границам. Это не означает, что микросервисы всегда современнее или лучше: они добавляют задержки, версионирование контрактов и частичные отказы.
В обоих случаях нужны компонентные, интеграционные и пользовательские проверки. Для микросервисов дополнительно важны:
- Контракты запросов, ответов и сообщений.
- Тайм-ауты, повторы и идемпотентность.
- Недоступность одного сервиса при работающих остальных.
- Дубли, нарушение порядка и задержка сообщений.
- Сквозная трассировка операции между компонентами.
Чем отличаются POST, PUT и PATCH
POST отправляет данные ресурсу и часто создаёт новую сущность или запускает обработку. PUT заменяет текущее представление ресурса по известному адресу. PATCH применяет частичные изменения. Краткая семантика методов собрана в справочнике MDN.
Идемпотентный запрос при повторе имеет тот же ожидаемый эффект на сервере, что и один запрос. HTTP считает PUT идемпотентным, а POST и PATCH не гарантирует таковыми. Но конкретный API может спроектировать безопасный повтор через ключ идемпотентности. Поэтому тестировщик проверяет не название метода, а фактический контракт и состояние системы.
Что нужно знать о брокерах сообщений и JWT
Брокер сообщений принимает данные от отправителя и передаёт потребителю через очередь или другой механизм доставки. RabbitMQ, например, строит модель вокруг producer, queue и consumer; базовый поток показан в официальном руководстве. Для тестов важны подтверждения, повторная доставка, порядок, недоступный потребитель и «мёртвые» сообщения.
JWT — компактный формат подписанного набора утверждений. Он состоит из частей, разделённых точками, и не обязан скрывать содержимое: подпись защищает от незаметного изменения, но payload обычно можно декодировать. Структуру и стандартные поля определяет RFC 7519. Аутентификация отвечает на вопрос «кто это», авторизация — «что ему разрешено».
Как выбрать предпоследнюю дату в SQL
Сначала нужно уточнить: предпоследняя строка или предпоследняя уникальная дата, общая для таблицы или отдельная для каждой сущности. Для второй уникальной даты по пользователю подходит DENSE_RANK():
WITH ranked_dates AS (
SELECT
user_id,
event_date,
-- Одинаковые даты получают один ранг.
DENSE_RANK() OVER (
PARTITION BY user_id ORDER BY event_date DESC
) AS date_rank
FROM events
)
SELECT user_id, event_date
FROM ranked_dates
WHERE date_rank = 2;
Оконные функции выполняются после фильтрации строк, поэтому их результат обычно фильтруют во внешнем запросе. Такой приём описан в документации PostgreSQL.
Итог: получил бы кандидат оффер
Фактический результат встречи не назван. По технической части кандидат скорее получил бы положительное решение: уточнял требования, знал уровни тестов, понимал границы микросервисов и уверенно отвечал по API. Ответы местами были заметно глубже ожидаемого Junior-уровня. На следующем этапе мы бы проверили Python-автоматизацию, проектирование тестов и работу с реальным сервисом.
Источники
частые вопросы
Короткие ответы
Что должен знать Junior QA Automation про API?
Семантику HTTP-методов и статусов, структуру запроса и ответа, авторизацию, идемпотентность, контракты, негативные проверки и работу зависимостей.
Нужно ли тестировщику понимать микросервисы?
Да. Даже новичку важно видеть границы сервисов, способы обмена данными и дополнительные точки отказа, которых нет внутри одного процесса.
Как отвечать на задачу «протестируйте форму»?
Сначала уточните требования и главные риски, затем разделите проверки на валидацию, бизнес-правила, интеграции, безопасность и состояние интерфейса.
