Тест-дизайн по требованиям

Тест-дизайн — самая «ручная» часть работы QA и одна из самых выгодных для агента. Codex быстро раскладывает требование на классы эквивалентности и границы, но так же быстро додумывает то, чего в требовании нет. Разберём порядок работы, при котором агент ускоряет вас, а не подменяет ваше понимание продукта.

Сразу оговорка: у OpenAI нет официального руководства по тест-планам. В гайде компании описано, как инженеры вставляют в Codex запрос пользователя или спецификацию и получают черновик (How OpenAI uses Codex). Всё остальное в этом уроке — методика курса.

Шаг 1. Сначала вопросы, потом кейсы

Требование из задачи в Kaiten почти всегда неполное. Если сразу попросить «напиши тест-кейсы», агент молча закроет пробелы своими предположениями, и вы получите аккуратный список проверок несуществующего поведения.

Поэтому первый проход — поиск дыр. Гайд по лучшим практикам Codex советует для неоднозначных задач режим планирования (/plan или Shift+Tab) и просьбу к агенту сначала задать вопросы (Best practices). Для тест-дизайна это подходит идеально.

/plan Ниже требование к форме заявки на сайте. Не пиши тест-кейсы.
Сначала:
1. Перечисли неоднозначности и пропуски: что не определено для пустых значений,
   границ длины, форматов, ошибок сервера, повторной отправки, мобильной версии.
2. Для каждого пункта задай мне вопрос и предложи вариант по умолчанию.
3. Отдельно — что в требовании противоречит макету (скриншот приложен).

<текст требования из задачи>

Скриншот макета можно приложить прямо в CLI: codex -i form.png или вставкой в поле ввода. Ответы на вопросы — это материал для аналитика и менеджера, а не только для вас: половина багов закрывается ещё до кода.

Шаг 2. Техники — называйте явно

Попросите применить конкретные техники, иначе агент выдаст «позитивный кейс, негативный кейс, пустое поле» и остановится.

По уточнённому требованию составь проверки, используя:
- классы эквивалентности и граничные значения для каждого поля;
- таблицу решений для комбинации «email / телефон / согласие на обработку»;
- переходы состояний формы: пустая → заполняется → отправка → успех / ошибка → повтор;
- попарное тестирование для браузер × размер экрана × способ ввода.
Для каждой проверки укажи: ID, требование-источник, предусловия, шаги, ожидаемый результат.
Не добавляй проверки поведения, которого нет в требовании, — вынеси их в отдельный
список «предлагаю уточнить».

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

Шаг 3. Трассируемость

Набор проверок полезен, только если видно, что ничего не потеряно. Попросите таблицу покрытия:

Затем — обратный вопрос: «Какие требования не покрыты ни одной проверкой и какие проверки не ссылаются ни на одно требование?» Вторая группа — либо лишнее, либо скрытое требование, которое стоит записать.

Если чек-лист нужно загрузить в систему управления тестами, попросите CSV с колонками вашей системы. Для автоматического конвейера можно получать кейсы в JSON по схеме через codex exec --output-schema — это разобрано в уроке «Ответ по схеме».

Шаг 4. Приоритеты — ваша работа

Агент не знает, что форма заявки — главный источник лидов, а страница «О компании» меняется раз в год. Приоритет по риску ставите вы: вероятность поломки × цена поломки. Агенту можно дать подсказку, где искать вероятность:

Посмотри git log и историю правок в src/plugins/<vendor>/<plugin>/components/LeadForm
за последние полгода. Какие части формы менялись чаще всего и в каких коммитах
упоминаются исправления? Используй это как сигнал риска, не как вывод.

Частота правок и прошлые фиксы — объективные данные. Цену поломки знаете только вы и бизнес.

Ловушка: дизайн по коду, а не по требованию

Если агент видит реализацию, он охотно строит проверки по ней: читает валидатор, видит лимит в 255 символов и предлагает проверить 255 и 256. Звучит разумно, но такой тест подтверждает, что код делает то, что делает. Если в требовании было 100 символов, баг станет «ожидаемым поведением».

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

Для мобильных приложений

Тот же порядок работает для мобайла, но добавьте в промпт измерения, о которых агент сам вспоминает редко: сворачивание и возврат в приложение, потеря сети посреди отправки, разрешения ОС, разные размеры экрана и тёмная тема, обновление со старой версии. Чем конкретнее список измерений, тем полнее матрица.