Вопросы на собеседовании: QA-инженер

API должен выдерживать 600 RPS в течение 10 минут при p95 не более 400 мс, p99 не более 800 мс и доле ошибок ниже 1%. Базовая итерация k6 занимает 1,2 секунды. Как настроить и принять тест с открытой моделью поступления запросов?

Распределенный тест JMeter должен создать 12 000 RPS. Один генератор стабильно выдает 1 800 RPS при CPU 65%, средний ответ занимает 8 КБ, а обязательный запас генератора равен 25%. Сколько генераторов нужно и как проверить схему?

Нужно создать 15 000 HTTP RPS и 500 постоянных WebSocket-сессий в 10-минутной CI-задаче; JavaScript знают 4 из 6 инженеров, Python знает 1, Java знает 1, а генератор ограничен 1 ГБ памяти. Что выбрать: k6, JMeter, Gatling или Locust, и какими данными подтвердить выбор?

Кандидат в релиз выдает 2 400 RPS в течение 15 минут при p95 280 мс, p99 760 мс и 0,2% ошибок. SLO на 2 200 RPS требует p95 не более 300 мс, p99 не более 700 мс и менее 0,5% ошибок. Можно ли одобрить релиз?

Промышленный трафик состоит из 70% горячих чтений из кэша, 20% чтений теплых ключей с одним промахом за тест и 10% уникальных холодных чтений. Как построить 10-минутный тест на 5 000 RPS без нереалистично высокой доли попаданий в кэш?

Обычная нагрузка равна 1 000 RPS, рекламная кампания может поднять ее до 5 000 RPS на 60 секунд, а предел мощности неизвестен. Какие spike- и stress-тесты провести и какое численное решение даст каждый из них?

Спроектируйте 18-часовой soak-тест на 1 500 RPS для сервиса, который после прогрева использует 4,2 ГБ памяти, имеет p95 300 мс и 400 открытых соединений. Какие пороги наклона определят успех или провал?

Закрытый тест использует 200 пользователей и показывает p95 900 мс при 200 RPS, но требование равно 1 000 RPS, а ответ может замедляться до 2 секунд. Валиден ли результат и как устранить coordinated omission?

Три генератора обработали 1 миллион, 3 миллиона и 6 миллионов запросов и сообщили p95 100 мс, 200 мс и 400 мс. Можно ли принять SLO p95 300 мс, усреднив эти процентили?

Тестовая среда имеет четверть вычислительной мощности промышленной и выдерживает 450 RPS при p95 250 мс; промышленная среда должна поддерживать 1 500 RPS, а CI дает 5 минут на pull request и 30 минут по расписанию. Как использовать малую среду и построить два уровня тестирования?

Пайплайн pull request обрабатывает 120 изменений в день: сборка артефакта занимает 2 минуты, 6 000 unit-тестов идут 3 минуты, 600 выбранных component-тестов 6 минут, contract-тесты 4 минуты, а 30 браузерных smoke-тестов требуют 8 минут после двухминутного деплоя. Как построить DAG с p95 ниже 13 минут и не тратить ресурсы зря, если 18% изменений падают?

Регрессионный набор потребляет 960 раннер-минут, CI-платформа разрешает 100 воркеров, а требуемое время p95 равно 12 минутам. Как вы спроектируете сбалансированные по длительности шарды?

В пиковый час в merge queue поступают 40 одобренных пул-реквестов, проверочный набор занимает 15 минут, доступны только четыре изолированных окружения, а 4 процента изменений падают. Как удержать p95 ожидания в очереди ниже 35 минут?

В монорепозитории 200 сервисов и 25 000 тестов; полный набор занимает 180 минут, но обратная связь по пул-реквесту должна укладываться в 15 минут. Как применить отбор по графу зависимостей и не потерять полную подстраховку?

Вы создаёте 180 эфемерных тестовых окружений в день; запуск каждого сейчас занимает 12 минут, тесты идут 35 минут, затем окружение простаивает 60 минут, а стоимость равна $0,02 за минуту окружения. Как уложиться в $250 в день и запускать окружение не дольше 7 минут?

