Что проверить кроме внешнего вида: данные, права доступа, ошибки, интеграции, мобильные сценарии и готовность к эксплуатации.
У приложения аккуратные экраны, кнопки реагируют, а демонстрация проходит без ошибок. Достаточно ли этого для запуска? После разработки с ИИ проверять нужно те же рабочие свойства, что и у любого другого продукта: сохранность данных, права, интеграции и возможность пройти сценарий в обычных условиях.
Проверяйте задачу пользователя целиком
Начните с согласованного результата. Если продукт принимает заявки, пройдите путь от заполнения формы до появления записи у ответственного сотрудника. Затем обновите страницу, откройте заявку повторно и убедитесь, что значения сохранились.
Не подменяйте такую проверку нажатием каждой кнопки по отдельности. Интерфейс может правильно показывать уведомление, а запись в другой системе — не создаваться. Пользователю важен итог, поэтому приёмочный сценарий должен включать обе стороны процесса.
Проверьте неприятные, но обычные ситуации
- Пустое обязательное поле и некорректный формат данных.
- Повторное нажатие на отправку.
- Обновление страницы в середине работы.
- Пропавшее соединение или задержка ответа.
- Истёкшая сессия пользователя.
- Недоступная внешняя система.
Для каждой ситуации заранее определите ожидаемое поведение. Например, при сбое отправки форма должна объяснять проблему и давать безопасный способ повторить действие. Ошибка не должна превращаться в ложное сообщение об успехе.
Проверять повторы особенно важно там, где создаются заявки, заказы или платежные операции. Технический способ защиты выбирает разработчик, а для заказчика критерий прост: одно намерение пользователя не должно незаметно превращаться в несколько одинаковых действий.
Используйте разные учётные записи
Создайте тестовые роли, предусмотренные заданием, и пройдите один процесс от их имени. Клиент видит своё, сотрудник — разрешённые ему данные, администратор — необходимые инструменты управления. Проверяйте не только меню, но и прямые ссылки на записи.
Техническая команда дополнительно проверяет серверные ограничения. Скрыть элемент на странице недостаточно: правила должны соблюдаться при обращении к данным. Реальные клиентские сведения для этих проверок обычно не нужны — сценарии можно воспроизвести на специально подготовленном наборе.
Сверьте интерфейс с реальными экранами
На телефоне откройте длинное название, заполните форму с экранной клавиатурой, прочитайте ошибку и попробуйте исправить значение. Проверьте, что кнопка не перекрыта, текст не обрезан, а прокрутка не уводит пользователя от важного сообщения.
На компьютере пройдите ключевые действия с клавиатуры. Видимый фокус, понятные подписи и логичный порядок переходов помогают обнаружить проблемы, которые не заметны при быстром клике мышью. Если нужно системно разобрать взаимодействие, полезен отдельный UX/UI-аудит.
Разберите каждую интеграцию отдельно
Составьте список связей: CRM, почта, платежи, учётная система, файловое хранилище. Для каждой выясните, как подтверждается успешная операция, где видно ошибку и кто её исправляет. Уведомление по почте и сохранённая заявка — два разных результата.
Согласуйте поведение при задержке и повторе. Если CRM временно недоступна, заявка не должна просто исчезнуть. В зависимости от архитектуры потребуется очередь, повторная отправка или понятная задача оператору. Важно, чтобы выбранный механизм был реализован и проверен.
Если внутри продукта есть ИИ, добавьте отдельную проверку
Использование ИИ при написании кода не означает, что приложение само обращается к модели. Но если оно генерирует ответы, анализирует документы или выполняет действия по запросу, обычных функциональных тестов недостаточно.
Подготовьте набор типовых и сложных примеров с описанием приемлемого результата. Проверьте неизвестный вопрос, неполные данные, недоступность модели и запрос, выходящий за полномочия пользователя. Значимые действия должны проходить предусмотренный контроль; текст, полученный от модели, не заменяет проверку прав.
Также выясните, как ограничиваются расходы и что видит пользователь при исчерпании лимита. Оценивать такую функцию следует по согласованным сценариям, а не по одному удачному ответу на демонстрации.
Попросите показать развёртывание и восстановление
Наличие исходников ещё не гарантирует возможность продолжить проект. Команда должна объяснить, как собрать приложение, какие настройки нужны и какие внешние сервисы используются. Значения секретов передаются отдельно от публичной документации.
Порядок резервного копирования имеет смысл проверить восстановлением на отдельном окружении. Для релиза также нужен понятный способ вернуться к предыдущей рабочей версии. Объём этих процедур зависит от продукта, но ответственность не должна оставаться неопределённой.
Что подписывать по итогам приёмки
Зафиксируйте версию продукта, выполненные сценарии, найденные ограничения и незавершённые задачи. Разделите ошибки, мешающие запуску, и улучшения следующего этапа. Назначьте контакт для обращений и порядок наблюдения за первыми днями работы.
В ИИ-разработке FOCUS-group критерии готовности обсуждаем ещё до реализации. Если вы только планируете проект, начните с структуры технического задания: хороший список проверок вырастает из ясно описанной задачи.