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

Коротко: определения именно тестирования сайта на названной странице web.dev нет, есть общее определение тестирования программ: запуск программы определёнными способами, чтобы убедиться, что она ведёт себя так, как задумано. Разработчики называют виды тестов по масштабу и цели: модульные, интеграционные, сквозные и другие. Что из этого может пройти сам заказчик, источники не говорят; это вывод автора, он помечен в тексте. Для приёмки MDN советует записать список требований, которые должны пройти, и сценарий шагов.

Подрядчик может сообщить, что идёт тестирование сайта. Ниже - что это слово значит на странице web.dev, какие виды проверок там названы, как MDN советует записать, что должно пройти до приёмки, и что показывают Lighthouse и PageSpeed Insights.

Главные опоры, курсы web.dev и MDN, - учебные материалы для разработчиков: стандарта или нормативного акта в них нет. Перенос на заказчика (что из этого вы видите, что спросить) - вывод автора, и каждый такой вывод назван так. Страницы web.dev, MDN, Chrome for Developers и страница Google о PageSpeed Insights открыты на английском, цитаты даны с переводом. Русские версии web.dev и Chrome for Developers переведены автоматически, на странице так и сказано. Документ Google о переносе сайта и страница ЮKassa открыты на русском. Примеры вымышленные: цветочная мастерская Фиалка с сайтом example.ru. Код, настройка инструментов, цены и сроки тестирования не разбираются. Страницы открыты 11.10.2026.

Что такое тестирование сайта?

Коротко: у web.dev тестирование - процесс запуска программы определёнными способами, чтобы убедиться, что она ведёт себя как задумано. Отдельного определения именно для сайта на названных в статье страницах web.dev и MDN нет, поэтому ниже взято общее определение для программ и примеры проверок из той же страницы.

Определение стоит на странице What testing is | web.dev, первой в разделе «Get Started with Testing» курса Learn Testing:

«Testing can be broadly defined as the process of running software in specific ways to ensure that it behaves as it was intended to.»

• web.dev, What testing is

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

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

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

Коротко: страница web.dev «Types of automated testing» перечисляет восемь общих видов тестов и несколько других. Страница оговаривает, что у этих названий нет строгих определений; вывод автора: подрядчик может вкладывать в слово иной смысл.

Автоматизированное тестирование - любой процесс, который позволяет записать тесты так, чтобы компьютер запускал их повторно, и человеку не приходилось повторять шаги, например подготовку или проверку результатов (перевод и пересказ страницы What testing is | web.dev). О названиях видов предупреждает страница Types of automated testing | web.dev:

«The names given to different types of tests tend to have common themes across codebases, but they don't have particularly rigorous definitions.»

• web.dev, Types of automated testing

Перевод наш: у названий разных видов тестов есть общие темы в разных проектах, но строгих определений они не имеют. Курс даёт ориентиры, и другие материалы, по словам страницы, могут определять виды иначе. Таблица составлена из перевода и пересказа раздела «Common types of tests».

Раздел «Other types» добавляет ещё пять названий. Manual testing - ручное тестирование. Acceptance testing - приёмочное, вид ручного. Chaos testing - ввод случайных данных, чтобы сайт не рухнул от неправильных данных. Failure testing - намеренная имитация сбоев, например сети. Build testing - проверка, что файлы сборки создаются; страница отмечает, что такой тест может пригодиться для проверки результата сложной CMS.

Страница «What to test and your approach» добавляет, что не все названия описывают масштаб. Дымовые тесты, по её словам, - отдельная категория, и сами они могут быть модульными, сквозными или другими. Цель дымовых тестов там названа так: дать проверяющим общую уверенность, что проект в допустимом состоянии.

Что из этого может проверить сам заказчик?

Коротко: web.dev называет ручное тестирование отдельным способом проверки: человек открывает сайт в браузере и подтверждает, что он ведёт себя как ожидалось. Перенос этого на заказчика - вывод автора: сценарии сквозного теста можно пройти руками.

Про ручное тестирование страница What testing is пишет так:

«Manual testing involves humans running software directly, such as loading a website in their browser, and confirming that it behaves as expected.»

• web.dev, What testing is

Перевод наш: ручное тестирование - когда люди запускают программу напрямую, например открывают сайт в браузере, и подтверждают, что он ведёт себя как ожидалось. Для ручных тестов страница даёт два вопроса: «can your site load?» (открывается ли сайт) и «Can you perform these actions?» (получается ли выполнить эти действия). Там же отмечено, что люди могут плохо замечать сбои и несоответствия, когда много раз повторяют одно задание. Страница «Types of automated testing» добавляет: ручное тестирование может служить дымовым тестом.