Сервис собирается 70 раз в день, каждая сборка занимает 8 минут, а повторная сборка между тестами пул-реквеста, staging и релиза дала 0,8 процента несовпадений бинарных файлов. Как вы спроектируете тестирование неизменяемого артефакта?

Пайплайн запускает 10 000 тестов с исторической долей успешного первого прогона 99,6 процента, линейным покрытием 82 процента и целевым временем 20 минут. Какие числовые quality gates вы зададите, чтобы общие проценты не скрывали плохое изменение?

Каждому из 40 интеграционных шардов нужны приложение, PostgreSQL, Redis и Kafka; тестовый кластер Kubernetes допускает 60 подов, каждый шард занимает 6 минут, а бюджет пайплайна равен 18 минутам. Как вы разместите зависимости?

Монорепозиторий запускает 12 000 тестов для 120 pull request в день; 70% тестов герметичны, каждый в среднем занимает 30 секунд, а CI должен сократить runner-минуты на 50% без повторного использования результата после изменения любого значимого входа. Как спроектировать кеш результатов тестов?

CI выполняет 50 000 тестов в день и выдаёт 1 500 падений примерно из 120 первопричин, но инженеры должны получать правильного владельца и доказательства не позднее 15 минут. Как вы спроектируете наблюдаемость результатов и маршрутизацию?

Три сервиса публикуют 48 REST-операций, в CI есть лимит на 240 контрактных тестов, но написанные вручную моки регулярно расходятся с файлами OpenAPI. Как построить измеримую архитектуру тестирования OpenAPI?

У tenant API есть 12 защищенных эндпоинтов, 3 роли, 3 состояния учетных данных (валидные, просроченные, отсутствующие) и 2 цели (свой tenant, чужой tenant). Как реализовать матрицу авторизации 12 × 3 × 3 × 2 = 216 и негативные проверки payload, не скрывая дефекты авторизации?

Одного провайдера используют 14 приложений в системе из 18 сервисов, причем у каждого потребителя может быть 3 активные версии. Как применить Pact Broker и can-i-deploy, чтобы не выпустить несовместимую версию провайдера или потребителя?

У REST API v1 есть 27 активных клиентов во время перехода на v2, а платформа публикует 8 типов Kafka-событий, потребители которых могут отставать на 2 релиза при хранении трафика за 14 дней. Как тестировать обратную совместимость синхронных и асинхронных контрактов?

Набор содержит 600 тестов для 15 таблиц, фабричные данные не охватывают production-сегмент с 18% пустых профилей, в production есть 4,2 миллиона строк, а копирование сырых production-данных запрещено. Как совместить фабрики и анонимизированные данные production-формы?

Нужно маскировать 2,4 миллиона записей в 6 связанных таблицах блоками по 50 000 строк, сохранив связи, уникальность, форматы и одинаковый результат повторных запусков. Как реализовать и проверить детерминированное маскирование?

CI выполняет 60 прогонов в день с 8 параллельными workers, общие схемы и очереди конфликтуют, а тесту производительности нужно эксклюзивное окно на 45 минут со стабильной базой из 10 миллионов записей. Как разделить эфемерные и общие среды и гарантировать очистку?

Для одного релиза до выпуска нашли 120 валидных дефектов: S1=2, S2=8, S3=30, S4=80. За следующие 30 дней в production нашли 20 относящихся к релизу дефектов: S1=1, S2=3, S3=6, S4=10. При весах серьезности 8, 5, 2, 1 рассчитайте escape rate и определите release gate.

У 10 дефектов релиза время от обнаружения до финальной проверки в production составило 2, 3, 4, 5, 6, 8, 10, 12, 20 и 40 часов, причем 40-часовой дефект переоткрыли после первого закрытия. Как рассчитать перцентили defect MTTR и правильно сохранить жизненный цикл?

За 30 дней 120 тестов сначала упали, а затем прошли без изменения кода, при 20 000 выполнениях тестов; time-to-signal p50=7 и p90=18 минут; 6 из 80 production-изменений потребовали rollback или defect hotfix; взвешенный escape=11%; пройдено 4 960 из 5 000 контрактных проверок. Постройте сбалансированный dashboard с точными decision gates.

