Каждый, кто запускал сайт, знает это чувство: вроде всё готово, макеты утверждены, разработчики отчитались, но в последний момент выясняется, что форма не отправляет заявки с одного из телефонов, а картинка на главной обрезается на широком мониторе. Хорошо, если это обнаружили сотрудники. Хуже, когда ошибку находит клиент, который уже собирался обратиться.
Тестирование нужно, чтобы поймать такие вещи заранее. Оно не гарантирует отсутствия ошибок вообще, но резко снижает вероятность того, что критичная проблема доживёт до публичного запуска. Кроме того, это часть профессиональной культуры: в сильных студиях тестируют не в последний день, а на протяжении всей работы.
Ниже разберём, какие бывают проверки, в каком порядке их проводят, как оформляют найденные ошибки и какую роль в процессе играет заказчик.
Зачем тестировать, если разработчики всё проверили
Разработчик проверяет, что его код делает то, что он задумал. Тестировщик проверяет, что сайт делает то, что нужно пользователю, даже когда тот ведёт себя непредсказуемо. Это разные взгляды. Автор плохо замечает собственные ошибки: он знает, как должно работать, и невольно идёт по «правильному» пути.
Типичный пример. Форма заявки валидна, если вводить аккуратно. Но что произойдёт, если вставить телефон с пробелами, нажать кнопку дважды, вернуться назад или отправить пустое поле? Для разработчика это краевые случаи, для живых людей — обычная жизнь.
Что экономит тестирование
- Деньги: исправление после запуска дороже, потому что приходится останавливать работу, откатывать изменения и объяснять клиентам.
- Репутацию: первое впечатление об обновлённом сайте формируется один раз.
- Рекламный бюджет: трафик, который уходит на сломанную страницу, потерян навсегда.
- Нервы команды: меньше авралов в первые дни после запуска.
Виды тестирования
Проверка сайта состоит из нескольких слоёв. Каждый ловит свои ошибки, и пропуск одного оставляет слепую зону.
Функциональное тестирование
Проверяет, что все элементы работают так, как задумано. Что именно входит:
- Работа форм: отправка, проверка полей, сообщения об ошибках, письма-уведомления, сохранение заявок в системе.
- Навигация: меню, хлебные крошки, ссылки, кнопки, возврат на главную.
- Поиск, фильтры, сортировка, пагинация, если они есть.
- Корзина и оформление заказа в интернет-магазине: добавление, удаление, пересчёт, промокоды, доставка, оплата.
- Личный кабинет, регистрация, восстановление пароля.
- Административная панель: создание и редактирование страниц, загрузка файлов, роли и права.
Кроссбраузерное тестирование
Сайт должен одинаково работать в разных браузерах и их версиях: у разных движков есть тонкие отличия в обработке стилей и скриптов. Минимальный набор: актуальные версии популярных браузеров на компьютерах и на мобильных платформах, а также один-два варианта предыдущих версий, если аналитика показывает долю таких посетителей. Решение о том, что поддерживать, лучше принимать на основе статистики вашей аудитории, а не по умолчанию.
Адаптивность и мобильная версия
Сайт проверяют на разных размерах экрана: от узких смартфонов до широких мониторов, в вертикальной и горизонтальной ориентации. Эмулятор в браузере полезен, но не заменяет реальные устройства: на них иначе работают прокрутка, клавиатура, жесты, адресная строка. Основы подхода описаны в статье про адаптивную вёрстку, а проектирование с акцентом на смартфон — в материале про mobile first.
Проверка соответствия макетам
Дизайнер и верстальщик сверяют готовую страницу с утверждёнными макетами: отступы, шрифты, цвета, состояния кнопок, анимации. Мелкие расхождения накапливаются и портят общее впечатление. Особое внимание уделяется состояниям, которые редко рисуют: наведение, фокус, ошибка, пустой список, длинное название, отсутствие картинки.
Тестирование скорости
Измеряется время загрузки страниц, вес ресурсов, поведение на медленном мобильном соединении. Здесь выясняется, не тормозят ли тяжёлые изображения, лишние скрипты или неоптимизированные шрифты. Почему это критично, мы подробно объясняли в статье про скорость загрузки сайта, а один из главных рычагов описан в материале про оптимизацию изображений.
Нагрузочное тестирование
Показывает, как сайт ведёт себя, когда на нём одновременно много посетителей. Для визитки это излишне, а для интернет-магазина перед распродажей или для проекта с планируемой рекламной кампанией — необходимо. Специальные инструменты имитируют поток запросов и фиксируют, при какой нагрузке время ответа становится неприемлемым.
Тестирование безопасности
Проверка на типичные уязвимости: защита форм, права доступа, настройки сервера, наличие сертификата, обработка загружаемых файлов. Более подробно меры защиты описаны в статье про SSL-сертификат и безопасность сайта.
Тестирование доступности
Проверяется возможность пользоваться сайтом людям с ограничениями: управление с клавиатуры, контраст, подписи к изображениям, понятные формы. Это не экзотика, а часть качества; тема раскрыта в материале про доступность сайта.
SEO-проверка
Перед запуском проверяют заголовки, описания, адреса страниц, перенаправления, файл robots, карту сайта, микроразметку, закрытие от индексации тестовой версии. Типичная катастрофа: сайт запущен, а в настройках остался запрет индексации с этапа разработки, и месяцы поискового трафика потеряны. Подробнее — в статьях про SEO на этапе разработки и robots.txt и sitemap.xml.
Проверка аналитики и целей
Счётчики установлены, цели настроены, события срабатывают, данные поступают без дублей. Если не проверить это до запуска, первые недели статистики окажутся пустыми или искажёнными. Ориентиры по метрикам — в статье про веб-аналитику.
Как организован процесс
Тестирование не должно происходить в один день перед запуском. Хорошая практика — проверять по мере готовности блоков, а в конце проводить общий прогон.
- Подготовка тест-плана. Составляется перечень сценариев и страниц, определяются устройства и браузеры, фиксируются критерии готовности.
- Тестовая среда. Проверка идёт на копии сайта, максимально близкой к боевой, чтобы не навредить реальным данным и не пустить в поиск незавершённую версию.
- Прогон сценариев. Специалист проходит каждый сценарий по списку и отмечает результат.
- Фиксация ошибок. Каждая найденная проблема описывается так, чтобы её можно было воспроизвести.
- Исправление. Разработчики устраняют ошибки в порядке приоритета.
- Повторная проверка. Каждое исправление проверяется отдельно, а затем проходит регрессия: убеждаются, что починка не сломала соседние функции.
- Приёмка заказчиком. Заказчик проходит основные сценарии и подтверждает готовность.
- Проверка после выкладки. На боевом сайте повторяется краткий набор критичных проверок.
Как этот этап вписывается в общий план проекта, можно увидеть на странице этапов работы.
Как правильно описывать ошибки
Хороший баг-репорт экономит часы. Плохой, вроде «не работает форма», вызывает долгие уточнения. Полное описание содержит:
- Адрес страницы и название блока.
- Шаги воспроизведения: что сделал, в каком порядке.
- Ожидаемый результат и фактический результат.
- Окружение: устройство, операционная система, браузер и его версия, размер экрана.
- Скриншот или запись экрана с отмеченной проблемой.
- Приоритет: насколько ошибка критична.
Уровни приоритета
| Уровень | Что означает | Пример |
|---|---|---|
| Блокирующая | Запуск невозможен | Не оформляется заказ, не отправляются заявки |
| Критическая | Ломается важная функция | Не работает фильтр каталога на смартфонах |
| Значительная | Мешает, но есть обходной путь | Неверно отображается блок в одном из браузеров |
| Незначительная | Косметика | Отступ отличается от макета на несколько пикселей |
Приоритеты нужны, чтобы не тратить время на мелочи, пока не починено главное. Блокирующие и критические дефекты закрываются до запуска всегда. Незначительные иногда переносятся на этап поддержки по согласованию с заказчиком.
Роль заказчика в тестировании
Команда студии проверяет техническое качество, но только заказчик знает бизнес изнутри. Он замечает ошибки смыслов, которые не увидит тестировщик: неверная формулировка условий, устаревший адрес офиса, неправильная цена, не тот тип услуги в заявке.
Что должен сделать заказчик
- Пройти путь клиента. Зайти на сайт глазами покупателя: найти услугу, узнать цену, оставить заявку, оформить заказ.
- Проверить тексты и данные. Названия, цены, телефоны и адреса в формах, условия доставки, юридическая информация.
- Проверить получение заявок. Убедиться, что письма приходят нужным сотрудникам, а данные попадают в учётную систему.
- Привлечь коллег. Люди из отдела продаж, поддержки и логистики видят то, что упускает руководитель.
- Дать сайт на проверку «свежему глазу». Попросите кого-то из знакомых выполнить простое задание и понаблюдайте. Методика описана в статье про юзабилити-тестирование своими силами.
- Своевременно отвечать. Затянутая приёмка срывает график, о чём мы писали в материале как не сорвать сроки проекта.
Правила приёмки по этапам и формулировки, которые стоит закрепить в договоре, собраны в статье как принимать работу по этапам.
Тестирование интернет-магазина: особенности
Для торговли набор проверок шире, потому что каждая ошибка напрямую связана с деньгами. Дополнительно проверяют:
- Весь путь покупки от главной до страницы благодарности, с разными способами доставки и оплаты.
- Расчёт стоимости: скидки, купоны, бесплатная доставка от суммы, округление.
- Реальные платежи на минимальную сумму, а не только тестовый режим платёжного сервиса. См. также статью про онлайн-оплату.
- Обмен данными с учётной системой: остатки, цены, статусы заказов; подробности в материале про интеграцию с учётными системами.
- Письма покупателю и менеджеру: тема, содержание, ссылки, корректность на разных почтовых клиентах.
- Поведение при отсутствии товара, отмене заказа, повторной оплате, обрыве соединения.
- Работу на смартфонах: большинство покупок сейчас совершается именно там, поэтому мобильная версия магазина проверяется особенно тщательно.
Такой подход мы применяли при запуске проектов для мебельного магазина «Древо» и магазина косметики «Флора»: сценарии заказов прогонялись с разными корзинами, способами доставки и промокодами до того, как открывался доступ клиентам. Более общий план запуска магазина описан в статье запуск интернет-магазина: пошаговый план.
Ручное и автоматизированное тестирование
Ручное тестирование — человек выполняет сценарии и оценивает результат. Оно незаменимо для оценки удобства, внешнего вида, нестандартных ситуаций. Автоматизированное — скрипты прогоняют повторяющиеся проверки без участия человека. Оно полезно на крупных проектах с частыми обновлениями: после каждого изменения система быстро проверяет ключевые функции.
Для типового корпоративного сайта достаточно ручной проверки с небольшим набором автоматических проверок: доступность страниц, битые ссылки, скорость, валидность разметки. Для сложных проектов с личным кабинетом и интеграциями автоматизация оправдывается, особенно на этапе поддержки и развития.
Типичные ошибки при тестировании
- Оставляют на последний день. Времени на исправления нет, и запуск проходит с известными дефектами.
- Проверяют только на одном устройстве. Сайт работает на ноутбуке разработчика, но ломается у клиентов.
- Тестируют на пустых данных. Реальный контент с длинными названиями, большими картинками и нестандартными символами выявляет проблемы, которые не видны на заглушках.
- Не проверяют письма и интеграции. Форма отправляется, но письмо уходит в спам или не доходит.
- Забывают про закрытие от индексации и про отмену закрытия. Тестовая версия попадает в поиск, или боевая остаётся закрытой.
- Не делают регрессию. Исправили одно, сломали другое.
- Принимают «на слово». Заказчик не проверяет сам, надеясь, что подрядчик всё сделал идеально.
- Не фиксируют результаты. Без протокола непонятно, что проверено, а что нет.
Критерии готовности к запуску
Чтобы решение «запускаем» было объективным, заранее договоритесь о критериях. Пример набора:
- Закрыты все блокирующие и критические дефекты.
- Основные сценарии пройдены на реальных устройствах и в согласованных браузерах.
- Формы отправляют данные, письма доходят адресатам, заявки попадают в нужные системы.
- Скорость загрузки не хуже согласованных значений.
- Настроены перенаправления, карта сайта, файл robots, снят запрет индексации.
- Установлены счётчики, цели срабатывают.
- Проверен защищённый протокол и отсутствие смешанного содержимого.
- Создана резервная копия и известен порядок отката.
- Заказчик письменно подтвердил приёмку.
Полный перечень действий в день запуска мы собрали в статье чек-лист запуска нового сайта.
Что делать после запуска
Тестирование не заканчивается открытием сайта. Первые дни стоит повысить внимание: следить за доступностью, просматривать статистику, проверять заявки. Реальные пользователи неизбежно найдут сценарии, о которых не подумала команда. Для этого полезно настроить журнал ошибок и сбор обратной связи.
Дальше качество поддерживают регулярными проверками: после обновлений системы, при добавлении новых блоков, при изменении платёжных или логистических сервисов. Эти работы входят в состав технической поддержки, о пользе которой мы рассказывали в материале поддержка сайта после запуска.
Итог
Тестирование — не формальность, а страховка вашего запуска. Оно включает функциональные проверки, работу в разных браузерах и на разных устройствах, скорость, безопасность, доступность и SEO, а завершается приёмкой заказчика по понятным критериям. Чем раньше начинается проверка и чем аккуратнее фиксируются результаты, тем спокойнее проходит запуск.
В Mevero тестирование встроено в каждый этап проекта, а перед запуском проводится полный прогон по чек-листу. Если хотите узнать, как это будет в вашем случае, напишите нам через страницу контактов, а о гарантиях на выполненные работы можно прочитать на странице гарантий.
