Тестирование сайта перед запуском: что проверяем

Сайт, который «вроде работает» у разработчика, и сайт, который выдерживает реальных посетителей, — это два разных продукта. Между ними стоит тестирование. По нашей статистике, на среднем интернет-магазине перед запуском находится от 60 до 150 дефектов разной критичности, и около десятка из них способны прямо остановить продажи. Рассказываем, что именно мы проверяем, в каком порядке и почему некоторые проверки нельзя доверить ни разработчику, ни заказчику.

Зачем нужен отдельный тестировщик

Разработчик проверяет свой код, но смотрит на него глазами автора: он знает, как система должна работать, и неосознанно идёт по «правильному» пути. Тестировщик делает наоборот — вводит телефон с буквами, нажимает «Оформить» дважды, открывает корзину в двух вкладках, возвращается назад кнопкой браузера после оплаты. Именно в таких сценариях живут самые неприятные ошибки.

Заказчик тоже не заменяет тестирование. Он обычно проверяет то, что видит: тексты, картинки, цвета. Это важно, но такая приёмка не поймает, что письмо о заказе не уходит на почтовые ящики одного из популярных сервисов, что выгрузка в 1С дублирует заказы, если покупатель обновил страницу, или что на iPhone с маленьким экраном кнопка оплаты уезжает за край. В нашей команде из 14 человек есть выделенный тестировщик, и это осознанное решение: стоимость его работы многократно ниже, чем стоимость одного дня сломанного оформления заказа.

Простой расчёт: магазин с оборотом 3 млн ₽ в месяц теряет около 100 000 ₽ за каждые сутки, когда не работает оплата. Ошибку такого рода тестировщик находит за полчаса.

Из чего состоит предрелизная проверка

Мы делим тестирование на несколько направлений. Каждое проходится по своему чек-листу, а результаты сводятся в единый реестр дефектов с приоритетами. Порядок важен: сначала проверяем, что основные функции вообще работают, потом — детали, иначе можно потратить день на выравнивание отступов в форме, которая не отправляется.

Функциональное тестирование: сценарии пользователя

Основу составляют пользовательские сценарии — последовательности действий, которые реальный посетитель совершает, чтобы достичь цели. Для интернет-магазина их обычно 20–40: найти товар через поиск, отфильтровать каталог, сравнить два товара, оформить заказ как гость, оформить с регистрацией, применить промокод, выбрать самовывоз, оплатить картой, отменить оплату, повторить заказ из кабинета. Каждый сценарий проходится в позитивном варианте и в нескольких негативных.

Формы и валидация

Формы — источник примерно трети всех дефектов. Проверяем пустые поля, слишком длинные значения, спецсимволы, кириллицу в email, пробелы в начале и конце, вставку телефона в формате с восьмёркой и с плюсом. Проверяем, что сообщения об ошибках понятны и появляются рядом с полем, а не только вверху страницы. Обязательно проверяем двойное нажатие на кнопку отправки — классическая причина дублей заявок в CRM. И, конечно, наличие чекбокса согласия на обработку персональных данных со ссылкой на политику, как того требует 152-ФЗ «О персональных данных».

Корзина и оплата

Здесь мы особенно придирчивы. Изменение количества, удаление последнего товара, товар, который закончился, пока лежал в корзине, смена города с пересчётом доставки, минимальная сумма заказа. Оплату проверяем в тестовом режиме платёжного сервиса: успешный платёж, отказ банка, закрытие окна оплаты, возврат на сайт по кнопке «Назад». Отдельно — что заказ получает статус «Оплачен» по уведомлению от платёжной системы, а не по факту возврата покупателя на страницу «Спасибо»: туда он может и не вернуться.

Права и роли

Если на сайте есть личный кабинет, оптовые цены или несколько ролей в админке, проверяем, что пользователь не видит чужие заказы, подставив другой номер в адресную строку, а менеджер контента не может удалить способы оплаты. Ошибки доступа редко заметны при обычном использовании, но последствия у них самые серьёзные.

Вёрстка на устройствах и в браузерах

Мы проверяем сайт не в эмуляторе, а на реальных устройствах: в студии есть парк из десятка телефонов разных размеров и платформ, включая недорогие Android-смартфоны с небольшим экраном и слабым процессором. Эмулятор в браузере честно показывает ширину, но не покажет, как ведёт себя экранная клавиатура, перекрывающая поле ввода, как работает автозаполнение адреса или насколько тормозит анимация на бюджетном устройстве.

Контрольные ширины для проверки — 320, 375, 414, 768, 1024, 1280, 1440 пикселей и ширина Full HD-монитора. Промежуточные значения тоже проверяем, медленно растягивая окно: именно между контрольными точками ломаются сетки карточек и выпадают пункты меню. Подробнее о принципах вёрстки под разные экраны — в статье про адаптивный дизайн.

Интеграции: где ошибки дороже всего

Интеграции — самая коварная часть, потому что ошибка часто проявляется не на сайте, а в другой системе и не сразу. Заказ оформился, покупатель доволен, а в 1С он пришёл без адреса доставки, или в CRM упал дважды, или вообще не дошёл, потому что в названии товара были кавычки, сломавшие XML.