За последние 200 запусков CI красными были 28, из них 24 прошли при повторном запуске, а команда включила до 3 слепых повторов за 4 часа до релиза. Что вы сделаете?

Сценарий платежного callback в Playwright падает в 11 из 80 запусков: интерфейс иногда обновляется за 2,1 секунды, а тест ждет фиксированные 2 секунды. До закрытия релизного окна осталось 90 минут. Что вы сделаете?

Двенадцать API-тестов проходят отдельно, но 9 падают при случайном порядке набора из 240 тестов; все 9 используют одну учетную запись клиента и оставляют разные состояния подписки. Что вы сделаете?

За 6 недель набор тестов для pull request вырос с 18 до 57 минут, лимит CI равен 35 минутам, а 14 из последних 40 сборок отменили до получения результата. Что вы сделаете?

Запуск CI с 8 шардами завершается за 34 минуты: один шард работает 31 минуту, самый быстрый 7 минут, а 46 тяжелых спецификаций распределены только по количеству файлов. Что вы сделаете?

После релиза интерфейса падают 168 из 420 тестов Playwright из-за смены сгенерированных CSS-классов, но ручная проверка 25 критичных действий не находит дефектов продукта. Что вы сделаете?

Релиз checkout изменил поток с 3 шагов на 2, и теперь 96 из 150 сценариев Cypress падают на удаленной странице подтверждения за 70 минут до конца релизной проверки. Что вы сделаете?

Автоматическое обновление Chrome приводит к ошибке запуска сессии в 73% из 600 тестов Selenium; Firefox остается зеленым, а до релиза 2 часа. Что вы сделаете?

Сервис тестовых артефактов отвечает 503 для 100% заданий, за последние 90 минут заблокированы 62 запуска CI, а решение о релизе нужно принять через 60 минут. Что вы сделаете?

За 45 минут до релиза падают 9 из 1800 тестов: 7 совпадают с известными сигнатурами нестабильности, а 2 новых сбоя затрагивают сброс пароля и итоговую сумму счета. Бизнес просит общее исключение. Что вы сделаете?

Релиз 8.14 показывает неверную дату продления 18 400 пользователям; 620 продлений завершились ошибкой, а до отката поддержка получила 73 обращения. Что вы сделаете за первые 24 часа и как предотвратите такой же пропуск?

Повтор платежного вебхука в релизе 5.6 дважды списал деньги у 214 клиентов в 286 транзакциях, хотя все 340 автоматизированных платежных тестов прошли. Как вы отреагируете и измените систему тестирования?

Инцидент INC-417 заблокировал вход 3 200 пользователям после сброса пароля, хотя покрытие аутентификации составляло 91%. Какие данные вы соберете и какие 1 или 2 исправления выберете?

Доля дефектов, дошедших до прода, выросла с 1,8% до 3,1%, 4,7% и 6,2% в релизах 21-24, а частота осталась 2 релиза в неделю. Как вы исследуете и развернете тренд?

Критический сценарий выплат был зеленым в 126 тестах из-за мока банка, но в проде банк отклонил 9% из 4 800 выплат после изменения поведения тайм-аутов. Что вы измените?

Релиз 3.9 прошел стенд, но 41% из 12 000 загрузок в проде завершились ошибкой, потому что стенд использовал хранилище версии 7.2, а прод версии 6.8. Как вы восстановите сервис и закроете разрыв окружений?

После API v32 17% из 90 000 загрузок мобильных профилей завершились ошибкой, потому что сервис вернул null для поля, объявленного обязательной строкой. Почему тесты это пропустили и что вы внедрите?

Задержка поиска p95 выросла с 480 мс до 2,4 секунды в релизе 11.3 и затронула 1,6 млн запросов до обнаружения, хотя набор производительности оставался зеленым. Как вы диагностируете проблему и предотвратите повтор?

Экспорт счетов повредил 6 700 из 240 000 записей с именами не на латинице и отрицательными корректировками, хотя 58 тестов экспорта прошли. Как вы сверите данные и устраните слепую зону?

