Оценка ИИ-процесса: сравниваем результат, а не впечатления
Создаём маленький проверочный набор и фиксируем фактические ошибки, исправления и затраты времени.
- Задать наблюдаемую рубрику ответа ассистента.
- Сравнить промпты на неизменном наборе задач.
- Не смешивать ошибки артефакта, результаты продукта и замеры времени.
Структурнее не всегда значит точнее
После улучшения промпта ответ обычно становится длиннее и аккуратнее. Это не доказывает, что проверки точнее или команда тратит меньше времени. Нужен небольшой набор задач с независимыми ожиданиями. Зафиксируйте его версию, повторяйте сравнение после изменений, затем добавляйте новые случаи, которых не было при настройке инструкции.
В нашем курсе набор включает подмену authorId, потерю Веры в SQL, удвоение t1 после JOIN, пробельный title, выдуманный метод Playwright и путаницу DOM с сервером. Для каждого случая запишите нужный результат и критическую ошибку. Это локальная проверка рабочего процесса, а не рейтинг всех моделей для всех задач.
Наблюдаемая рубрика
| Задача | Нужный результат | Критическая ошибка |
|---|---|---|
| API-доступ | Чужой draft не раскрыт; проверяется тело | Назвать 404 с утечкой успешным |
| SQL: нулевая группа | Вера сохранена с 0 | Потерять u3 и не заметить |
| SQL: кратность | Анна имеет 1 задачу | Посчитать комментарии как задачи |
| UI-код | Однозначный локатор и assertion | Выдать DOM за проверку БД |
Что сохранять для сравнения
Запишите задачу, версию контракта, промпт, доступную версию инструмента, ответ и правки человека. Для времени измеряйте весь путь до проверенного артефакта: подготовку, получение ответа, ревью, исправления и проверку. Не объявляйте экономию без фактического замера. Если одновременно изменены модель, промпт и входы, нельзя понять, что именно повлияло на результат.
Разделяйте ошибку модели и дефект приложения. Неправильное ожидание в сгенерированном кейсе ещё не доказывает неверное поведение сервера. Если запрос не выполнялся, динамический результат неизвестен. Отдельно фиксируйте неверные утверждения, пропуски и стоимость исправления. Число таких замечаний не становится процентом покрытия системы.
Одинаковые условия для двух промптов
Промпт A просит написать больше тестов. Промпт B требует правило, контрпример и проверку эффекта. Дайте им одинаковые учебные входы и оцените артефакты по одной рубрике. По возможности скройте, какой ответ принадлежит новой версии, чтобы не предпочесть её только из-за ожидания улучшения. Второй человек может провести независимое ревью; второй похожий ответ модели не заменяет оракул.
Одна удачная попытка не гарантирует повторяемость. Для важного сценария повторите несколько случаев и запишите различия. Не выдавайте четыре учебных задачи за доказательство качества всех будущих ответов. Укажите ограничение набора и условия, при которых нужен новый цикл оценки.
Переведите наблюдение в рабочее правило
Допустим, B лучше связывает тесты с требованиями, но всё ещё пропускает побочный эффект отказа. Следующий шаг — добавить проверку состояния после 403, а не немедленно внедрять процесс без ревью. Для доступа можно сохранить обязательный контролируемый запрос; для SQL — прогон на фикстуре; для кода — компиляцию и запуск в разрешённой среде.
Журнал оценки полезен при обновлении помощника или требований. Он показывает, что нужно перепроверить и почему прежний артефакт считался приемлемым. Сохраняйте только необходимый безопасный контекст, без производственных логов и секретов. Результат урока — конкретное изменение процесса с известными пределами, а не рекламное обещание эффективности.
ЗАДАЧА
Оцени ответ по постоянной рубрике.
КОНТЕКСТ
Учебные OD-API-1 и OD-DATA-1. Оценка ответа не является прогоном продукта.
ВХОДНЫЕ ДАННЫЕ
Учебный контракт OrbitDesk OD-API-1. Это спецификация для упражнений, не действующий удалённый сервис.
Объект: {id, title, description, authorId, teamId, state: "draft" | "published"}.
POST /api/lab/tasks: нужна сессия. Тело: {title: string, description?: string}; description по умолчанию "". Title: 1–80 кодовых точек Unicode; description: 0–2000. Сохранение не обрезает пробелы. Сервер назначает authorId и teamId из сессии, state=draft. Поля authorId, teamId, state в клиентском теле отклоняются с 422. Успех: 201 и объект; ошибка типа или длины: 422.
GET /api/lab/tasks/{id}: без сессии — 401. Неизвестный объект, чужая команда или чужой draft — 404 без содержимого задачи. Собственный draft или published своей команды — 200 и объект. Editor не получает право читать чужой draft.
POST /api/lab/tasks/{id}/publish: пустое тело. Порядок проверки: 401 (нет сессии) → 404 (нет объекта или чужая команда) → 403 (не автор и не editor) → 409 (уже published) → 422 (title.trim() пуст) → 200. Роль editor разрешает отдельное действие publish для своей команды. Trim соответствует JavaScript String.prototype.trim. Успех меняет только state.
Ошибки: JSON {error:{code,message}}; code — машинный идентификатор, текст message может меняться. Любой отказ не изменяет существующие объекты и не создаёт новую задачу. Дублирование создания, редактирование, архивирование и повтор при потерянном ответе не специфицированы.
Даны только фрагменты двух учебных ответов; остальные строки пакетов не предоставлены. Время не измерялось.
A (всего заявлено 20 сценариев): «Вера editor из команды A читает draft t1 Анны: ожидаем 200 с объектом; основание — название роли editor».
B (всего заявлено 8 сценариев): «Вера читает draft t1 Анны: 404 без title и description по OD-API-1. Борис user публикует draft Анны: 403; после этого проверка заканчивается».
В обоих фрагментах для t1 не даны конкретные строки title/description. Не делайте вывод о тех частях ответов, которые не показаны.
Критерии: правильность прав, эффект операции, связь с правилом, выполнимость данных. Сравни только наблюдаемые свойства.
ОГРАНИЧЕНИЯ
Не выдумывай замеры. Обоснуй замечание конкретной фразой или пропуском. Не оценивай уверенный тон.
ОЖИДАЕМЫЙ ФОРМАТ
Критерий → наблюдение → оценка; критические ошибки; исправление; границы вывода.Используйте разрешённый ИИ-сервис. Не отправляйте рабочие секреты и персональные данные.
Источники и проверка фактов
ISTQB — CTFL v4.0, программа и материалыРазделы анализа и проектирования тестов; курс использует собственные учебные примеры, не является подготовкой к сертификации.OWASP API1: Broken Object Level AuthorizationПрава нужно проверять для конкретного объекта и действия на сервере; скрытая кнопка не является проверкой доступа.Playwright — Best PracticesПроверка пользовательского поведения, изоляция тестов, локаторы и повторяемые web-first assertions.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1