Проблема, с которой столкнулась команда, была классической: ручное тестирование ключевых сценариев перед каждым деплоем занимало два человеко-дня, при этом мелкие, но неприятные для пользователей баги (например, «поплывшая» верстка на определенном разрешении или неработающая кнопка в модальном окне) все равно проскальзывали в прод. Это приводило к горячим фиксам, подрывавшим доверие клиентов и увеличивавшим нагрузку на команду поддержки. Необходим был системный подход.
Первым шагом стал аудит и приоритизация. Вместо того чтобы пытаться покрыть тестами всё и сразу, мы совместно с продукт-менеджером и лидом поддержки выделили «золотой путь» (happy path) пользователя: регистрация, поиск услуги, добавление в корзину, оформление заказа и оплата. Именно эти сценарии приносили 80% дохода и были наиболее критичны. Также мы проанализировали историю инцидентов и выделили наиболее «хрупкие» компоненты интерфейса, которые чаще всего ломались при изменениях в коде — это были фильтры в каталоге и многошаговые формы.
Выбор инструментария пал на связку Playwright + TypeScript. Почему не Selenium или Cypress? Playwright предложил отличную скорость выполнения, встроенную поддерку нескольких браузеров (Chromium, Firefox, WebKit) «из коробки», а также мощные возможности для работы с сетевыми запросами и моками данных. TypeScript добавлял строгости и предотвращал множество ошибок на этапе написания тестов. Инфраструктура была развернута в отдельном репозитории, интегрированном с основным пайплайном CI/CD в GitLab.
Архитектура тестового набора была выстроена по принципу «пирамиды тестирования». В основании — множество unit-тестов для отдельных компонентов (на React Testing Library), которые писали сами разработчики. На уровне UI-тестирования мы создали три слоя:
- **Компонентные тесты (Component Tests):** С помощью Playwright Component Testing мы тестировали изолированные сложные UI-компоненты (те самые «хрупкие» фильтры и формы) с различными состояниями и пропсами.
- **Интеграционные E2E-тесты (End-to-End):** Ключевые пользовательские сценарии («золотой путь»). Здесь мы активно использовали моки API-ответов, чтобы тесты были быстрыми и не зависели от бэкенда. Например, для теста оплаты мы подменяли ответ платежного шлюза на успешный.
- **Регрессионные визуальные тесты (Visual Regression):** Для критичных с точки зрения дизайна страниц (лендинг, личный кабинет) мы настроили автоматический скриншот-тестинг. Playwright делал снимки в трех разрешениях и сравнивал их с эталонными образами в сервисе Percy, интегрированном в наш пайплайн. Это позволило отлавливать незапланированные изменения верстки.
* Ни один MR (Merge Request) не может быть смержен, если не проходят все unit-тесты и компонентные тесты, связанные с измененным кодом.
* Полный набор E2E-тестов запускается nightly на staging-окружении.
* Визуальные тесты запускаются перед релизом на прод. Любое расхождение требует ревью у дизайнера.
* Ответственность за падающий тест лежит на том, чей код привел к падению. Для этого мы настроили детальные алерты в Slack.
Результаты превзошли ожидания. Через 6 месяцев после внедрения:
* Количество регрессионных багов, дошедших до продакшена, сократилось на 92%.
* Время на ручное регрессионное тестирование перед релизом уменьшилось с 2 дней до 4 часов (только на проверку edge-кейсов).
* Уверенность команды при внесении изменений в legacy-код значительно возросла.
* Произошла неожиданная позитивная сторона: тесты стали живой документацией пользовательских сценариев, которую могли понять даже новые члены команды.
Ключевой вывод этого кейса: успешное UI-тестирование в продакшене — это не про написание тысяч тестов, а про стратегический выбор инструментов, фокус на бизнес-критичных сценариях и, самое главное, бесшовную интеграцию в культуру и процессы разработки. Это инвестиция, которая окупается спокойствием за стабильность продукта и сохранением нервов разработчиков и пользователей.
Комментарии (15)