Тестирование сайта: какие проверки делает разработчик и что заказчик может проверить сам

Короткий ответ: тестирование сайта — это проверка по списку сценариев, что сайт работает на телефонах и в разных браузерах, достаточно быстро грузится, принимает заявки и оплату и правильно передаёт данные в CRM или 1С. Основную часть проверок делает разработчик до сдачи, но главные сценарии — отправить заявку, оформить заказ, открыть сайт со своего телефона — заказчику стоит повторить самому: это занимает час и не требует специальных знаний. Нагрузочное тестирование и автотесты нужны не всем, ниже — когда они оправданы, а когда нет.

Какие виды тестирования бывают?

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

• Функциональное тестирование — каждая кнопка, ссылка, фильтр и форма делают то, что задумано. Проверяют по сценариям: «посетитель выбирает услугу и оставляет заявку», «покупатель кладёт два товара в корзину, меняет количество и оплачивает».
• Устройства и браузеры — вёрстка не разваливается на узком экране, меню открывается пальцем, поля формы не уходят за край, в Safari всё выглядит так же, как в Chrome.
• Скорость — страница показывает главное быстро и не «прыгает» при загрузке. Подробно о метриках и о том, как их читать, — в статье о скорости загрузки сайта.
• Формы и интеграции — заявка доходит до нужного человека, заказ появляется в CRM, оплата меняет статус заказа, письмо клиенту уходит с правильными данными.
• Нагрузочное тестирование — что будет, если на сайт одновременно придут сотни или тысячи человек.
• Автотесты — программы, которые сами прогоняют ключевые сценарии при каждой выкладке и сообщают, если что-то сломалось.

Отдельно стоят проверка безопасности и тестирование мобильных приложений — у них свои методы и свои риски, в этой статье мы их не разбираем.

Вид проверки	Что ловит	Кому обязательно	Кто делает
Функциональное	Кнопка не нажимается, фильтр показывает не то, корзина теряет товар	Любому сайту	Разработчик, заказчик повторяет главные сценарии
Устройства и браузеры	Съехавшее меню на телефоне, форма не влезает в экран, сломанная вёрстка в Safari	Любому сайту	Разработчик; заказчик — на своём телефоне
Скорость	Тяжёлые картинки, долгая первая отрисовка, прыгающий экран	Любому сайту, особенно с рекламой	Разработчик, сверка по PageSpeed Insights
Формы и интеграции	Заявка «ушла», но не пришла; заказ не попал в CRM или 1С; оплата без смены статуса	Всем, у кого есть формы, оплата или обмен	Разработчик на тестовых и реальных данных
Нагрузочное	Сайт падает при наплыве посетителей или при массовом импорте	Магазинам с акциями, сервисам с личными кабинетами	Разработчик или отдельный специалист
Автотесты	Поломки старых функций после новых правок	Продуктам, которые дорабатываются каждый месяц	Разработчик, запуск при каждой выкладке

Что обязательно проверить до запуска любого сайта?

До запуска обязательны четыре вещи: главные сценарии работают от начала до конца, сайт нормально выглядит на телефоне, формы и оплата доходят до адресата, страницы открываются по https без ошибок. Остальное зависит от типа сайта.

Чек-лист, который мы проходим перед сдачей любого сайта, от лендинга до магазина:

1. Сценарии целиком. Не «форма есть», а «заполнил, отправил, увидел сообщение об успехе, заявка пришла в Telegram и на почту, в ней телефон и название страницы».
2. Ошибки ввода. Что будет, если не заполнить обязательное поле, ввести телефон с восьмёркой, плюсом или скобками, вставить адрес почты с пробелом в конце. Посетитель должен понять, что исправить, а не потерять введённое.
3. Телефон. Меню, кнопки звонка и мессенджеров, формы, таблицы, всплывающие окна — на ширине обычного смартфона, в вертикальном и горизонтальном положении.
4. Браузеры. Как минимум Chrome, Safari на iPhone, Яндекс Браузер и Firefox. Самые частые сюрпризы — в Safari: даты, шрифты, липкие шапки.
5. Ссылки и пустые страницы. Все пункты меню ведут куда надо, несуществующий адрес отдаёт страницу 404, а не пустой экран.
6. https и сертификат. Сайт открывается по защищённому адресу, браузер не ругается на смешанное содержимое, адрес с www и без ведёт на одну версию.
7. Аналитика и цели. Метрика считает визиты, цель «заявка» срабатывает один раз, а не дважды и не ноль.
8. Юридические мелочи. Согласие на обработку персональных данных у формы, ссылка на политику, работающий баннер о cookie, если он нужен.
9. Техническая база для поиска. robots.txt не закрывает сайт от индексации после тестового режима, sitemap на месте, у страниц свои title и description. Подробно — в чек-листе что должно быть на сайте при запуске.

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

Как проверить сайт на разных устройствах и в браузерах?

Быстрый вариант — режим устройств в браузере Chrome: он сужает окно до ширины телефона и имитирует касания. Но это приближение, поэтому финальную проверку делают на настоящих телефонах: хотя бы один iPhone и один Android.

Режим устройств открывается через инструменты разработчика (F12, затем значок телефона). Документация Chrome прямо называет его «приближением первого порядка»: код выполняется на компьютере, процессор и поведение реального телефона он не воспроизводит. Поэтому порядок такой:

• Во время вёрстки разработчик смотрит страницы в режиме устройств на нескольких ширинах: узкий телефон, большой телефон, планшет, ноутбук, широкий монитор.
• Перед сдачей — проход по главным сценариям на реальных устройствах. Именно там видно, что клавиатура закрывает кнопку «Отправить», что на iPhone поле с датой выглядит иначе, что на старом Android тормозит анимация.
• Для редких сочетаний устройств и браузеров существуют платные облачные фермы реальных устройств. Для сайта компании или магазина они обычно избыточны; оправданы, когда у продукта широкая и разнообразная аудитория.

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

Ещё одна деталь: бесплатная проверка мобильной версии от Google (Mobile-Friendly Test), которой многие пользовались раньше, больше не работает — в блоге Google она помечена как закрытая. Если подрядчик предлагает «прогнать сайт через Mobile-Friendly Test», значит, давно не обновлял свой чек-лист.

Нужно ли нагрузочное тестирование небольшому сайту?

Обычно нет. Сайту-визитке, лендингу или корпоративному сайту с формой заявки нагрузочный тест мало что даст. Он нужен, когда вы точно знаете о пике: распродажа, рассылка по большой базе, запуск рекламы, сезонный спрос или сервис, где сотни людей работают одновременно.

Нагрузочное тестирование — это имитация множества одновременных посетителей: программа отправляет на сайт запросы и замеряет, когда он начинает отвечать медленно или с ошибками. Для этого есть бесплатные инструменты с открытым кодом, например Apache JMeter или k6, но сам прогон — не главная часть работы. Главное — правильно описать, что делают посетители: смотрят каталог, ищут, кладут в корзину, оплачивают. Тест «тысяча человек открывают главную» почти ничего не говорит о том, выдержит ли оформление заказа.

Когда нагрузочная проверка оправдана:

• интернет-магазин готовит акцию и пишет о ней всей базе одновременно;
• веб-приложение или личный кабинет, где сотрудники или клиенты работают весь день и все сразу заходят утром;
• каталог с тысячами товаров и фильтрами, которые считаются на лету;
• массовые операции: импорт прайса, синхронизация остатков с маркетплейсами, ночные выгрузки в 1С.

Важно: нагрузочный тест гоняют не на боевом сайте в рабочее время, а на копии или в согласованное окно. Иначе вы сами устроите сбой реальным покупателям.

Как проверяют формы, оплату и интеграции?