Вывод автора для заказчика. Автоматические тесты записаны как код (на странице есть примеры на JavaScript) и рассчитаны на разработчика. Ручная проверка кода не требует: открыть сайт, пройти действия посетителя и записать результат. Сквозной тест по описанию web.dev проходит основные действия сайта, как и ручной проход. Поэтому сценарии сквозного теста и ваш список для приёмки могут совпадать.

Покрытие кода - доля кода, которую проверяют автоматические тесты; страница «Types of automated testing» пишет, что её можно измерять и показывать как статистику во времени. Стремиться к 100% она не советует: это может привести к лишним затратам и к простым или плохо продуманным тестам, которые не проверяют основные сценарии глубоко. Вывод автора: если подрядчик называет процент покрытия, спросите, какие сценарии сайта за ним стоят.

Как тестирование связано с приёмкой сайта?

Коротко: web.dev называет приёмочное тестирование видом ручного, который подтверждает, что продукт соответствует нуждам пользователя. Приёмку работы по договору подряда описывает ст.720 ГК РФ; её разбор вынесен в статью о договоре.

Приёмочное тестирование страница определяет коротко: вид ручного тестирования, популяризированный Agile, который подтверждает, что продукт «meets the user's needs» (отвечает нуждам пользователя). Это переведённая и сокращённая строка из раздела «Other types» страницы Types of automated testing | web.dev.

Приёмка работы по договору подряда - отдельное понятие из закона. Пункт 1 ст.720 ГК РФ говорит, что заказчик обязан «в сроки и в порядке, которые предусмотрены договором подряда, с участием подрядчика осмотреть и принять выполненную работу (...)» (ст.720 на consultant.ru, редакция от 24.06.2025 с изменениями от 09.06.2026). Остальные пункты статьи, последствия приёмки без проверки и права при недостатках разобраны в статье «Договор на разработку сайта: что говорит ГК и что проверить до подписи». Юридической оценки конкретной ситуации здесь нет.

Как записать, что должно пройти?

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

Страница MDN Strategies for carrying out testing - Learn web development | MDN, раздел «What are you going to test?», открывается такой фразой:

«When you've got a new addition to your codebase that needs testing, before you start testing you should write out a list of testing requirements that need to pass to be accepted.»

• MDN, Strategies for carrying out testing

Перевод наш: когда в проект добавлено новое, что нужно проверить, до начала проверки следует выписать список требований, которые должны пройти, чтобы это приняли. Требования, по словам страницы, могут быть визуальными и функциональными. В примере MDN о кнопке с вопросительным знаком среди них: кнопка включается основным способом управления пользователя (мышью, клавиатурой, касанием); нажатие показывает и скрывает блок с информацией; текст в блоке читается; слабовидящие пользователи программ чтения с экрана имеют доступ к тексту.

Дальше страница объясняет, как использовать такой список для проверки людьми:

«It is useful to provide a set of steps (sometimes called a script) so that you get more reliable results pertaining to what you were trying to test.»

• MDN, Strategies for carrying out testing, раздел «User testing»

Перевод наш: полезно дать набор шагов (его называют также сценарием), чтобы результаты, относящиеся к тому, что вы проверяли, были надёжнее. Для проверки группой пользователей страница описывает показ страницы с новой функцией на сервере разработки: «so you are not putting the final site or change live until it is finished» (чтобы не выпускать итоговый сайт или изменение, пока оно не закончено). Перечень браузеров, чистый профиль браузера и проверку группой пользователей разбирает статья «Кроссбраузерность сайта: что это и как проверить до приёмки». Как записывать требования так, чтобы их можно было проверить, - статья «Техническое задание на сайт: что это и что в него входит».

Какие сценарии включить в список в первую очередь, web.dev советует выбирать по основным сценариям использования: страница «What to test and your approach» предлагает думать о том, как пользователь работает с проектом. Там же сказано: у каждого тестового случая должна быть чётко определённая цель.

Как выглядит список сценариев для приёмки?

Коротко: ниже пример автора для вымышленной мастерской Фиалка. Он составлен по схеме MDN: требование, шаги, вопрос о результате. У вашего сайта страницы и сценарии будут другими; перенос схемы - вывод автора.

Цветочная мастерская Фиалка заказала сайт с каталогом букетов и оформлением заказа на example.ru. Список ниже придуман; в источниках таких сценариев нет, схема взята со страницы MDN.

Сценарий 1. Заказ букета
Где: example.ru, компьютер и телефон.
Шаги:
1. Откройте главную страницу.
2. Перейдите в каталог и откройте карточку любого букета.
3. Нажмите кнопку добавления в корзину.
4. Оформите заказ с тестовыми данными.
Вопросы о результате:
- Видно ли в корзине выбранный букет и его цену?
- Появилось ли сообщение, что заказ принят?
- Получила ли мастерская письмо о заказе?
Результат: пройден / не пройден; устройство, браузер и его версия.