Релиз 6.2 сделал кнопку оплаты невидимой при масштабе 200% и удалил ее доступное имя, затронув примерно 14 000 сессий клавиатурных и слабовидящих пользователей до поступления 96 обращений. Что вы сделаете дальше?

Нагрузочный тест выдержал 12 000 запросов в секунду при p99 180 мс, но в продакшене p99 достиг 2,4 секунды всего при 3 000 запросов в секунду. В тесте было 90% кешированных чтений, а в продакшене 45% трафика составляют записи и есть несколько горячих аккаунтов. Что вы решите и измените?

При 8 000 виртуальных пользователей процессор генератора нагрузки загружен на 100%, а сеть на 95%, тогда как сервис использует 42% процессора; пропускная способность перестает расти, а время ответа выглядит стабильным. Как вы поступите с таким результатом?

Проверка производительности отклоняет сборки при p95 выше 450 мс, но 10 прогонов неизменной базовой версии дают от 410 до 470 мс, и 3 из них не проходят. Один прогон новой сборки показал 455 мс. Какое корректирующее решение вы примете?

Все 38 потребительских контрактов Pact проходят, но релиз провайдера вызывает ответы HTTP 400 для 17% запросов оформления заказа, потому что разрешенное матчером поле в продакшене равно null. Что вы сделаете помимо повторного запуска Pact?

Песочница платежного провайдера принимает запросы API v2 за 300 мс, но продакшен уже перешел на v3, отклоняет 12% таких запросов и доставляет вебхуки через 8 минут вместо 10 секунд. Как вы отреагируете?

Шесть команд используют одно тестовое окружение; полный набор тестов нестабилен в 14% прогонов, а сбои коррелируют с параллельными запусками, которые повторно используют идентификаторы аккаунтов и оставляют 30 000 записей. Каково ваше немедленное и долгосрочное решение?

Эфемерные тестовые окружения должны удаляться через 6 часов, но инвентаризация показывает 312 активных окружений, 47 из них старше 72 часов, а месячные расходы выросли с 4 000 до 18 000 долларов. Что вы предпримете?

Тест на 10 миллионах равномерно распределенных строк показывает p99 запроса 90 мс, но в продакшене он равен 1,8 секунды, потому что на самый активный 1% арендаторов приходится 64% строк. Что вы измените перед одобрением оптимизации?

Миграция прошла на 2 миллионах строк в стейджинге, но в продакшене 240 миллионов строк и 7% устаревших значений null; бэкфилл удерживает блокировки 11 минут, а отставание очереди достигает 25 минут. Что вы решите?

В релизе есть 12 функциональных флагов, но тесты покрыли только состояния все выключено и все включено; сочетание флагов A и D, региона ЕС и клиента ниже версии 5.4 вызывает повторные платежи у 9% этой группы. Как вы отреагируете?

За 3 часа до релиза падают 27 из 1 800 автотестов в 6 группах, а тестовая среда показывает повышенное число ошибок базы данных. Как вы отделите дефекты продукта от нестабильных тестов и сбоев среды и примете решение о релизе?

Известный дефект приводит к исчезновению сохранённых фильтров примерно у 7% из 120 000 активных пользователей в месяц, но данные не теряются навсегда, а обходной путь занимает около 20 секунд. Выпустите ли вы релиз через 4 часа?

Из-за задержки сборки окно тестирования сокращено с 18 до 6 часов, при этом есть 420 регрессионных сценариев и 4 тестировщика. Как вы сохраните обоснованность решения о релизе?

За 90 минут до запуска руководитель просит обойти критерий в 98% успешных критических тестов, потому что текущий результат равен 92% и падают 12 из 150 тестов. Что вы сделаете?

Во время инцидента, затронувшего 18% транзакций, хотфикс меняет 46 строк в логике повторных попыток оплаты, а команда хочет развернуть его в продакшене за 35 минут. Как вы оцените риск?

На встрече по решению о запуске 99,3% из 2 400 автотестов успешны и тестовый выпуск на 5% трафика не показывает ухудшения метрик, но исследовательское тестирование выявило 2 случая потери черновика в 40 попытках. Каково ваше решение?

