Сколько тестирования нужно сайту или приложению перед запуском?

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

КОРОТКО

Сколько тестирования достаточно

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

Покупатели замечают сбои, даже если никогда о них не пишут. В исследовании Baymard Institute среди онлайн-покупателей в США, бросивших заказ на этапе оформления, 17% назвали причиной ошибки или падение сайта, ровно столько же, сколько пожаловались на слишком длинное или сложное оформление (Baymard, список обновлён в сентябре 2025 года). Ошибка в корзине редко попадает в отчёт как ошибка: она выглядит как конверсия чуть ниже, чем могла бы быть, месяц за месяцем.

Нужный объём тестирования определяет цена сбоя.

ЦЕНА СБОЯ

Сначала оцените сбой, потом тесты

Прежде чем считать часы тестирования, прикиньте три вещи. Сколько стоит час простоя в заказах или бронированиях? Сколько стоит одна потерянная заявка при вашем среднем чеке сделки? Какие личные или платёжные данные могут утечь и кому вам придётся это объяснять? Приблизительных ответов хватит, чтобы понять, ближе ли проект к сайту-визитке или к системе, через которую идут деньги и данные.

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

Самые опасные сбои происходят без шума. О форме, которая выдаёт ошибку, сообщат в течение нескольких часов. Форма, которая благодарит посетителя, а письмо при этом не приходит, может так работать неделями. Мы столкнулись ровно с этим на одном из наших проектов, который не был в приоритете: при обновлении с Laravel 7 до Laravel 13 изменение в настройке шифрования почты в Laravel 11 оставило бы форму с благодарностью на экране, а все письма с заявками пропадали бы. Мы отправили настоящую тестовую заявку и дождались письма, и только после этого шаг считался завершённым.

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

КРИТИЧНЫЕ СЦЕНАРИИ

Что тестировать первым

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

1. Денежные сценарии. Оформление заказа с каждым способом оплаты, возвраты, купоны, налоги, стоимость доставки и продление подписок.
2. Регистрация и вход. Регистрация, подтверждение почты, сброс пароля и истёкшая сессия посреди оформления заказа.
3. Формы и заявки. Каждая форма от клика посетителя до почтового ящика и CRM, с проверкой, что письмо не попадает в спам.
4. Письма и уведомления. Подтверждения заказов, счета, уведомления о доставке и внутренние оповещения на всех языках сайта.
5. Роли и права доступа. Что каждая роль может видеть и менять, с проверкой под реальным аккаунтом каждой роли.
6. Всё остальное. Контентные страницы, поиск, фильтры и админка.

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

Тест-кейсы для этих сценариев, с шагами, данными и ожидаемым результатом для каждой роли, хранятся в TestRail, Qase или Jira, чтобы любой мог повторить их через месяц. На странице QA и тестирование описано, насколько глубоко идёт каждый вид проверки.

УСТРОЙСТВА И СКОРОСТЬ

Браузеры, телефоны и нагрузка

После критичных сценариев проверяют среду, в которой они работают. Веб-продукт тестируют в Chrome, Safari, Firefox и Edge, на нескольких размерах экрана и на медленном соединении. Safari заслуживает отдельного прохода на настоящем iPhone, потому что ошибки вёрстки, которых никогда не бывает в Chrome, часто первыми появляются именно там. Playwright запускает один и тот же тест в Chromium, Firefox и WebKit и умеет эмулировать телефоны и планшеты (документация Playwright, октябрь 2026 года). Эмуляция всё же не заменяет настоящий телефон, когда речь о касаниях, экранной клавиатуре и камере.

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

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

Самые дорогие ошибки выглядят на экране как успех.

ДОСТУПНОСТЬ

Доступность стала юридическим риском

Если вы продаёте клиентам в США, доступность сайта стала постоянным источником судебных исков. Юридическая фирма Seyfarth Shaw, которая отслеживает дела по разделу III закона ADA, насчитала 3 117 исков о доступности сайтов, поданных в федеральные суды в 2025 году, на 27% больше, чем 2 452 в 2024-м. Это 36% всех федеральных исков по разделу III ADA за год. Больше всего исков подано в Нью-Йорке (1 021) и Флориде (961) (Seyfarth Shaw, март 2026 года). Иски в судах штатов и досудебные претензии идут сверх этих федеральных цифр.