Сценарий 2. Заявка на доставку
Шаги:
1. Откройте страницу доставки.
2. Заполните форму и отправьте её.
Вопросы о результате:
- Что увидел посетитель после отправки?
- Пришла ли заявка по адресу, записанному в задании?
Результат: пройден / не пройден.

Сценарий 3. Оплата в тестовом режиме
Условие: платёжный сервис подключён, у него есть тестовый режим.
Шаги: оформите заказ и оплатите его тестовыми данными сервиса.
Вопросы о результате:
- Прошла ли оплата?
- Не ушёл ли заказ в работу мастерской как настоящий?
Результат: пройден / не пройден.

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

Что проверяют Lighthouse и PageSpeed Insights?

Коротко: Lighthouse - автоматический инструмент с открытым исходным кодом, который проверяет страницу аудитами, среди них производительности, доступности и SEO. PageSpeed Insights показывает лабораторные данные из Lighthouse и данные реальных посетителей; у недавно опубликованной страницы данных посетителей может не быть.

Скорость страниц проверяют инструментами; ниже разобран один из них и его ограничения, без инструкции. Страница Introduction to Lighthouse | Chrome for Developers начинается так:

«Lighthouse is an open-source, automated tool to help you improve the quality of web pages.»

• Chrome for Developers, Introduction to Lighthouse

Перевод наш: Lighthouse - автоматический инструмент с открытым исходным кодом, который помогает улучшить качество веб-страниц. В тексте страницы сказано: «It has audits for performance, accessibility, SEO, and more» (у него есть аудиты производительности, доступности, SEO и другие). Не пройденные аудиты, по словам страницы, служат указаниями, как улучшить страницу; у каждого аудита есть справка о том, почему он важен и как исправить. Запускают его в Chrome DevTools, из командной строки или как модуль Node, а также через веб-интерфейс.

Страница About PageSpeed Insights | Google for Developers разделяет два вида данных:

«Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience - but has a more limited set of metrics.»

• Google for Developers, About PageSpeed Insights

Перевод наш: лабораторные данные полезны для поиска проблем, потому что собраны в контролируемой среде, но могут не показать узкие места в реальной жизни. Полевые данные полезны, чтобы уловить настоящий опыт реальных пользователей, но метрик у них меньше. Лабораторные данные PageSpeed Insights получает через Lighthouse. Полевые данные, по словам страницы, берутся из набора Chrome User Experience Report за предыдущие 28 дней. Для новой страницы там есть оговорка: данных может не хватить, если страница опубликована недавно или у неё слишком мало образцов от реальных пользователей.

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

Что такое нагрузочное тестирование?

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

В конце страницы Types of automated testing | web.dev в вопросе «Which of the following are known types of tests?» есть вариант «Stress testing». В пояснении к нему сказано:

«We haven't mentioned this here, but stress or load testing is a type of testing production systems to ensure they can accept a large amount of traffic. It's more associated with big system design than with testing more typical codebases.»

• web.dev, Types of automated testing, раздел «Check your understanding»

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

Где разобраны проверки браузеров, адаптива, форм и оплаты?

Коротко: проверки по предметам вынесены в отдельные статьи раздела. Для оплаты в тестовом режиме у ЮKassa есть своя страница; она описывает, какие способы оплаты можно проверить до настоящего магазина.

Для оплаты статья о подключении оплаты разбирает справку ЮKassa о тестовых магазинах. Страница Тестирование - Прием платежей по API ЮKassa (документация для разработчиков) начинается словами о тестовом режиме:

«При использовании тестового режима всё проходит, как при настоящих платежах, но деньги никуда не переводятся.»

• ЮKassa, Тестирование - Прием платежей по API ЮKassa

В разделе «Что можно протестировать» там же сказано, что платежи банковской картой и кошельком ЮMoney протестировать можно, а остальные способы оплаты проверяют только в настоящем магазине. И предупреждение: «Не отдавайте товар, за который заплатили через тестовый магазин.» Если на сайте предложены другие способы оплаты, по этой странице в тестовом магазине их не проверить (вывод автора); порядок нужно выяснить у подрядчика и у платёжного сервиса.

Для редизайна есть документ Перенос сайта | Центр Google Поиска | Documentation | Google for Developers. Его обзор содержит пункт: «Подготовьте новый сайт и тщательно его протестируйте.» Документ написан о переносе с изменением адресов страниц; что проверить после снятия тестовых запретов на индексирование, разобрано в статье о редизайне.

Что спросить у подрядчика о тестировании?