Мы проверяем обмен на тестовой копии учётной системы заказчика: выгружаем заказы с разными способами доставки и оплаты, с промокодами, с товарами в разных единицах измерения. Смотрим, как обрабатываются изменения статусов в обратную сторону. Проверяем граничные случаи: товар с нулевой ценой, позиция, удалённая из 1С, но лежащая в чьей-то корзине, обмен, прерванный посередине. Для служб доставки сверяем рассчитанную на сайте стоимость с калькулятором службы на нескольких десятках адресов, включая удалённые населённые пункты.

Письма покупателям — частая слепая зона. Мы отправляем тестовые уведомления на ящики нескольких популярных почтовых сервисов и проверяем, что они не попадают в спам, корректно отображаются в мобильных приложениях и содержат правильные данные заказа. Неверно настроенные записи SPF и DKIM для домена — одна из самых частых причин, по которой письма о заказе «не доходят».

Скорость, SEO и безопасность

Эти проверки часто откладывают «на после запуска», и зря: исправлять их на живом сайте с трафиком сложнее и рискованнее.

По скорости мы замеряем ключевые шаблоны — главную, раздел каталога, карточку товара, корзину — в лабораторных инструментах и проводим нагрузочный тест. Целевые значения: LCP до 2,5 секунды на мобильном, отсутствие заметных сдвигов вёрстки, время ответа сервера до 600 мс на холодном кеше. Нагрузку подбираем исходя из ожидаемого трафика с запасом в три–пять раз.

По SEO проверяем, что у каждой страницы уникальные title и description, все старые адреса при переезде перенаправлены 301-м редиректом, нет страниц с кодом 200 вместо 404, карта сайта содержит только реальные канонические адреса, а в robots.txt снят запрет индексации, который стоял на тестовом домене. Последний пункт кажется очевидным, но забытый запрет — классика, после которой сайт неделями не появляется в поиске. Эти работы входят в SEO-подготовку при запуске.

По безопасности проверяем стойкость административного входа, отсутствие в открытом доступе резервных копий, файлов конфигурации и папок с системой контроля версий, корректность HTTPS и заголовков безопасности, защиту форм от спама и подбора.

Как мы организуем процесс

Тестирование — не разовое мероприятие за день до запуска. Если откладывать его до самого конца, дефекты накапливаются, их исправление тянет за собой новые, и релиз сдвигается. Поэтому проверка встроена во все этапы разработки.

1. Тест-план на этапе ТЗ

   Тестировщик читает техническое задание и прототипы, задаёт вопросы о неописанных сценариях и составляет список проверок. Уже на этом шаге находятся противоречия в требованиях.

2. Проверка по готовности модулей

   Каждый завершённый блок — каталог, корзина, кабинет — проверяется сразу, пока разработчик помнит контекст и исправление занимает минуты.

3. Регрессионное тестирование

   Перед релизом весь сайт проходится заново: исправления в одном месте нередко ломают что-то в другом. Часть проверок автоматизирована.

4. Приёмка заказчиком

   Заказчик получает стабильную версию и проверяет контент и бизнес-логику, а не ловит базовые ошибки.

5. Дымовой тест после запуска

   Сразу после переноса на рабочий сервер за 20–30 минут проходим критичные сценарии: заказ, оплата, формы, письма, обмен с 1С.

Каждый дефект получает приоритет. Блокирующие — сайт нельзя запускать: не работает оплата, не отправляются заявки. Критичные — серьёзная проблема, которую нужно исправить до релиза. Значительные и незначительные можно закрыть в первые недели после запуска, если сроки поджимают. Такая градация позволяет запускаться вовремя, не жертвуя главным. Как тестирование вписывается в общий процесс, видно на странице этапов работы.

Что проверить заказчику самостоятельно

Даже при профессиональном тестировании есть вещи, которые лучше всех знает сам бизнес. Мы просим заказчика пройти собственный короткий список до подписания акта приёмки.

• Цены, условия доставки и оплаты на сайте совпадают с реальными условиями работы компании.
• Заявки и заказы приходят тем сотрудникам, которые будут их обрабатывать, и в удобном виде.
• Контакты, реквизиты и режим работы актуальны во всех местах: шапка, подвал, страница контактов, письма.
• Тексты юридических документов согласованы с юристом компании.
• Менеджеры умеют добавить товар, изменить цену и обработать заказ в админке.
• Счётчики аналитики установлены на аккаунт компании, а не на личный аккаунт разработчика.

Коротко о главном

Тестирование перед запуском — это страховка от потерь, которые невозможно заметить сразу: недошедших заявок, задублированных заказов, некорректных цен и проблем на устройствах, которыми не пользуется команда разработки. Хорошая проверка охватывает функции, вёрстку на реальных устройствах, интеграции, скорость, SEO и безопасность, а не только внешний вид.

Самое ценное — встроить тестирование в процесс с первых этапов: составить тест-план вместе с ТЗ, проверять модули по мере готовности и обязательно проводить регрессию перед релизом. Тогда запуск проходит спокойно, а первые недели после него уходят на развитие сайта, а не на тушение пожаров.