Цель урока
Перестать оценивать помощника по одному удачному диалогу и перейти к системному тестированию.
1. Удачный ответ ничего не доказывает
Если помощник один раз сделал хорошее письмо, это не значит, что он:
- задаст вопрос при пропущенной цене;
- не придумает факт;
- правильно обработает конфликт данных;
- откажется от выхода за роль;
- сохранит формат на сложном запросе.
2. Четыре типа тестов
Нормальный кейс. Все данные есть, стандартная задача.
Неполный кейс. Не хватает критической информации. Ожидается вопрос или плейсхолдер.
Конфликтный кейс. Два входных факта противоречат друг другу. Помощник должен остановиться и указать конфликт.
Пограничный кейс. Пользователь просит то, что выходит за роль или требует внешнего действия.
3. Структура тест-кейса
- ID;
- сценарий;
- вход;
- ожидаемое поведение;
- запрещённое поведение;
- критерии проверки;
- результат: pass/fail;
- комментарий.
4. Метрики без вымышленных процентов
На первом этапе не нужен искусственный «accuracy 97%». Достаточно операционных критериев:
- задал ли обязательный вопрос;
- сохранил ли формат;
- отметил ли неизвестное;
- не придумал ли факт;
- соблюдал ли границу;
- можно ли использовать результат после человеческой проверки.
5. Regression-тест
После изменения инструкции повторите ключевые тесты. Иначе исправление одного сценария может сломать другой.
Практика
Создайте 10 тестов в шаблоне «Test Cases Template» из раздела «Файлы урока»: минимум 4 нормальных, 2 неполных, 2 конфликтных, 2 пограничных.
Ключевая мысль
Помощник готов не тогда, когда вам понравился ответ, а когда он предсказуемо проходит заранее определённые сценарии.