Содержание11
- Зачем тестировать сайт, если «и так работает»
- Кто тестирует что: матрица ответственности
- Функциональность и вёрстка: что проверяем вручную
- Скорость и Core Web Vitals: пороги, которые проверяет Google
- SEO-аудит перед запуском: что нельзя исправить потом
- Интеграции: CRM, аналитика, рекламные пиксели
- Нагрузка, безопасность и юридическая проверка
- Сколько времени занимает тестирование: сроки по типам проектов
- Что делать с чек-листом дальше
- Частые вопросы
- Источники
Половина провалов запуска сайта — не в коде, а в том, что никто не проверил форму заявки на мобильном или забыл открыть индексацию в robots.txt. Этот чек-лист собирает всё, что веб-студия должна протестировать перед сдачей проекта: от вёрстки и скорости до CRM-интеграций и 152-ФЗ. С распределением ответственности — кто проверяет что.
Зачем тестировать сайт, если «и так работает»
Заказчик редко проверяет сайт так же придирчиво, как реальный пользователь. Он откроет главную, прокрутит до формы, увидит красивую картинку — и согласует. А через неделю выяснится, что кнопка «Заказать» на iPhone уезжает за экран, а заявка в CRM не попадает.
Типичный сценарий: форма отправляется, но письмо уходит в спам. Или уходит, но без номера телефона, потому что маска ввода не работает в Safari. Или работает, но создаёт дубль лида каждый раз, когда пользователь жмёт «Назад» в браузере. Каждый из этих багов — потерянная заявка, то есть прямые убытки заказчика.
Исправление после запуска обходится дороже. Команда уже разобрана на другие проекты, контекст утрачен, а правка в продакшене рискует сломать то, что работало. Плюс репутационные потери: заказчик не различает «баг» и «недоделку», для него это просто «сайт не работает».
Есть проекты, где заказчик действительно не заметит проблему месяцами. Но это не повод пропускать проверку: баг вылезет сам, но в самый неподходящий момент — во время рекламной кампании или перед отчётом инвесторам.
Кто тестирует что: матрица ответственности
Разработчик не должен быть единственным тестировщиком своего кода. Он знает, как должно работать, и не заметит, что интерфейс ведёт себя неочевидно. Нужно распределить проверки между четырьмя ролями: PM, frontend-разработчик, QA-инженер и заказчик.
| Блок проверки | PM | Frontend | QA | Заказчик |
|---|---|---|---|---|
| Функциональность, critical path | Контролирует | Выполняет | Проверяет | Принимает |
| Вёрстка, адаптивность, кроссбраузерность | — | Выполняет | Проверяет | — |
| SEO: метатеги, sitemap, robots.txt | Контролирует | Выполняет | — | — |
| Интеграции: CRM, аналитика, пиксели | Контролирует | Настраивает | Проверяет | Проверяет поступление данных |
| Нагрузка, безопасность, SSL | Контролирует | Выполняет | Проверяет | — |
| Юридика: 152-ФЗ, cookie-баннер | Контролирует | Реализует | — | Проверяет |
| Контент: тексты, изображения, цены | — | — | — | Выполняет |
| Приёмка, подписание акта | Организует | — | — | Выполняет |
PM отвечает за то, чтобы каждый блок был проверен, но не выполняет проверки сам. Заказчик проверяет только то, что знает лучше студии: соответствие контента договору, корректность цен, логику бизнес-процессов. Всё техническое — не его зона.
Выделенный QA нужен, когда проект сложнее одностраничного сайта с одной формой. Для лендинга хватит разработчика + PM. Для интернет-магазина с CRM, коллтрекингом и личным кабинетом — без QA не обойтись. В штате нет QA — берите на аутсорс на этап тестирования, это дешевле исправления багов в продакшене.
Функциональность и вёрстка: что проверяем вручную
Автоматические тесты проверяют, что код выполняется без ошибок. Но только человек заметит, что кнопка «Купить» перекрыта баннером на iPhone 12 или что форма не отправляется, если пользователь ввёл номер через «+7» вместо «8». Ручное функциональное тестирование включает кроссбраузерную проверку — убедиться, что сайт корректно отображается и работает в разных браузерах.
Critical path — главный сценарий конверсии. Для магазина это: главная -> категория -> карточка товара -> корзина -> оформление -> оплата -> подтверждение. Для адаптивного сайта услуг: главная -> услуга -> форма заявки -> отправка -> страница «Спасибо». Проверяйте весь путь от начала до конца, не по частям.
Формы — самое уязвимое место: - валидация каждого поля: пустое, некорректное, слишком длинное; - маски телефона: «+7», «8», скобки, пробелы, международный формат; - защита от дублирования: что произойдёт, если пользователь дважды нажмёт «Отправить»; - сообщения об ошибках: понятны ли они, указывают ли на конкретное поле.
Навигация и поиск: работают ли фильтры в сочетаниях, не ломается ли пагинация при сортировке, сохраняются ли параметры при возврате назад.
Кроссбраузерность — последние две версии Chrome, Safari, Firefox, Edge. Не все четыре на всех устройствах, а критический путь на каждом. Адаптивность — шесть контрольных точек:
- 320 px — старые iPhone SE, минимальная ширина
- 375 px — iPhone 14/15, основной мобильный трафик
- 768 px — планшеты, iPad mini
- 1024 px — iPad, ноутбуки в портретной ориентации
- 1440 px — стандартные мониторы
- 1920 px — широкоформатные экраны, проверка на «расползание»
Скорость и Core Web Vitals: пороги, которые проверяет Google
Google измеряет скорость через три метрики Core Web Vitals. Они влияют на ранжирование и на то, уйдёт ли пользователь, пока страница грузится.
| Метрика | Что измеряет | Порог «хорошо» | Типичная причина провала |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Время загрузки крупного элемента на экране | <= 2,5 секунды | Неоптимизированные изображения, тяжёлый hero-блок |
| INP (Interaction to Next Paint) | Задержка от клика до отклика интерфейса | <= 200 мс | Render-blocking JavaScript, тяжёлые скриптовые фреймворки |
| CLS (Cumulative Layout Shift) | Сдвиги вёрстки при загрузке | <= 0,1 | Шрифты без fallback, рекламные блоки без зарезервированного места |
Проверяйте в PageSpeed Insights, Lighthouse, WebPageTest, GTmetrix. Все четыре инструмента бесплатны с достаточными лимитами для проектной работы. PageSpeed Insights показывает данные из реального использования Chrome — это главный ориентир.
Большинство проверок делайте в мобильном режиме с эмуляцией 3G/4G. Десктопный интернет в офисе разработчика не отражает реальность пользователя. Особенно это касается лендингов с трафиком из рекламы: мобильный пользователь менее терпелив и меньше тратит трафика.
Типичные проблемы студийных сайтов: изображения в оригинальном разрешении, скрипты в <head> без defer, шрифты Google Fonts без предзагрузки. Всё это решается на этапе вёрстки, но ломает метрики, если забыть проверить.
SEO-аудит перед запуском: что нельзя исправить потом
Ошибки в SEO стоят не денег на исправление, а времени. Пока вы настраиваете robots.txt, конкуренты набирают возраст и ссылки. Проверяйте до запуска, потом будет поздно.
Особое внимание — robots.txt и sitemap. Ошибка в robots.txt может закрыть весь сайт от индексации на недели. Неправильный sitemap — отправить поисковик на 404-страницы или пропустить важные разделы.
Это проверяет разработчик при сборке, а не SEO-специалист «потом». Потом — значит через месяц, когда заказчик спросит, почему нет трафика.
Интеграции: CRM, аналитика, рекламные пиксели
Внешние сервисы должны работать с первого дня. Пиксель без настроенных целей — это слепая реклама: бюджет тратится, а вы не знаете, что купили.
| Тип интеграции | Что проверить | Как проверить | Кто отвечает |
|---|---|---|---|
| CRM (Битрикс24, amoCRM) | Поступление лида, правильность полей, статусы, дубли | Тестовая заявка с реальными данными, проверка в CRM | QA + заказчик |
| Аналитика (Яндекс.Метрика, GA4) | Цели, события, электронная коммерция, отсутствие дублей счётчиков | Просмотр в реальном времени, проверка событий в отладчике | QA |
| Коллтрекинг | Подмена номеров, динамический пул, привязка к источнику | Звонок с сайта, проверка в личном кабинете | QA |
| Чаты, обратные звонки | Инициализация, не перекрытие контента, работа на мобильном | Открытие на каждом breakpoint, проверка отправки сообщения | Frontend + QA |
| Рекламные пиксели (VK, Яндекс.Директ) | Фиксация конверсий, передача параметров | Тестовое событие, проверка в рекламном кабинете | QA |
CRM-интеграция проверяется вместе с SEO-аудитом: если форма не передаёт UTM-метки в лид, маркетинг не свяжет заявку с каналом. Проверяйте полный цикл: от клика по рекламе до появления лида в CRM с правильными метками.
Нагрузка, безопасность и юридическая проверка
Сайт может работать идеально при одном пользователе и падать при десяти одновременных заказах. Нагрузочное тестирование проверяет, какое количество запросов в секунду выдерживает хостинг. Core Web Vitals напрямую связаны с нагрузкой: если сервер не справляется, метрики скорости уходят в красную зону.
Проверьте RPS (requests per second) на типовом тарифе. Уточняйте лимиты у хостинг-провайдера, не полагайтесь на маркетинговые описания тарифов.
SSL-сертификат: валиден ли, настроен ли HSTS, работает ли принудительный редирект HTTP -> HTTPS. Проверьте все поддомены и www/без-www — частая ошибка, когда основной домен защищён, а поддомен нет.
Бэкапы: частота, место хранения, проверка восстановления. Резервная копия, которую никто не пробовал разворачивать, — это рулетка, а не страховка.
152-ФЗ требует политику конфиденциальности, если сайт собирает любые персональные данные: имя, телефон, email, IP-адрес. Проверьте: - страница политики доступна и связана с формами; - формы не отправляются без согласия; - данные не передаются третьим лицам без указания в политике.
Cookie-баннер нужен, если используете аналитику, пиксели, чаты — то есть почти всегда. Баннер должен давать возможность отказа, а не только «Согласен». Запись выбора пользователя хранится для возможной проверки.
Сколько времени занимает тестирование: сроки по типам проектов
| Тип проекта | Длительность тестирования | Кто участвует | Критичные проверки |
|---|---|---|---|
| Лендинг | от нескольких часов до дня | PM + frontend | Формы, адаптивность, пиксели, скорость |
| Сайт-визитка | от одного до нескольких дней | PM + frontend + QA | Все страницы, SEO, контактные формы |
| Каталог / корпоративный | от нескольких дней | PM + frontend + QA + заказчик | Фильтры, поиск, пагинация, интеграции |
| Интернет-магазин | от нескольких дней до двух недель | Полная команда + заказчик | Оформление заказа, оплата, личный кабинет, CRM |
Сроки зависят от числа интеграций и сложности бизнес-логики. Магазин без онлайн-оплаты и личного кабинета — ближе к каталогу. Лендинг с пятью формами и коллтрекингом — ближе к визитке.
Финальная приёмка — подписание акта сдачи-приёмки по чек-листу. Документ фиксирует, что проверено, кем и когда. Без акта любой баг после запуска станет «вашим», даже если его не было в ТЗ.
Что делать с чек-листом дальше
Адаптируйте под свои проекты. Уберите пункты, которые не применимы: лендинг не нуждается в проверке личного кабинета. Добавьте специфику вашего стека: для 1С-Битрикс — проверку композитного кеширования, для WordPress — конфликтов плагинов.
Встройте в таск-менеджер: шаблон задачи на тестирование с подзадачами под каждый блок. Это исключает «забыл проверить» и даёт историю для регрессионного тестирования.
Пересматривайте раз в квартал. Пороги Core Web Vitals меняются, появляются новые требования регуляторов, меняются инструменты аналитики. Чек-лист, который не обновлялся год, — это чек-лист прошлого запуска, а не следующего.
Если нужна помощь с тестированием перед запуском — оставьте заявку, подберём состав проверок под ваш проект и сроки.
