Культура тестирования в команде
↑ 9.1 Team Lead и soft skills · ← Предыдущая · → Следующая
Зачем это на собесе
Качество проектируют вместе с фичей; лид отвечает за процесс, а не только за инструменты.
Принципы
- тесты — часть определения готовности, а не отдельный этап;
- пирамида (баланс unit / component / integration / E2E) по риску;
- ответственность у всей команды, а не только у QA;
- быстрая обратная связь: локально и в CI за минуты;
- нестабильные тесты — приоритетный долг.
Как внедрять
- Стартовая диагностика: покрытие критических путей, скорость, стабильность.
- Стандарт: инструменты (Vitest, Testing Library, Playwright), шаблоны тестов, именование.
- Правило: новый код и исправление бага — с тестами (regression test на каждый баг).
- CI-гейты: обязательные тесты и линт для merge, порог покрытия нового кода.
- Обучение: воркшопы, парное написание, примеры хороших тестов.
- Метрики: доля flaky, время прогона, escaped defects (баги в проде), покрытие критических сценариев.
Практики
- тест-ревью вместе с кодом;
- test data factories, MSW для API;
- контрактные тесты с бэкендом;
- «тестовые пятницы» и уборка flaky;
- инциденты → тест на регрессию → постмортем.
Сопротивление
| Возражение | Ответ |
|---|---|
| «Нет времени» | тесты сокращают отладку и регрессии, показать данные |
| «Тесты хрупкие» | тестируем поведение, не реализацию |
| «Это работа QA» | качество — общая ответственность, QA помогает со стратегией |
| «Слишком медленно» | пирамида, параллелизм, шардинг |
Не путать с метрикой
Покрытие не цель. Оценивайте по предотвращённым регрессиям и уверенности при релизах.
Вопросы с ответами
Как начать вводить тесты в проекте без тестов?
Покрыть критические пути E2E-смоуком, тесты на каждый новый баг и на новый код, постепенно добавлять компонентные и unit-тесты в модулях, которые часто меняются.
Как бороться с flaky-тестами?
Отслеживать долю нестабильных, находить причину (асинхронность, данные, окружение), исправлять или удалять, не оставлять «зелёными повторами».