Как проверять веб-приложение, созданное ИИ: чек-лист функций и скрытых недоработок

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

В эксперименте автора ИИ самостоятельно запустил локальный сервер для браузерной операционной системы. В интерфейсе открывались поиск, проекты и изображения, работали тёмная тема, список задач, фокус-таймер и конвертер температур. Музыкальные файлы не открывались. Notes позволял редактировать существующий файл, но не создавать и не удалять документы, а полноэкранная кнопка не срабатывала в проверенных местах.

Проверка веб-приложения начинается с запуска

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

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

Минимальный сценарий запуска

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

А что делать, если локальный сервер запустился сам, но часть функций не отвечает?

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

Таблица функций показывает разницу между демо и продуктом

Составьте перечень всех функций, которые видны в интерфейсе или обещаны в описании. Для каждой функции укажите конкретный результат, входные данные и ожидаемое состояние после действия. Формулировка «работает» слишком общая. Лучше записать сценарий полностью: пользователь вводит 30 градусов Цельсия, нажимает кнопку конвертации и получает 86 градусов Фаренгейта.

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

Операции с файлами нужно проверять отдельно

Файловые функции часто скрывают самые серьёзные недоработки ИИ-сгенерированных приложений. Список файлов ещё не означает, что приложение умеет управлять данными. Для каждого объекта проверьте полный набор операций: открыть, создать, изменить, сохранить, переименовать, удалить и отменить изменения.

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

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

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

Навигация и интерактивные элементы выявляют скрытые ошибки

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

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

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

Игровой сценарий проверяет логику, а не только клики

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

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

Внешняя целостность не подтверждает готовность приложения

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

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

Как оформить список доработок

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

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

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

Короткий чек-лист перед передачей веб-приложения

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

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