Даже аккуратно собранный сайт перед запуском почти всегда имеет десяток мелких дефектов: где-то не отправляется письмо с формы, на планшете ломается меню, а в поисковой выдаче появляется дублирующая страница. Тестирование — это не формальность в конце проекта, а способ поймать такие ошибки до того, как их увидят пользователи. Ниже — виды проверок, которые имеет смысл пройти до переезда на рабочий домен.
Функциональное тестирование
Проверяем, что все заявленные функции работают: каждая кнопка делает то, что обещает, а данные сохраняются туда, куда должны. Обычно в чек-лист входят:
- формы — отправка, валидация полей, письма и уведомления в CRM;
- регистрация, авторизация, восстановление пароля;
- поиск, фильтры, сортировки, пагинация;
- корзина, оформление заказа, промокоды, расчёт доставки;
- личный кабинет и административная панель.
Негативные сценарии
Обязательная часть — проверка неверных действий: пустые поля, слишком длинные строки, несуществующие адреса, повторная отправка формы, оплата с отклонённой картой. Именно здесь чаще всего всплывают необработанные ошибки и «белые экраны».
Кросс-браузерное тестирование и устройства
Сайт должен одинаково работать в Chrome, Safari, Firefox, Edge, «Яндекс Браузере» и мобильных версиях тех же браузеров. Отдельно стоит проверить поведение у пользователей с блокировщиками рекламы, устаревшими версиями браузеров и нестандартными разрешениями экрана. Минимальный набор — реальный компьютер, смартфон и планшет: эмуляция в DevTools не покажет особенности тач-событий и рендеринга шрифтов.
Адаптивность и мобильная версия
Большая часть трафика приходит с телефонов, поэтому вёрстку проверяют на четырёх-пяти разрешениях: от узких экранов 320–360 px до широких мониторов. Смотрим на меню, таблицы, изображения, всплывающие окна, размер кликабельных зон и поведение контента при повороте экрана.
Производительность и нагрузка
Скорость влияет и на конверсию, и на позиции в поиске. Полезно измерить:
- время загрузки первой страницы и метрики Core Web Vitals;
- вес изображений, скриптов и шрифтов;
- поведение сайта при одновременной работе десятков или сотен пользователей;
- устойчивость к пиковой нагрузке — например, к рассылке или рекламной кампании.
Нагрузочное тестирование особенно важно для сервисов с личными кабинетами, оплатой и высоконагруженными разделами.
Тестирование безопасности
Минимальный набор проверок: защита от SQL-инъекций и XSS, корректная работа с правами доступа, шифрование соединения, скрытые от индексации и от посторонних служебные файлы, надёжное восстановление пароля, отсутствие открытых админок и резервных копий в публичном доступе. Если сайт принимает оплату или персональные данные, стоит рассмотреть внешний аудит.
Техническое SEO
Перед запуском проверяют файл robots.txt, карту сайта, корректность редиректов со старого домена, канонические адреса, метатеги title и description, микроразметку, alt у изображений, ЧПУ и отсутствие битых ссылок. Отдельный пункт — запрет индексации тестовой среды: иначе две версии сайта начнут конкурировать в выдаче.
Контент, ссылки и тексты
Простой, но часто пропускаемый этап: вычитать тексты, проверить орфографию, актуальность цен и контактов, работу внутренних и внешних ссылок, отсутствие заглушек «Lorem ipsum» и тестовых изображений.
Формы, интеграции и оплата
Внешние сервисы — самая хрупкая часть проекта. Нужно убедиться, что письма доходят и не попадают в спам, интеграции с CRM, аналитикой, платёжными системами и службами доставки передают корректные данные, а статусы заказов меняются правильно. Хорошая практика — провести реальную тестовую оплату и отследить путь клиента от заявки до уведомления менеджеру.
Доступность
Проверка базовых требований доступности — контраст текста, alt-тексты, навигация с клавиатуры, корректные заголовки и подписи к полям — расширяет аудиторию и снижает риск претензий. Значительная часть этих требований пересекается с техническим SEO, поэтому удобно проверять их одним списком.
Юзабилити и приёмочное тестирование
Финальный этап — пройти по ключевым пользовательским сценариям целиком: найти товар, оставить заявку, связаться с компанией. Лучше, если это сделает человек, не участвовавший в разработке, — он заметит очевидные неудобства, к которым команда уже привыкла. Затем сайт принимает заказчик по заранее согласованному списку требований.
Что делать после запуска
Тестирование не заканчивается в день релиза. Первые недели стоит следить за журналами ошибок, скоростью ответа сервера, корректностью целей в аналитике и обратной связью пользователей. Практика показывает: небольшая проверка сразу после запуска обходится дешевле, чем срочные правки, когда сайт уже приводит клиентов.

Спасибо, что отдельно вынесли негативные сценарии. Я как раз на прошлом проекте поймала баг: при повторной отправке формы заявка дублировалась в CRM, а письмо уходило дважды. До этой статьи думала, что достаточно проверить только успешную отправку.
А насколько реально на небольшом проекте без выделенного QA закрыть кросс-браузерное тестирование? Я обычно проверяю Chrome, Safari и Android, но про блокировщики рекламы и старые версии браузеров даже не думал. Что из этого можно считать обязательным минимумом?
Для небольшого проекта обязательным я бы назвал Chrome, Safari, Firefox и мобильные Chrome/Safari на реальном телефоне. Блокировщики и устаревшие версии можно проверить выборочно, если аудитория старая или есть жалобы. Планшет обычно добавляю, когда есть сложное меню или таблицы.