Стратегия тестирования проекта
Вопрос
Ты приходишь в проект без тестов. Как выстроишь стратегию тестирования?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
несколько e2e smoke-тестов на критичные пути
unit-тесты на чистую логику: расчёты, форматирование, утилиты
интеграционные тесты компонентов и API на новых и изменяемых местах
тесты в CI как обязательная проверка PR
регрессионный тест на каждый найденный баг, борьба с флаки
Что могут спросить следом
- Как убедить команду и бизнес выделить на это время?
- Нужна ли цель по покрытию?
- Как бороться с медленным тестовым набором?
Разбор
Писать тесты на всё сразу бессмысленно, поэтому иду от риска. Сначала договариваюсь, какие сценарии критичны: вход, оплата, создание заказа. На них делаю несколько e2e smoke-тестов в Playwright, чтобы сразу ловить поломки главного. Параллельно покрываю unit-тестами чистую логику, где ошибки дорогие и тесты дешёвые: расчёт цен, валидацию, форматирование. Дальше правило для команды: новый или изменённый код приходит с интеграционными тестами, каждый баг закрывается регрессионным тестом. Всё запускается в CI как обязательная проверка PR, иначе тесты быстро устареют. Цель по покрытию ставлю мягкую, как ориентир, а не KPI. Слежу за скоростью набора и флаки-тестами: ненадёжный тест хуже его отсутствия, потому что его перестают слушать.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.