Подготовка к техническим собеседованиям для QA специалистов

Об авторе

Спикер имеет опыт преподавания физики (6 лет) и работы в сфере тестирования (10 лет). Сейчас находится в декретном отпуске с частичной занятостью в финтех-компании (работает с платформой единой фронтальной системы). Ведет блог ProTestingInfo, делится актуальной информацией и снимает видеоконтент для социальных сетей. Активно разбирает вопросы с собеседований в соцсетях, составляет посты и Reels с ответами на часто задаваемые вопросы.

Введение в вебинар

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

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

Первые три вопроса охватывают позицию младшего тестировщика
Четвертый вопрос про Kafka больше касается позиции Middle и Senior специалистов

План вебинара

Вопрос об авторизации (логин, пароль)
Практический вопрос про SQL (декартово произведение таблиц)
Анализ JSON-запросов в системах доставки
Сквозной (end-to-end) сценарий с тремя сервисами и Kafka

Вопрос 1: Анализ формы авторизации

Сценарий

Рассмотрим типичный сценарий авторизации. Пользователь вводит существующий логин и неверный пароль, нажимает кнопку входа, после чего система отображает ошибку.

Возможны вариации:

Существующий логин + неверный пароль
Неверный логин + существующий пароль
Оба значения неверны

На ответ потребуется 5-10 минут. Интервьюер ожидает услышать ваше рассуждение о том, что происходит на стороне системы, в области взаимодействия клиент-сервер, безопасности и валидации.

На что обратить внимание

Ваша задача проговорить:

Проверки на стороне фронтенда и бэкенда

Используя DevTools (Firefox или Chrome), нужно проанализировать сетевые запросы. В Chrome смотрите фильтр XHR, в Firefox используйте Inspect UI → Network. Ищите:

HTTP запрос при отправке учетных данных
Ответ от сервера
JavaScript валидация на стороне фронта
Возможные сообщения об ошибках

Поведение сервера

Система может вернуть несколько типов реакций:

Просто сообщение об ошибке
Временная блокировка аккаунта после нескольких неудачных попыток
Общее сообщение об ошибке для безопасности (чтобы не раскрыть информацию о существовании логина)

Важный момент: Хорошей практикой является возвращать общее сообщение об ошибке типа "неверный логин или пароль" вместо раскрытия того, существует ли аккаунт. Это защищает от перечисления пользователей.

Порядок действий сервера при получении запроса авторизации

Валидация входящих данных - проверка формата и наличия обязательных полей
Поиск и верификация учетных данных - сервер ищет пользователя по логину и сравнивает хэш введенного пароля с хэшем в базе данных
Регистрация неудачной попытки - логирование и аудит события (редко упоминается, но важно)
Формирование ответа об ошибке - генерация сообщения, указывающего на сбой аутентификации

Возможные статус-коды

400 - неверный запрос
401 - не авторизован
403 - запрещено
412 - условие предварительно не выполнено (редко, но встречается на тестовых стендах)
429 - слишком много запросов (для защиты от перебора)

Что проверять при ответе

Статус ответа - какой HTTP код вернулся
Содержимое ошибки - что написано в теле ответа
Идентичность сообщений - убедиться, что сообщение об ошибке одинаково для неверного логина и пароля (защита от перечисления)
Лимиты на попытки - существует ли ограничение на количество попыток входа
Механизм сброса счетчика - как корректно сбрасывается счетчик неудачных попыток
Логирование и аудит - какие события фиксируются в серверных логах при каждой неуспешной попытке

Дополнительные улучшения формы авторизации

Интервьюер может намеренно скрыть некоторые элементы на форме. Вы должны предложить улучшения:

Кнопка "Создать аккаунт" / регистрация
Функция "Восстановить пароль" / "Забыли пароль?"
Капча (может появиться после нескольких неудачных попыток)
Двухфакторная аутентификация (2FA)
Показ/скрытие пароля

Пример на основе опыта

На некоторых сайтах (например, www.reg.ru) после неправильного ввода 3-х раз логина система показывает сообщение типа "попытайтесь позже через полчаса", что указывает на временную блокировку аккаунта.

На сайте ViKunja при вводе существующего логина и неверного пароля возвращается статус 403 с сообщением "неправильный пароль или юзернейм".

На других сайтах для повышенной безопасности возвращается статус 200 даже при ошибке, чтобы скрыть реальную причину отказа от злоумышленников.

Двухфакторная аутентификация

Некоторые системы реализуют двухэтапную проверку:

