Собеседование на ручного тестировщика (Middle QA) | Выпуск 2

Коротко о видео

Публичное тестовое (мок) собеседование кандидата Алексея на уровень Middle QA: он рассказывает о примерно годе работы на страховом микросервисном проекте, а интервьюер уточняет его практический опыт. Основная часть посвящена работе QA с требованиями, тест-дизайну, чек-листам и тест-кейсам, включая критерии качества, ревью, предусловия, ожидаемые результаты и формулировки шагов. В конце обсуждаются тестирование микросервисов, Kafka, Jaeger, основы PostgreSQL и JOIN, после чего кандидат устно разбирает SQL-задачу о договорах.

Затронутые темы

Что взять на заметку

• QA стоит подключаться уже на grooming и анализе требований: неясности и «серые зоны» лучше обсуждать с аналитиком до реализации и подготовки тестов.
• Кандидат использует классы эквивалентности и граничные значения; попарное тестирование и таблицы принятия решений, по его словам, применяются реже.
• Чек-лист без ожидаемого результата может заставлять исполнителя возвращаться к спецификации. Интервьюер рекомендует включать ожидаемый результат прямо в название проверки, например через условие и успешный исход.
• Тест-кейс должен позволять новому сотруднику выполнить проверку без постоянных уточнений: нужны понятное название, достаточные предусловия, воспроизводимые шаги и ожидаемые результаты.
• При ревью тест-кейсов проверяют логичность шагов, полноту покрытия функциональной логики и отсутствие неописанных настроек или возврата системы в исходное состояние.
• Для диагностики межсервисных ошибок кандидат описывает просмотр трасс в Jaeger, проверку сообщений Kafka и изменений в базе данных; если трассировки недостаточно, он обращается к разработчикам.
• В SQL-практике интервьюер акцентирует, что открытость договора нужно определять по отсутствию даты закрытия и отличать NULL от пустой строки; это было разбором задачи, а не подтверждённым готовым решением кандидата.