Министерство юстиции США применяет раздел III к тому, что предлагают бизнесы, открытые для публики, в том числе через свои сайты, но регламента с подробными техническими стандартами у него нет; существующие стандарты, такие как WCAG, служат полезным ориентиром (ADA.gov, разъяснение от марта 2022 года). На практике мерилом служит WCAG, и текущая версия это WCAG 2.2, рекомендация W3C, последняя редакция которой датирована 12 декабря 2024 года. По сравнению с WCAG 2.1 в ней девять новых критериев, среди них фокус, который не перекрывают закреплённые элементы, минимальный размер кнопок и доступная аутентификация (W3C, октябрь 2026 года).

В Европе есть жёсткая дата. Европейский акт о доступности (European Accessibility Act) вступил в силу 28 июня 2025 года (AccessibleEU, Европейская комиссия), и в число охваченных им услуг входят электронная коммерция и банковские услуги (Европейская комиссия). Микропредприятия, которые оказывают услуги, то есть компании с численностью менее 10 человек и годовым оборотом или балансом не более €2 млн, освобождены от требований; микропредприятия, которые продают товары, нет (CCPC, ведомство по защите прав потребителей Ирландии). Компании за пределами ЕС, которая продаёт онлайн покупателям в ЕС, стоит исходить из того, что требования касаются и её магазина.

Исследование WebAIM Million 2026 нашло автоматически выявляемые нарушения WCAG на 95,9% главных страниц из миллиона самых посещаемых сайтов, в среднем 56,1 ошибки на страницу. Текст с низким контрастом встретился на 83,9% из них, изображения без альтернативного текста на 53,1%, поля форм без подписей на 51% (WebAIM, данные за февраль 2026 года). Всё это находит базовая проверка.

Базовая проверка доступности перед запуском охватывает навигацию с клавиатуры по всему сценарию покупки или заявки, видимый фокус, текстовые альтернативы для изображений, подписи и сообщения об ошибках в формах, цветовой контраст и правильные заголовки. Те же исправления помогают программам, которые читают ваши страницы: в двух из 15 проверенных нами интернет-магазинов США всплывающее окно подписки оставляло в дереве доступности только iframe, и ИИ-агент для покупок не видел ни цены, ни кнопки. Эксперимент описан в статье о том, как мы отправили ИИ-агента за покупками в 15 магазинов США. Если продукту нужен полный аудит у специалиста или формальный отчёт о соответствии, мы так и говорим.

БЕЗОПАСНОСТЬ И ДАННЫЕ

Базовая безопасность и перенос данных

Тестирование перед запуском не заменяет тест на проникновение, но должно ловить слабые места, которые встречаются снова и снова. Кто может видеть и менять какие данные, с проверкой под каждой ролью, и проверяет ли это правило сервер или интерфейс просто прячет кнопку. Ключи и платёжные реквизиты, оставленные в коде, который выполняется в браузере. Ввод, который попадает в базу без проверки, и страницы ошибок, которые показывают посетителям настройки. Для продукта, быстро собранного с помощью ИИ-инструментов, эти проверки ещё важнее: интерфейс там часто выглядит готовым, а правила доступа так и не были написаны. Для такого продукта мы начинаем с оценки MVP, от $3 000: она показывает, что оставить, что исправить и что переписать, а тестирование потом охватывает то, что остаётся.

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

• количество записей до и после для товаров, клиентов и заказов;
• аккаунты, в которые по-прежнему можно войти, с историей заказов у нужного клиента;
• редиректы со всех старых адресов, у которых был трафик или ссылки;
• почтовые настройки на новом сервере, потому что без записей SPF и DKIM заявки начинают попадать в спам;
• robots.txt и доступ краулеров, ведь новый хостинг может по умолчанию закрыть сайт от поисковых и ИИ-краулеров.

Последний пункт не теоретический. На одном недавнем проекте после переезда на новый хостинг-аккаунт GPTBot и краулеры Meta стали получать ошибку 403, а хостинг сам добавил их в robots.txt. Остальной список в нашей статье о том, какие пункты переноса сайта агентства обычно пропускают.

РЕГРЕССИЯ

Тестирование после каждого обновления

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

Наши собственные обновления показывают, что обычно находит регрессия. Недавно мы перевели один из наших проектов, который не был в приоритете, с Laravel 7 на 13, а сайт Института трихологии и его интернет-магазин на OpenCart 3.0.5.1. Чаще всего в этих обновлениях всплывали проблемы вёрстки и CSS: стили, завязанные на старые версии библиотек, съезжали после обновления. Каждая такая проблема проявилась на тестовой копии и была исправлена до релиза, и обновлённые системы просто заработали, когда вышли в бой.

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

