Собеседование QA: вопросы junior, middle и тренировка с ИИ

Чем отличаются severity и priority?

Что должно быть в сильном ответе:Severity показывает, насколько сильно баг влияет на систему, а priority — насколько срочно его нужно исправить с точки зрения бизнеса. Они выставляются независимо: опечатка в названии компании на главной — низкая severity, но высокий priority, а падение редко используемого отчёта в админке может иметь высокую severity и более низкий priority. Стоит добавить, что severity обычно ставит QA, а последнее слово по priority часто за PM или лидом.

В чём разница между smoke, sanity и regression тестированием?

Что должно быть в сильном ответе:Smoke — быстрая поверхностная проверка, пригоден ли новый билд к тестированию вообще: приложение запускается, логин работает, ключевые страницы открываются. Sanity — узкая проверка, что конкретный фикс или изменение работает как нужно. Regression проверяет, что старый функционал не сломался после изменений, и именно его чаще всего автоматизируют, потому что он повторяется каждый релиз.

Как применить анализ граничных значений к полю, которое принимает возраст от 18 до 60?

Что должно быть в сильном ответе:Сначала делим входные данные на классы эквивалентности: меньше 18, от 18 до 60, больше 60, плюс невалидные значения вроде букв или пустого поля. Затем тестируем границы, где баги встречаются чаще всего: 17, 18, 60 и 61, а для трёхточечного варианта ещё 19 и 59. Так несколькими test cases получаем хорошее покрытие вместо проверки каждого числа.

Что должен содержать хороший bug report?

Что должно быть в сильном ответе:Короткий и конкретный заголовок, чёткие шаги воспроизведения, ожидаемый и фактический результат и окружение: версия билда, браузер или устройство, ОС, тестовые данные. Приложите доказательства — скриншот, видео, логи или падающий запрос к API — и выставьте severity. Простой критерий: другой человек должен воспроизвести баг, ничего у вас не переспрашивая.

Чем верификация отличается от валидации?

Что должно быть в сильном ответе:Верификация отвечает на вопрос «правильно ли мы делаем продукт?»: проверяем соответствие требованиям и спецификациям, например через ревью требований, дизайна и кода. Валидация — «тот ли продукт мы делаем?»: проверяем, что результат действительно закрывает потребности пользователя, обычно тестируя работающее ПО. Коротко: верификация — против спецификации, валидация — против потребностей пользователя.

Какие HTTP-методы идемпотентны и почему это важно для тестирования API?

Что должно быть в сильном ответе:GET, PUT, DELETE, HEAD и OPTIONS идемпотентны: повторный одинаковый запрос оставляет сервер в том же состоянии. POST не идемпотентен, PATCH — не гарантированно. На практике QA отправляет одинаковый PUT или DELETE дважды и проверяет, что ничего лишнего не произошло, а для POST проверяет, как API обрабатывает дубликаты, например через idempotency key или уникальное ограничение в базе.

Чем отличаются статус-коды 401 и 403 и как вы тестируете авторизацию?

Что должно быть в сильном ответе:401 Unauthorized означает, что запрос не аутентифицирован: токена нет, он просрочен или сломан. 403 Forbidden — пользователь аутентифицирован, но у него нет прав на этот ресурс. Для проверки вызываем каждый эндпоинт без токена, с просроченным токеном и с токеном пользователя с другой ролью, а также проверяем, что, подменив ID, нельзя прочитать или изменить чужие данные.

В чём разница между INNER JOIN и LEFT JOIN и когда это нужно QA?

Что должно быть в сильном ответе:INNER JOIN возвращает только строки, у которых есть совпадение в обеих таблицах, LEFT JOIN — все строки левой таблицы, а где совпадения справа нет, подставляет NULL. QA часто использует LEFT JOIN с условием WHERE правая_таблица.id IS NULL, чтобы найти «осиротевшие» или отсутствующие данные: пользователей без профиля или заказы без оплаты. Это типичный способ проверить целостность данных после миграции или изменений на бэкенде.