Коротко: семь вопросов ниже составлены по разделам статьи. Это вывод автора, источники web.dev и MDN вопросов заказчика не формулируют. Ответы стоит записать вместе с критериями приёмки.

На главной странице BITSPARK шаг процесса «Запуск» описан так: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.» Вопросы ниже составлены для любого исполнителя.

1. Как называется этап проверки и что именно на нём проверяют? Если звучит название вида теста, попросите объяснить, что оно значит для этого сайта: страница web.dev предупреждает, что строгих определений у названий нет.
2. Какие проверки проходят руками, а какие выполняет программа? В каком виде вы увидите результат: отчёт, список пройденных сценариев или показ на экране?
3. Где идёт проверка: на тестовом адресе до публикации? MDN описывает проверку на сервере разработки, чтобы итоговый сайт не выходил, пока не закончен.
4. Записан ли список требований и сценариев для приёмки, и кто его утверждает? Как записывать проверяемые требования, разобрано в статье о техническом задании.
5. Если называют покрытие кода в процентах, какие сценарии сайта за этим стоят? Страница web.dev не советует стремиться к 100%.
6. Для скорости: какой инструмент и какие данные использованы, лабораторные или полевые, на каких страницах? Для новой страницы полевых данных может не быть.
7. Для оплаты: какой тестовый режим у платёжного сервиса, кто проводит тестовый платёж и кто переключает сайт на настоящий магазин?

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

Чего источники не говорят?

Коротко: названные в статье страницы web.dev и MDN не дают определения тестирования именно сайта, не называют сроков и цен проверки и не обещают результата. Три страницы курса web.dev, на которые опирается статья, датированы 31 января 2024 года.

• Определение на странице web.dev относится к программам вообще. Для сайтов отдельной формулировки на названных в статье страницах web.dev и MDN нет.
• Курс web.dev Learn Testing и учебный курс MDN рассчитаны на разработчиков. Что и в каком объёме проверять на вашем сайте, они не решают.
• Сроков, цен и числа сценариев для проверки сайта в источниках нет.
• Страницы web.dev о видах тестов датированы 2024-01-31 UTC, страница PageSpeed Insights - 2024-10-21 UTC, страница Lighthouse - 2025-06-02 UTC. Страница MDN изменена 6 октября 2026 года.
• Страница ЮKassa описывает сервис ЮKassa; порядок проверки у других платёжных сервисов в статье не разбирается.

Источники

Страницы открыты 11.10.2026.

• What testing is | web.dev - определение тестирования, ручное и автоматизированное (обновлена 2024-01-31 UTC, английская версия).
• Types of automated testing | web.dev - виды тестов, другие виды, покрытие кода, нагрузочное тестирование (обновлена 2024-01-31 UTC, английская версия).
• What to test and your approach | web.dev - выбор по основным сценариям, цель тестового случая (обновлена 2024-01-31 UTC, английская версия).
• Strategies for carrying out testing - Learn web development | MDN - список требований, сценарий шагов, проверка на сервере разработки (страница изменена 6 октября 2026 года, английская версия).
• Introduction to Lighthouse | Chrome for Developers - что такое Lighthouse (обновлена 2025-06-02 UTC, английская версия).
• About PageSpeed Insights | Google for Developers - лабораторные и полевые данные (обновлена 2024-10-21 UTC, английская версия).
• Тестирование - Прием платежей по API ЮKassa - тестовый режим, способы оплаты для проверки (дата на странице не указана).
• Перенос сайта | Центр Google Поиска | Documentation | Google for Developers - пункт обзора о проверке нового сайта (последнее обновление 2026-09-11 UTC).
• ГК РФ Статья 720. Приемка заказчиком работы, выполненной подрядчиком \ КонсультантПлюс - п.1 (ред. от 24.06.2025, с изм. от 09.06.2026).
• BITSPARK - Digital studio - шаг «Запуск» (главная студии).
• Кроссбраузерность сайта: что это и как проверить до приёмки - BITSPARK - статья раздела.
• Адаптивный сайт: что это и как проверить адаптив до приёмки - BITSPARK - статья раздела.
• Юзабилити сайта: что это и что проверить до приёмки - BITSPARK - статья раздела.
• Договор на разработку сайта: что говорит ГК и что проверить до подписи - BITSPARK - статья раздела.
• Техническое задание на сайт: что это и что в него входит - BITSPARK - статья раздела.
• Как подключить оплату на сайт: что просят ЮKassa и Robokassa - BITSPARK - статья раздела.
• Форма обратной связи на сайте: что это и что проверить до запуска - BITSPARK - статья раздела.
• Редизайн сайта: что это и что проверить до запуска - BITSPARK - статья раздела.

Обсудить проект в Telegram: t.me/billioniks