После примерно трёх дней разработки один день приёмки охватил 15 публичных страниц на трёх языках, 30 экранов админки, настоящую тестовую заявку, журнал ошибок и 987 внутренних ссылок. Вся история в нашем кейсе о том, как мы прошли шесть версий Laravel за три дня. Для живого сайта такие плановые обновления с регрессией на копии входят в поддержку и обслуживание сайтов, от $1 000 в месяц, а полная регрессия перед крупным релизом заказывается как работа QA.

АВТОМАТИЗАЦИЯ

Ручное или автоматическое тестирование

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

Автоматизация окупается, когда одни и те же проверки идут перед каждым релизом, а тестируемый сценарий перестал меняться каждую неделю. Продукту, который быстро меняется и не имеет тест-кейсов, сначала нужен ручной тестировщик: автоматизировать экран, который через месяц перерисуют, значит заплатить за тесты дважды. Что мы обычно автоматизируем первым:

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

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

Автоматизируйте то, что устоялось, а то, что меняется, проверяйте руками.

Сквозные тесты пишут на Playwright, Cypress или Selenium, они живут в вашем репозитории и запускаются в вашем пайплайне: GitHub Actions, GitLab CI или Jenkins. Тест, который время от времени падает, чинят или убирают, а не перезапускают до зелёного результата, потому что нестабильные тесты приучают команду не обращать внимания на красные сборки. Сам пайплайн, тестовая копия и откат, который выполняется известной командой, это работа инженеров по DevOps и облачной инфраструктуре, от $50 до $70 в час.

ОБЪЁМ ПО ПРОЕКТУ

Разумный объём тестирования по типу проекта

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

Когда продукт делаем мы, тестирование не покупается отдельно. В разработке MVP, от $20 000, дизайн, разработка, тестирование и запуск входят в одну фиксированную цену за согласованный объём, а QA работает с первого спринта.

Исключением может быть небольшой внутренний инструмент. Нашу собственную систему для заявок, проектов и счетов примерно за месяц сделали senior-разработчик, который сам же её и тестировал, и разработчик уровня junior-middle. Внимательный senior может проверять свою работу, пока пользователи это коллеги. Когда появляются клиенты, платежи или частые релизы, отдельный тестировщик окупается, потому что автор сценария обычно проверяет его так, как тот задуман, а не так, как его ломают пользователи.

СТОИМОСТЬ

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

В Peretz Agency QA и тестирование стоят от $30 в час, это стартовая ставка за ручное тестирование. Инженеры по автоматизации, старшие QA и узкие навыки, например нагрузочное тестирование, стоят дороже. Вы оплачиваете отработанные часы по счёту раз в месяц или фиксированную сумму в месяц за тестировщика на полный день, банковским переводом по договору; в ставку входят работа специалиста, договоры, техника, HR-сопровождение и отчётность.

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

Тестирование можно заказать тремя способами:

• Разовая проверка перед запуском, переездом или крупным релизом, с объёмом, согласованным заранее. Подходит сайту, который меняется редко.
• QA-инженер в вашей команде, который берёт задачи у вашего руководителя в вашем трекере. Мы присылаем шорт-лист, от 2 до 4 проверенных кандидатов, обычно в срок от 1 до 3 недель; первый месяц испытательный, и если специалист вам не подходит, достаточно предупредить минимум за две недели. Как проходит подбор, описано на странице Нанять QA-инженера.
• QA внутри проекта, который делаем мы, входит в цену проекта.

Для сравнения: медианная годовая зарплата аналитика по обеспечению качества или тестировщика ПО в США в мае 2025 года составляла $104 300, без учёта соцпакета и затрат на найм (Бюро трудовой статистики США, октябрь 2026 года). Наши тестировщики приходят из большого пула специалистов в Европе и Украине, которых мы знаем лично и проверили сами; они работают на уровне сильных американских и европейских команд, но обходятся дешевле. Все наши цены на странице цен.

FAQ

Источники

• Baymard Institute: Cart abandonment rate statistics
• Seyfarth Shaw, ADA Title III: Federal court website accessibility lawsuit filings bounce back in 2025
• ADA.gov: Guidance on web accessibility and the ADA
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• AccessibleEU, Европейская комиссия: The EAA comes into effect in June 2025
• Европейская комиссия: European Accessibility Act
• CCPC Ireland: European Accessibility Act guidelines for microenterprises
• WebAIM: The WebAIM Million 2026
• Playwright: Browsers
• Бюро трудовой статистики США: Software developers, quality assurance analysts, and testers