Из-за чего появляются flaky-тесты и как с ними бороться?

Что должно быть в сильном ответе:Типичные причины: проблемы с таймингами и жёсткие sleep, общие или «грязные» тестовые данные, зависимость от порядка тестов, нестабильное окружение или сторонние сервисы, хрупкие локаторы. Лечить нужно причину: явные ожидания или auto-waiting, изолированные данные для каждого теста, моки для нестабильных зависимостей, стабильные локаторы вроде data-testid. Retries в CI уменьшают шум, но flaky-тесты нужно отслеживать и выносить в карантин, а не молча перезапускать.

Что такое Page Object Model и какие у него минусы?

Что должно быть в сильном ответе:Page Object Model выносит локаторы и действия со страницей в отдельные классы, поэтому тесты читаются как бизнес-шаги, а изменение UI исправляется в одном месте, а не в каждом тесте. Минусы: раздутые «god»-объекты, проверки, протекающие в page-классы, и лишние слои для простых страниц. Сильный ответ упоминает, что assertions должны оставаться в тестах, повторяющиеся компоненты стоит выносить отдельно, а в Playwright и Cypress часто используют более лёгкие подходы — fixtures или custom commands.

Как вы построите тест-стратегию для нового продукта с нуля?

Что должно быть в сильном ответе:Начать с рисков и бизнес-приоритетов: какие флоу приносят деньги или сильнее всего навредят пользователям, если сломаются. Дальше определить уровни тестирования и баланс между unit, API и UI-тестами, окружения и тестовые данные, критерии входа и выхода, а также что запускается в CI на каждое изменение, а что — перед релизом. Стоит объяснить, как вы согласуете это с разработчиками и продактом и как измерять результат, например по багам с продакшна и времени обратной связи от тестов.

Как вы решаете, что автоматизировать, а что оставить ручным?

Что должно быть в сильном ответе:Автоматизируем то, что часто повторяется, стабильно, критично для бизнеса и имеет чёткий ожидаемый результат: regression, smoke, контракты API, сценарии с большим объёмом данных. Ручными остаются exploratory, юзабилити, разовые проверки и фичи, чей UI меняется каждый спринт. И ещё — опускать проверки ниже по пирамиде: если что-то можно проверить unit- или API-тестом, не стоит покрывать это медленным end-to-end тестом через UI.

Ваш end-to-end набор идёт в CI 90 минут. Как его ускорить?

Что должно быть в сильном ответе:Сначала измерить: найти самые медленные и чаще всего красные тесты и убрать дубли того, что уже покрыто на уровне API или unit. Затем запускать тесты параллельно с изолированными данными, готовить состояние через API или сидинг базы вместо кликов в UI, переиспользовать состояние авторизации. И наконец разделить пайплайн: быстрый smoke-набор на каждый pull request, полная регрессия — ночью или перед релизом.

Как вы будете тестировать REST API, от которого зависят другие команды?

Что должно быть в сильном ответе:Покрыть функциональные и негативные кейсы, валидацию, авторизацию по ролям и формат ошибок. Контракт защитить проверкой схемы или consumer-driven contract тестами, например Pact, чтобы ломающее изменение падало в CI ещё до того, как дойдёт до других команд. Добавить проверки обратной совместимости и версионирования, а также базовые performance-тесты ключевых эндпоинтов.

Какие QA-метрики вы считаете полезными, а каких избегаете?

Что должно быть в сильном ответе:Полезны те, что показывают качество продукта и скорость команды: баги, дошедшие до продакшна, время от коммита до результата тестов, доля flaky-тестов и покрытие критичных пользовательских сценариев. Сырые числа вроде количества test cases или найденных багов на тестировщика легко «накрутить», и о качестве они говорят мало. Сильный ответ объясняет, что метрики должны помогать принимать решения, например какую зону докрыть тестами, а не ранжировать людей.