Первый шаг: всегда возвращает 200 при корректной отправке данных
Второй шаг (2FA): вернет 401, если 2FA данные неверны

Это делается для защиты от перебора и раскрытия зарегистрированных почт.

Вопрос 2: SQL - Декартово произведение таблиц

Сценарий задачи

Даны две таблицы:

Таблица A: 4 строки, 2 столбца
Таблица B: 3 строки, 4 столбца

Вопрос: Что вернет запрос SELECT * FROM a, b?

Это одна из частых ошибок на собеседованиях, которая сразу может снизить оценку кандидата.

Что такое декартово произведение

Запрос SELECT * FROM a, b (или SELECT * FROM a CROSS JOIN b) создает декартово произведение между двумя таблицами. Это означает, что каждая строка первой таблицы комбинируется со всеми строками второй таблицы.

Количество строк в результате = кол-во строк в таблице A × кол-во строк в таблице B

В нашем примере: 4 × 3 = 12 строк

Количество столбцов в результате = кол-во столбцов в таблице A + кол-во столбцов в таблице B

В нашем примере: 2 + 4 = 6 столбцов

Как ответить правильно

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

Сначала выводятся все столбцы из таблицы A, затем все столбцы из таблицы B.

Практический примерРезультат SELECT * FROM a, b:

A.ID | A.Name | B.Code

1    | 10     | 10

1    | 10     | 20

1    | 10     | 30

2    | 20     | 10

2    | 20     | 20

2    | 20     | 30

3    | 30     | 10

3    | 30     | 20

3    | 30     | 30

4    | 40     | 10

4    | 40     | 20

4    | 40     | 30

Итого: 12 строк, 3 столбца (2 из A + 1 из B)

Частая ошибка

Многие кандидаты вместо умножения используют сложение и отвечают "10 строк" (5+5) вместо правильного ответа "25 строк" (5×5).

Это критическая ошибка, которая может привести к дальнейшим более сложным вопросам по SQL или полному прекращению линии вопросов.

Как практиковаться

Используйте онлайн-платформы для SQL (например, SQL тренажеры с PostgreSQL), создавайте таблицы и выполняйте запросы, чтобы увидеть реальный результат.

Вопрос 3: Анализ JSON-запросов в системах доставки

Введение

Многие компании, особенно работающие с доставкой заказов (Valbergs, Ozon и др.), любят задавать вопросы о JSON-объектах. В этих вопросах либо нарушена бизнес-логика, либо нарушена валидация JSON структуры.

Вас просят проанализировать структуру и объяснить:

Какие основные три бизнес-сценария важны для клиента
Какие проверки необходимо выполнить
Какие ошибки и проблемы вы видите

Важное замечание

Когда вам дают JSON-объект для анализа, не спешите проверять синтаксис и типы данных. Сначала сосредоточьтесь на бизнес-логике. Спросите себя:

Чего не хватает в этой структуре?
Что нужно добавить?
Что можно улучшить?

Только потом переходите к проверке формата JSON.

Пример структуры JSON (адрес доставки)

Типичная структура для заказа с доставкой может содержать:

json
{

  "order_id": "UUID",

  "address": {

    "country": "Croatia",

    "city": "Moscow",

    "postal_code": "12345"

  }

}

Чего не хватает в этой структуре

По бизнес-логике:

Улица и номер дома - необходимо указать конкретный адрес
Ожидаемая дата доставки - очень важно для клиента знать, когда придет заказ
Метод доставки - курьер, самовывоз, почта и т.д.
Опция оставления у двери - для удобства клиента (true/false)
ID адреса (address_id) - для связи между адресом и заказом
Часовой пояс - важно, если заказ делается в одном городе, а доставка в другом

Логическая ошибка в примере:
Страна указана как "Croatia", а город как "Moscow". Это противоречие, которое нужно заметить.

Три основных бизнес-сценария для проверки

Корректность адреса доставки
- Адрес содержит ожидаемую дату доставки
- Все поля заполнены корректно
- Данные соответствуют выбранному методу доставки
Консистентность данных
- Страна и город совпадают
- Способ доставки доступен для данного адреса
- Почтовый индекс соответствует городу и стране
Функциональность для клиента
- Клиент видит сумму к оплате
- Клиент видит дату и время доставки
- Клиент может выбрать метод доставки (курьер, самовывоз, пункт выдачи)

Проверки при тестировании

Валидация JSON:

Проверка синтаксиса JSON (запятые, кавычки, скобки)
Проверка типов данных (строки, числа, булевы значения)
Проверка обязательных полей

