Automation QA - Собеседование на микросервисный проект (часть 1)

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

Первая часть пробного мок-интервью Automation QA для микросервисного проекта. Кандидат рассказывает о примерно годе в автоматизации, опыте API- и UI-автотестов на Java с Selenide и REST Assured, создании фреймворка и запуске регресса через Jenkins. Затем интервьюер последовательно проверяет понимание регрессионной отчётности, дефектов, пирамиды тестирования, техник тест-дизайна, Page Object Model и выбора CSS/XPath-локаторов.

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

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

• Для рассказа о проекте важно отделять личный вклад от командного: кандидат описывает перевод ручных сценариев в автотесты, создание фреймворка с нуля и настройку Jenkins-джоб.
• При ответе про API-тестирование нужно назвать источник контракта (например, Swagger), проверку request/response, статус-кодов и соответствия спецификации.
• Обсуждение дефектов включает проверку, является ли падение ошибкой теста или системы, оценку влияния на бизнес и решение о допустимости релиза; кандидат относит первичную установку priority/severity к тестировщику, а решение по приоритетам в команде — к Product Owner.
• Пирамида тестирования разбирается через число, скорость, стоимость и область проверки тестов: unit/компонентные тесты проверяют изолированные части, интеграционные — взаимодействие модулей, end-to-end — полный пользовательский сценарий.
• Для формы логина обсуждаются позитивные и негативные проверки, классы эквивалентности, граничные значения и понятные сообщения об ошибках. При отсутствии требований следует проводить исследовательское тестирование, фиксировать текущее поведение и согласовывать спорные ожидания, а не объявлять дефектом любое непривычное сообщение.
• Для большой формы с множеством полей интервьюер ожидает применение таблиц решений и pairwise-тестирования, которое сокращает набор комбинаций по сравнению с полным перебором.
• В UI-автоматизации Page Object Model должен хранить элементы и методы работы с ними, а общие header/footer и блок авторизации стоит выносить в переиспользуемые компоненты; предпочтительны стабильные семантические CSS-локаторы, XPath рассматривается как более широкий запасной инструмент.