Каждую форму и каждую связку проверяют «на выходе»: не только что сайт показал «спасибо», а что заявка пришла в CRM с нужными полями, оплата сменила статус заказа, а 1С получила документ. Ошибки здесь стоят денег: заявки теряются молча.

Как это выглядит на практике:

• Формы — отправляем по одной заявке с каждой формы сайта и сверяем, куда она пришла, в каком виде и с какой меткой источника. Отдельно — с телефона: мобильные формы чаще ломаются из-за всплывающей клавиатуры и автозаполнения.
• Оплата — проходим в тестовом режиме платёжного сервиса успешную оплату, отказ банка и брошенную на середине оплату. Смотрим, что заказ в каждом случае получает правильный статус, а покупатель — понятное сообщение.
• Обмен с CRM и 1С — проверяем на реальных данных: товар с длинным названием, клиент без отчества, заказ с десятком позиций, повторная отправка того же заказа. Пограничные случаи и ломают интеграции в первую неделю.
• Сбой внешнего сервиса — что происходит, если CRM на минуту недоступна. Хорошая интеграция пишет ошибку в журнал и отправляет данные повторно, плохая просто теряет заявку.

В наших тарифах интеграций проверка на реальных данных и обработка ошибок обмена прописаны в составе работ, как и тест на реальном каталоге в автоматизации маркетплейсов, — это видно на странице цен.

Что проверяем	Инструмент	Что смотреть	Ограничение
Скорость и базовые ошибки	PageSpeed Insights, Lighthouse в Chrome	Данные реальных пользователей и рекомендации	Оценка лабораторная, на свежем сайте реальных данных ещё нет
Вид на телефоне	Режим устройств в Chrome DevTools	Ширина экрана, меню, кнопки, формы	Это приближение, не настоящий телефон
Доступность для поиска	Проверка ответа сервера в Яндекс Вебмастере	Код ответа 200, SSL-сертификат	Инструмент ходит с другого адреса, чем робот
Формы и письма	Сам сайт, почта, CRM	Дошла ли заявка, в каком виде, кому	Только вы знаете, кто должен её получить
Битые ссылки и разметка	Валидатор W3C, переход по меню вручную	Ошибки 404, незакрытые теги	Не всякое замечание валидатора — поломка

Что можно проверить самому бесплатно?

Самому можно проверить всё, что видит посетитель: главные сценарии, вид на своём телефоне, скорость по PageSpeed Insights, доступность страниц в Яндекс Вебмастере и доходят ли заявки. Глубокие вещи — нагрузку, безопасность, автотесты — оставьте разработчику.

Порядок самопроверки на час времени:

1. Откройте сайт со своего телефона через мобильный интернет, не через офисный Wi-Fi. Пройдите путь клиента: от главной до заявки или оплаты.
2. Попросите двух-трёх знакомых с другими телефонами сделать то же самое и прислать скриншоты, если что-то выглядит странно.
3. Отправьте заявку с каждой формы и проверьте, кто её получил и в каком виде.
4. Проверьте адрес в PageSpeed Insights: смотрите на мобильную оценку и раздел с данными реальных пользователей, если он появился.
5. Если сайт добавлен в Яндекс Вебмастер, воспользуйтесь инструментом «Проверка ответа сервера»: для рабочих страниц нужен код 200. Справка Яндекса оговаривает, что инструмент ходит с другого адреса и ответ может отличаться от того, что получает робот.
6. Пройдитесь по меню и подвалу: ни одна ссылка не должна вести в пустоту.

Найденное записывайте по схеме «что сделал — что ожидал — что получил — устройство и браузер — скриншот», подробнее — в шаблоне баг-репорта для заказчика. Сообщение «на телефоне всё криво» разработчику мало что говорит, а «iPhone, Safari, страница услуг: кнопка „Заказать“ перекрыта плашкой cookie» исправляется за минуты.

Когда нужен отдельный тестировщик?

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

Признаки того, что пора выделять тестирование в отдельную роль:

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