Статус-коды при ошибках:

400 - неверный запрос (ошибка в синтаксисе JSON)
422 - неправильный формат данных (валидация не пройдена)
403 - доступ запрещен
404 - ресурс не найден

Примеры невалидных JSON:

Адрес как массив вместо объекта (если это не предусмотрено логикой)
Отсутствие обязательных полей
Неверные типы данных (число вместо строки для postal_code)
Нарушение логики (страна не соответствует городу)

Практический совет

Для подготовки:

Сделайте заказ на реальном сайте и посмотрите запрос в DevTools
Найдите соответствующий POST запрос и изучите структуру JSON
Обратите внимание на все поля, которые включены в тело запроса
Скопируйте структуру и используйте как шаблон для ответов на собеседовании

Вопрос 4: End-to-End тестирование с Kafka

Введение

Это вопрос больше подходит для Middle и Senior специалистов, но начинающим советуется изучить эту тему, так как она часто встречается на собеседованиях.

Важно: Если вы еще никогда не работали с Kafka, не паникуйте. Советуется посмотреть примеры и пройти практические симуляторы.

Сценарий

Представьте систему с тремя сервисами:

Publisher (Издатель) - записывает события в Kafka топик
Processor (Обработчик) - читает события, обрабатывает их и публикует результат в другой топик
Observer (Наблюдатель) - фиксирует уведомления о завершении обработки

Вопрос: Какие типичные риски нужно проверить при работе с Kafka?

Подсказка: Потеря сообщений, дублирование сообщений, нарушение порядка сообщений.

Типичные риски при работе с Kafka

Потеря сообщений - сообщение не достигло целевого сервиса
Дублирование сообщений - одно сообщение обработано несколько раз
Нарушение порядка - сообщения обработаны не в том порядке, в котором были отправлены

Как тестировать End-to-End сценарий

Основные этапы:

Эмулирование отправки события - через API, мобильное приложение или веб-интерфейс инициируете действие, которое должно создать событие
Проверка наличия события в топике - используя специализированные инструменты (Offset Explorer, AQHQ и др.), проверяете, что сообщение появилось в соответствующем топике Kafka
Анализ содержимого сообщения - убеждаетесь, что структура и данные сообщения соответствуют ожиданиям
Проверка обработки - отслеживаете, как Processor обработал сообщение, и что результат опубликован в выходном топике
Получение уведомления в другом сервисе - проверяете логи (через Kibana, OpenSearch или другие инструменты), что Observer получил уведомление и обработал событие
Проверка консистентности данных - убеждаетесь, что идентификаторы (ID) одного события проходят через всю цепочку сервисов без изменений

Инструменты для мониторинга

Offset Explorer - десктопное приложение для просмотра топиков, партиций и сообщений Kafka
AQHQ - веб-интерфейс для управления Kafka
Kibana / OpenSearch - для просмотра логов приложений
Elasticsearch - хранилище логов, которое индексирует данные

Важно: На многих коммерческих проектах разработчики не заходят напрямую в Kafka инструменты. Все данные логируются и анализируются через Kibana или OpenSearch.

Как ответить без опыта

Если у вас нет коммерческого опыта с Kafka:

Проговорите основные шаги тестирования (отправка, проверка в топике, проверка логов, проверка в другом сервисе)
Упомяните инструменты, которые бы использовали (Offset Explorer, Kibana)
Скажите, на что обратите внимание (наличие сообщения, дублирование, порядок)
Приведите примеры возможных проблем (потеря сообщения, дублирование)

Особенности тестирования брокеров сообщений

Проверка корректности отправки - убедиться, что сообщение попало в правильный топик и партицию
Проверка на дублирование - убедиться, что нет дублирующихся сообщений
Проверка содержимого - сообщение соответствует ожидаемому формату и данным
Обработка множества сообщений - проверить поведение при большом объеме данных
Загрузка собственных сообщений - эмулировать события вручную через инструменты
Проверка взаимодействия сервисов - убедиться, что сервисы корректно общаются через Kafka
Проверка порядка и времени - убедиться, что сообщения обрабатываются в правильном порядке

Реальный пример

На одном из коммерческих проектов была система публикации статей, включающая 8 сервисов. Для того чтобы статья полностью пройдя через всю цепочку появилась на сайте, требовалось от получаса до часа. Такие сценарии были автоматизированы, так как ручное тестирование было бы неэффективно.

Дополнительные ресурсы

Скидка на курсы

