Критерии приёмки в задаче для ИИ: как написать проверяемый результат

Начните с видимого результата

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

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

Добавьте положительный и отрицательные сценарии

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

Для критичного пути полезно минимум два отрицательных случая: неправильный ввод и недоступность зависимости.

Проверяйте на нужных слоях

Unit проверяет доменную логику, integration - реальную базу или внешний контракт, browser smoke - пользовательский путь. Restart подтверждает сохранение состояния.

Не требуйте браузер для чистой функции и не ограничивайтесь unit-тестом там, где ошибка возникает только между сервисами.

Пишите точные, но не хрупкие условия

Проверяйте смысл и состояние, а не случайный CSS-класс, если класс не является контрактом. Укажите viewport, статус, обязательные поля и отсутствие ошибок.

Критерий не должен диктовать архитектуру без причины. «Данные сохраняются после restart» полезнее, чем «создай вторую базу».

• что сделать;
• в каких условиях;
• какой результат наблюдать;
• какое запрещённое последствие отсутствует.

Заранее определите доказательство

Команда и её exit code подтверждают test или build. Скриншот показывает конкретное визуальное состояние. Запрос к API подтверждает контракт, а запись в базе - сохранение.

Слова исполнителя «проверил, всё работает» не являются достаточным evidence для рискованной части.

Пример слабой и сильной приёмки

Слабо: «бот должен хорошо отвечать». Сильнее: «на вопрос из опубликованного FAQ бот отвечает по источнику; неизвестную цену не придумывает; просьбу позвать человека передаёт один раз; duplicate update не создаёт второй ответ».

Вторая версия определяет четыре свойства, которые можно воспроизвести и защитить регрессией.

Когда критериев достаточно

Покрыты основной результат, критические границы и реальные точки интеграции. Остальные идеи записаны в backlog, а не добавлены в текущую задачу.

Effort может предложить структуру приёмки, но риск и достаточность подтверждает владелец продукта.