Часто вместо постоянного тестировщика выгоднее автотесты: один раз описать ключевые сценарии — вход, оформление заказа, оплата, создание заявки — и запускать их автоматически при каждой выкладке. Автотесты не заменяют взгляд человека на новую функцию, но надёжно ловят поломки старых. Нужны ли они вашему проекту и в каком объёме, решаем на брифе вместе с остальным составом работ.

Какие ошибки при тестировании встречаются чаще всего?

Главные ошибки — проверять только на компьютере разработчика, проверять «что форма есть» вместо «что заявка дошла», тестировать на пустой базе и откладывать проверку до последнего дня перед запуском.

• Проверка в идеальных условиях. Быстрый компьютер, офисный интернет, заполненный кэш браузера. Посетитель придёт с телефона в метро.
• Пустые данные. На трёх тестовых товарах каталог летает, на трёх тысячах — тормозит фильтр. Тестируйте на данных, близких к реальным.
• Нет списка сценариев. Без списка каждый проверяет «что вспомнил». Сценарии стоит записать ещё в техническом задании — как это сделать, разобрано в статье о составлении ТЗ на сайт.
• Тестовый режим остался включённым. Закрытый от поиска robots.txt, тестовые ключи оплаты, заявки, уходящие на почту разработчика. Это проверяют в день запуска отдельно.
• Перепроверка после правок забыта. Исправили кнопку в шапке — а сломалась мобильная версия меню. После каждой правки главные сценарии проходят заново.

Когда сложное тестирование вам не нужно?

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

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

Как тестирование устроено в работе Roboweb.team?

Проверка входит в каждый тариф, отдельной строкой её не продаём. Перед сдачей проходим чек-лист по типу проекта, затем вы принимаете работу: по договору на это есть 5 рабочих дней, а после подписания акта действует гарантия 30 календарных дней.

• Сайты и лендинги — адаптив под телефон, планшет и компьютер, проверка форм и аналитики, финальная проверка после публикации на домене. Лендинг — от 24 000 ₽, корпоративный сайт — от 56 000 ₽.
• Интернет-магазины — корзина, оплата, доставка, обмен с учётной системой; от 104 000 ₽.
• Веб-приложения — роли, сценарии, интеграции; автотесты — по согласованию на брифе; от 160 000 ₽.

Правки — до 2 раундов (в магазине и веб-приложении — до 2 на прототипе и до 2 на готовой сборке), после запуска — бесплатная поддержка 7 дней, 14 дней или месяц в зависимости от тарифа. Если сайт развивается дальше, доработки идут в рамках поддержки и развития — от 7 900 ₽ в месяц. Как устроены этапы целиком, рассказываем в статье о процессе работы над сайтом, а состав работ под вашу задачу — на странице заказной разработки.

Короткие ответы на частые вопросы

Что такое тестирование сайта простыми словами?

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

Сколько стоит тестирование сайта?

Отдельной строки «тестирование» в нашем прайсе нет: проверка входит в каждый тариф — от лендинга от 24 000 ₽ до веб-приложения от 160 000 ₽. Если нужно проверить чужой сайт или настроить автотесты на работающем продукте, объём оцениваем после брифа.

Можно ли проверить сайт на разных устройствах без набора телефонов?

Частично. Режим устройств в браузере Chrome показывает, как страница выглядит на узком экране, но сам Chrome называет это приближением. Для финальной проверки нужен хотя бы один настоящий iPhone и один Android, обычно они есть у сотрудников.

Нужно ли нагрузочное тестирование сайту-визитке?

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

Что делать, если ошибку нашли после подписания акта?

По нашему договору исполнитель бесплатно исправляет ошибки, возникшие по его вине, в течение 30 календарных дней с даты подписания акта. Гарантия не распространяется на изменения, которые внесли вы или третьи лица, и на сбои сторонних сервисов.

Услуги и кейсы по теме: поддержка сайта от 7 900 ₽/мес · заказная разработка · цены и сроки