Доступна скидка 20% на курсы по подготовке к собеседованиям (код скидки может быть указан отдельно).

Сообщество

Telegram канал ProTesting Info - уведомления о новых вебинарах, скидках и бонусах
Сайт protestinginfo.ru - полная информация о программе курсов и отзывы студентов

Что включено в курсы

Разбор технических вопросов на собеседованиях
Практические задания
Ревью резюме
Доступ к материалам на 6 месяцев
Без ограничения по потокам (смотрите в удобное время)

Ежемесячные интерактивные встречи

Проводятся встречи для разбора актуальных вопросов и практических примеров (например, работа с OpenSearch, логированием и мониторингом).

Резюме

На собеседовании для QA специалиста важно:

Показать рассуждение - не просто дать ответ, а объяснить логику
Демонстрировать опыт - ссылаться на реальные проекты или практические примеры
Проговаривать действия - объяснять, как вы будете тестировать, на что обратите внимание, куда смотреть
Быть готовым к уточнениям - интервьюер может задавать дополнительные вопросы для глубокого погружения
Предлагать улучшения - не только находить проблемы, но и предлагать решения

Помните, что на собеседовании нет неправильных ответов на ситуационные вопросы. Ценится ваша способность думать критически, анализировать и рассуждать логически.

Дополнительная информация

Анализ формы авторизации

Проверка: Статус-коды HTTP

Автор правильно указывает использование кодов 400, 401, 403, 412 и 429.

401 Unauthorized - используется для всех случаев, когда аутентификация не пройдена (неверный логин или пароль)
403 Forbidden - означает, что пользователь аутентифицирован, но не имеет прав доступа к ресурсу (не подходит для авторизации с неверным паролем)
400 Bad Request - может использоваться, если форма данных некорректна
429 Too Many Requests - корректно используется для защиты от перебора

Уточнение: В реальных приложениях для повышения безопасности часто всегда возвращают 200 OK, даже при ошибках авторизации, и передают информацию об ошибке в теле ответа. Это предотвращает раскрытие информации о существовании аккаунта.

Проверка: Хеширование паролей

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

Дополнение: Важно также знать о солях (salt) - случайные данные, добавляемые к паролю перед хешированием, для повышения безопасности. Это предотвращает использование радужных таблиц для подбора паролей.

SQL и Декартово произведение

Проверка: Математика корректна

Декартово произведение действительно является произведением количеств строк.

Дополнение: Важно различать:

CROSS JOIN или SELECT * FROM a, b - явное и неявное декартово произведение
INNER JOIN с условием - результат меньше декартова произведения, так как строки фильтруются по условию
LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN - другие типы соединений с разными результатами

JSON и валидация в системах доставки

JSON валидацию - проверка синтаксиса и структуры
Бизнес-логику валидацию - проверка соответствия данных реальному миру

Это важное различие, которое часто упускается новичками.

Дополнение по UUID:

UUID имеет формат 36 символов с дефисами (или 32 без дефисов)
Используется для глобальной уникальности без координации между системами
Предпочтительнее числовых ID по соображениям безопасности (сложнее предсказать следующий ID)

Важное замечание: Для адреса доставки было бы полезно добавить:

Квартира / офис / этаж - для детализации адреса
Дополнительные инструкции - для курьера (например, как попасть в дом)
Контактный номер телефона - для связи с получателем
Временное окно доставки - с какого по какое время курьер может приехать

Kafka и интеграционное тестирование

Топики и партиции Kafka
Consumer groups - группы потребителей, которые читают сообщения
Offset - позиция в журнале сообщений
Основные риски - потеря, дублирование, нарушение порядка

Дополнение важных концепций:

Idempotency (Идемпотентность) - система должна безопасно обрабатывать дубликаты сообщений, возвращая одинаковый результат
At-least-once delivery - Kafka гарантирует, что сообщение будет доставлено как минимум один раз (может быть более одного раза)
At-most-once delivery - сообщение доставляется максимум один раз (может быть потеряно)
Exactly-once semantics - достигается через комбинацию механизмов и требует тщательного проектирования

Практическое уточнение: При тестировании Kafka не всегда нужно использовать Offset Explorer или AQHQ напрямую. На многих коммерческих проектах используется:

Логирование - все события логируются, и анализ происходит в Kibana / OpenSearch
Мониторинг - метрики через Prometheus, Grafana
API тестирование - проверка через REST API того же приложения
Автоматизация - end-to-end тесты, которые проверяют всю цепочку программно