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

Чек-лист запуска

Отмечайте проверенное и возвращайтесь позже

Отметки сохраняются только в этом браузере и никуда не отправляются.

0 из 8 пунктов отмечено

Пройдите основной сценарий как новый пользователь

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

Зафиксируйте ожидаемый результат каждого шага:

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

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

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

Проверьте ошибки и неполные данные

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

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

Посмотрите приложение на разных экранах и способах управления

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

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

Закройте служебные файлы и лишний доступ

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

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

AppCheck Lite V1 выполняет базовые файловые и внешние проверки в режиме read-only: ищет открытые служебные файлы, небезопасные HTTP-настройки и публичные API. Он помогает увидеть типовые риски, но не заменяет проверку архитектуры и прав доступа.

Проверьте метаданные, аналитику и ссылки

Для публичной страницы проверьте title, description, один H1, canonical, favicon и отображение ссылки при публикации в мессенджере. Внутренние переходы и кнопки должны вести на действующие адреса.

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

Подготовьте публикацию и путь назад

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

После публикации повторите короткий smoke test уже по публичному адресу:

  1. Проверьте ответ страницы и HTTPS
  2. Пройдите основной сценарий
  3. Откройте изображения, стили и скрипты
  4. Проверьте отправку формы или сохранение результата
  5. Убедитесь, что служебные адреса закрыты
  6. Посмотрите журналы на новые ошибки

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

Частые вопросы

Достаточно ли автоматических тестов

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

Нужно ли проверять небольшое внутреннее приложение

Да, но объём зависит от риска. Даже внутренний инструмент может содержать рабочие данные, права доступа и операции, которые нельзя выполнять повторно. Начните с критичного сценария и доступа.

Когда приложение можно считать готовым к запуску

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

Соберите проверку вокруг одного сценария

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