Где тестировали проект?
Что проверяют
Есть ли у вас картина всего пути кода до пользователя: где он проверяется автоматически, где руками, на каких браузерах и устройствах. Следом обычно спрашивают, как баг всё-таки доехал до прода и что вы поменяли после этого.
Как отвечать
Отвечайте по окружениям, на своём проекте и с реальными инструментами. Каркас:
- локально: юнит-тесты на Vitest или Jest с Testing Library, моки API через MSW, Storybook для проверки состояний компонента в изоляции;
- CI на каждый пулл-реквест: линтер,
tsc --noEmit, юнит-тесты, e2e на Playwright или Cypress в headless-режиме. Playwright гоняет Chromium, Firefox и WebKit, что закрывает большую часть кроссбраузерности; - preview или stage: отдельный стенд на ветку или общий тестовый контур с бэкендом, где QA проверяет фичу руками и где ловятся проблемы интеграции;
- реальные устройства: iPhone и Android в руках или облачные фермы вроде BrowserStack, потому что эмуляция в DevTools не повторяет Safari на iOS;
- продакшн: Sentry или аналог для ошибок, фича-флаги и постепенная раскатка, чтобы новый код сначала видела часть пользователей.
Можно добавить визуальные регрессии через toHaveScreenshot в Playwright или Chromatic и замер производительности через Lighthouse CI.
Цифры и примеры берите свои: сколько e2e-сценариев, сколько длится прогон, какой баг поймали на stage. Если отдельного QA и стендов не было, так и скажите и объясните, как компенсировали: «стенда не было, поэтому покрыли e2e критичный сценарий оплаты и перед релизом проверяли на двух реальных телефонах».
Где спотыкаются
Называют устаревший стек. Enzyme не поддерживает актуальные версии React, и упоминание его как текущего инструмента сразу датирует опыт.
Отвечают «тестировали в Chrome». Интервьюер слышит, что Safari и мобильные браузеры не проверялись, а именно там всплывает много фронтенд-багов.
Приводят круглые проценты вроде «снизили баги на 30%» без базы сравнения. Сильнее звучит конкретный случай: что сломалось, на каком этапе поймали, что добавили в пайплайн.