За 2 часа до релиза прямое развёртывание проходит все 310 критических тестов, но никто не проверил откат миграции, затрагивающей 14 миллионов строк. Можно ли продолжать релиз?

За 1 день до релиза матрица совместимости заполнена, кроме Safari 16 на iOS 15, которым пользуются 11% активных пользователей, а изменённый сценарий загрузки принимает файлы до 25 МБ. Что вы решите?

За 5 часов до релиза сканер безопасности выдаёт 73 находки; 72 совпадают с шумным правилом для сгенерированных файлов, но 1 новая критическая находка с оценкой 9,8 может разрешать доступ к аккаунту без аутентификации. Как вы обработаете этот критерий?

Как вы проверите в продакшене новый сервис ранжирования поиска и ограничите риск, если обычный трафик равен 60 000 запросов в минуту, а откат занимает 4 минуты?

Джуниор отвечает за набор из 120 UI-тестов: в 38 используются фиксированные паузы от 2 до 5 секунд, в 64 используются абсолютные XPath-селекторы, а 18 падают минимум в 7 из 100 прогонов CI. Что должен сделать сеньор, как джуниор должен исправить и представить работу и какие числовые доказательства нужны перед одобрением?

QA уровня мидл задаёт для каждого нестабильного теста 3 повтора: теперь дашборд показывает итоговый pass rate 99,5%, но с первой попытки проходят только 91% тестов в 500 прогонах, а повтор нужен 46 тестам. Что должен сделать сеньор, как менти должен исправить и представить подход и какие числовые критерии выхода применить?

Менти отправляет 75 API-тестов, которые проверяют только статус 2xx и непустое тело ответа; мутационное тестирование оставляет незамеченными 23 дефекта контракта ответа или побочных эффектов. Что должен сделать сеньор, как менти должен усилить и представить набор и какие числовые проверки должны блокировать приёмку?

Менти моделирует нагрузку как 1 000 пользователей в цикле без пауз, хотя пик продакшена составляет 900 запросов в секунду при распределении 60% просмотра, 25% поиска, 10% обновления и 5% экспорта. Что должен сделать сеньор, как менти должен исправить и представить модель и какие числовые проверки должны её подтвердить?

Восемьдесят параллельных тестов используют общие 5 аккаунтов клиентов и один изменяемый заказ, из-за чего коллизии данных возникают в 14% прогонов. Что должен сделать сеньор, как менти должен перепроектировать и представить владение тестовыми данными и какие числовые проверки докажут изоляцию?

Менти открывает PR автоматизации на 4 800 строк в 37 файлах, который меняет раннер, политику повторов, отчётность и фикстуры, но не добавляет тестов самого фреймворка. Что должен сделать сеньор, как менти должен перестроить и представить изменение и какие числовые гейты применить?

Менти заводит баг с заголовком Checkout broken, одним скриншотом, без версии сборки, окружения и логов, хотя ошибка возникает в 3 из 10 попыток. Что должен сделать сеньор, как менти должен улучшить и представить отчёт и какие числовые доказательства сделают его готовым к триажу?

План запуска от менти содержит 210 happy path сценариев для платёжного сервиса с 25 000 транзакций в день, но упускает риски отката схемы, дублирующихся вебхуков и расхождения часов. Что должен сделать сеньор, как менти должен исправить и представить план и какие числовые критерии покажут достаточное покрытие рисков?

Дашборд менти заявляет 94% покрытия автоматизацией, считая выполненные сценарии относительно требований, но включает пропущенные и устаревшие тесты, тогда как актуальная автоматизированная проверка есть только у 52% из 40 критических пользовательских путей. Что должен сделать сеньор, как менти должен исправить и представить метрику и какая числовая проверка предотвратит повторение вводящего в заблуждение отчёта?

Инцидент в продакшене создаёт дублирующиеся возвраты для 1 800 заказов и риск потери 72 000 долларов, потому что менти не включил тест идемпотентности в релизный набор. Что должен сделать сеньор, как менти должен исправить и представить пробел и какие числовые проверки должны закрыть действие?