Где ИИ помогает, а решение остаётся за QA

Начните с результата, который можно проверить

ИИ полезен, когда помогает преобразовать уже известный материал: сгруппировать вопросы к требованиям, найти дубли в наборе, предложить альтернативные значения или привести записи к заданному формату. Это не снимает с QA обязанности установить ожидание. Если исходное правило неизвестно, модель может предложить правдоподобную договорённость, но не сделать её требованием проекта. До запроса сформулируйте, что вы собираетесь проверить после ответа и какие решения пока не готовы принимать.

Для OrbitDesk хорошая первая задача — выделить ограничения полей и вопросы к видимости черновика. Результат можно сопоставить с четырьмя правилами. Плохая первая задача — попросить модель единолично принять решение о выпуске: нет ни фактической сборки, ни выполненных сценариев, ни согласованных критериев риска. Формулировка «найди все ошибки» также не задаёт наблюдаемого результата.

Оракул важнее убедительного текста

Оракул тестирования — основание ожидаемого результата. В этом учебном кейсе им служит текст F1–F4. На реальном проекте это могут быть согласованное правило, контракт API, вычислимая модель или проверенный пример. Ответ модели сам по себе не становится таким основанием. Даже ссылка в ответе требует проверки: откройте документ, найдите относящийся фрагмент и убедитесь, что он применим к нужной версии.

Представьте ответ: «Только editor публикует задачи, пустое описание запрещено, 81 символ допускается после предупреждения». В нём сразу три разные проблемы. Право публикации editor не описано в переданном сокращённом фрагменте: это вопрос к полному контракту, а не подтверждённое правило для этого анализа. Запрет пустого описания противоречит F2. Допуск 81 символа противоречит F1 для примеров с однозначным подсчётом. Каждое замечание имеет своё основание; общего «ИИ ошибся» для рабочего разбора мало.

Разберите утверждение по типу

Не путайте предложение с выполненной проверкой

Список сценариев ещё не доказывает поведение приложения. Запись «ожидается отказ в доступе» не сообщает, был ли отправлен запрос и изменилось ли состояние сервера. В своём артефакте различайте спроектировано, выполнено и подтверждено результатом. Модель, которой не давали доступ к стенду, не могла выполнить тест. Красивый отчёт с зелёными отметками без доказательств нужно вернуть на переработку.

Делегируйте небольшой фрагмент, проверяйте его и только затем расширяйте задачу. Сначала возьмите поля формы; потом отдельно видимость и роли. Такая последовательность позволяет локализовать неверное допущение и не переносить его во весь набор. Сохраните исходник, запрос и принятое исправление: это делает решение объяснимым другому участнику команды и помогает отличать изменение требований от случайной вариации ответа.