Как происходило тестирование: своими силами или с использованием более жестких тестов

Что проверяют

Как на вашем проекте было устроено качество: полагались ли разработчики на ручную проверку «на глаз» или была система автотестов и проверок в CI. Следом обычно просят рассказать про конкретный тест, который поймал баг, или про то, что вы сознательно не тестируете.

Как отвечать

Опишите реальную картину, а не идеальную пирамиду из учебника. Удобный каркас по уровням:

• статические проверки: TypeScript в режиме strict, ESLint, tsc --noEmit в CI. Самый дешёвый слой, который отсекает целый класс ошибок;
• юнит-тесты: Vitest или Jest для утилит, хуков, редьюсеров, форматирования данных;
• компонентные тесты: Testing Library и проверка поведения глазами пользователя: что видно на экране, что происходит по клику. Запросы подменяются через MSW;
• e2e: Playwright или Cypress на критических сценариях вроде входа, оплаты, оформления заказа. Их мало, потому что они медленные и чаще других бывают нестабильными;
• визуальная регрессия: скриншотные тесты в Storybook или Playwright, если важна вёрстка дизайн-системы;
• люди: код-ревью, отдельные QA или проверка разработчиком перед мержем, приёмка на стенде.

Объясните, кто за что отвечал и что блокировало мерж: например, красный CI не давал влить ветку. Если тестов было мало, скажите честно и расскажите, что добавили бы первым. Обычно это тесты на логику, где уже случались баги, и пара e2e на ключевой путь пользователя. Цифры покрытия и числа багов называйте только свои.

Где спотыкаются

Называют процент покрытия главным показателем. Покрытие в 90% ничего не говорит, если тесты проверяют рендер, но не поведение.

Тестируют детали реализации: внутренний state, имена классов, вызовы приватных функций. Такие тесты ломаются от любого рефакторинга и при этом ничего не ловят.

Пытаются закрыть всё через e2e. Набор разрастается, прогон идёт полчаса, тесты падают случайно, и команда перестаёт им доверять.