Введение: агент — не оракул
Представим обычную задачу «к тестированию». В ней есть краткое описание, несколько комментариев, ссылка на документ, родительская задача, пара коммитов и стенд, который иногда доступен. Часть требований уже изменилась. Часть — живёт в коде соседней команды. Часть — существует только как договорённость между людьми.
Можно потребовать от постановщика идеальный документ. Можно не начинать работу, пока не появятся критерии в правильной форме. В реальном проекте это часто означает не повышение качества, а перенос ответственности и задержку обратной связи.
Другой путь опаснее: дать языковой модели доступ к репозиторию и попросить «проверь задачу». Она быстро напишет убедительный отчёт. Но убедительность текста не равна доказанности результата.
Описываемый подход построен вокруг третьего пути. Он исходит из того, что входные данные почти всегда неполны и неоднородны. Поэтому агент не ждёт идеального источника и не выдаёт догадку за факт. Он собирает доступные свидетельства, строит явную модель ожидаемого результата, проверяет её несколькими независимыми способами, фиксирует границы знания и оставляет решение о приёмке человеку.
Это не история о том, что «ИИ заменил тестировщика». Это история о том, как сделать работу ИИ проверяемой, воспроизводимой и полезной в сложном процессе.
Инженерный контур в одном экране
Рассмотрим нейтральный контур агентной проверки задач. Это не библиотека для вызова модели и не один скрипт «получи задачу → напиши отчёт». Его упрощённая карта выглядит так:
agent-testing/ ├── AGENTS.md # точка входа и обязательный порядок работы агента ├── agent/ │ ├── skills/ # сценарии: требования, код, API/DB/UI, отчёт │ ├── rules/ # ограничения: безопасность, подтверждения, границы │ └── adapters/ # короткие надстройки конкретной агентной среды ├── config/ │ └── testing_project.yaml # проект: репозитории, среды, доступы, публикация ├── task_tools/ │ ├── testing/ # анализаторы, API/DB/UI-исполнители, валидаторы │ └── tracker/ # адаптер трекера задач ├── reports/task_testing/ # отчёты, планы и результаты проверок └── data/ # история, исходы, паттерны дефектов и уроки
Проектная конфигурация выбирает, какие репозитории и сервисы доступны агенту, какие действия разрешены и где хранить артефакты. Агент строит и анализирует план, а детерминированные исполнители запускают API-, DB- и UI-проверки и валидируют структуру отчёта. Артефакты не являются побочным эффектом: они становятся входом следующей проверки.
Из чего состоит контур
Это не «набор хороших подсказок» для одной модели. Контур объединяет сценарии работы агента, обязательные правила, конфигурацию проекта и детерминированные исполнители проверок. Они задают один маршрут: восстановить критерии, найти затронутый код, собрать доказательства, сформулировать границы вывода и сохранить результат так, чтобы его можно было перепроверить.
Для изменений, затрагивающих состояние и интерфейс, полезны независимые слои свидетельств: проверка программного интерфейса, чтение сохранённого состояния в базе данных и пользовательский сценарий в интерфейсе. Отдельно нужны механизмы безопасной публикации, валидации отчёта и обратной связи по фактическим исходам проверок.
Главная мысль: качество ответа агента определяется не моделью, а контуром проверки
Языковая модель хорошо умеет связывать разнородный контекст: текст задачи, историю изменений, код, тесты, результаты API-вызовов, состояние хранилища и пользовательские сценарии. Но сама по себе она не получает надёжного основания утверждать, что задача готова.
Для этого в описываемом контуре результат строится как цепочка:
Источники: задача, родительская задача, комментарии, вложения, документация, код, история и результаты проверок.
Модель приёмки: обязательное постусловие каждого критерия, его источник и способ доказательства.
Наблюдения: трассировка кода, существующие тесты, API-прогоны, независимая проверка сохранённого состояния в БД, UI-прогоны, анализ конфликтов.
Матрица доказательств: «критерий → факт из кода → исполняемый факт → что не доказано → вывод».
Отдельный, неблокирующий слой: проактивные наблюдения о лишнем ручном вводе — без превращения их в новые требования и без влияния на вердикт.
Решение с границами: выполнено, не выполнено или недостаточно данных; затем — калиброванная уверенность и ручной чек-лист.
Обратная связь: фактическое решение тестировщика возвращается в память процесса и меняет будущие проверки.
Представим критерий: «после сохранения формы новая связь доступна пользователю». Одного зелёного ответа 200 OK недостаточно: он может подтвердить только принятие запроса. Агент прослеживает, какой обработчик меняет состояние, составляет API-проверку, при необходимости подтверждает запись запросом только на чтение и завершает цепочку UI-сценарием. Если хранилище недоступно, это не превращается автоматически в дефект продукта: в отчёте остаётся честный пробел именно в доказательстве сохранённого состояния.
Здесь важно различать две вещи. Агент может принять операционное решение: какие источники читать, какую гипотезу проверить, какой сценарий запустить, хватает ли свидетельств для рекомендации. Но он не получает право самостоятельно принимать организационное решение о закрытии задачи, если проект не делегировал ему это действие и не включил явную публикацию. Финальная приёмка остаётся человеческой ответственностью.
Такой подход близок к модели риска NIST AI RMF: управлять контекстом, измерять риск, ограничивать действия и документировать последствия, а не надеяться на «правильность по умолчанию».
Какие методики тестирования здесь работают
Риск-ориентированное тестирование: проверять не всё, а самое опасное
Полное тестирование нетривиальной системы невозможно. Это не оправдание для поверхностной проверки, а причина осознанно выбирать глубину. ISO/IEC/IEEE 29119-2 определяет риск-ориентированное тестирование как управление, отбор, приоритизацию и использование тестовых ресурсов на основе проанализированных рисков. ISTQB формулирует тот же практический принцип: вместо попытки проверить всё нужно сочетать техники тест-дизайна, приоритизацию и анализ риска. Общий цикл выявления, оценки, обработки и мониторинга рисков не должен существовать отдельно от самих проверок.
В таком контуре это выражено не словом «риск» в конце отчёта, а последовательностью действий:
при массовой очереди сначала рассматриваются критичные модули, крупные изменения, миграции и задачи с историей возвратов;
связанные задачи упорядочиваются по зависимостям: библиотека или API → интеграция → интерфейс → сквозная функция;
прошлые возвраты и повторяющиеся классы дефектов повышают приоритет конкретных проверок;
риск не становится автоматически дефектом: он указывается отдельно от подтверждённого несоответствия.
Это особенно важно для ИИ-агента. Модель способна предложить десятки правдоподобных сценариев. Риск-ориентированный контур заставляет её объяснить, почему сценарий выбран, какое обязательство он проверяет и каким фактом будет подтверждён.
Исследовательское тестирование: работать при неполных требованиях, не притворяясь, что их нет
Исследовательское тестирование не является «бессистемным кликаньем». В нём проектирование и выполнение проверок развиваются вместе с получением новых наблюдений. Для крупномасштабных систем оно требует знания предметной области, ясных границ, понятного способа работы и фиксации результатов. Исследовательский и тест-кейсный подходы не исключают друг друга: первый помогает находить неизвестное, второй — стабильно перепроверять уже известное.
Такой контур переносит эту дисциплину в агентный процесс:
задача не считается пригодной к анализу только после идеального оформления;
все доступные источники собираются и ранжируются по силе;
противоречие между источниками не «сглаживается» удобной трактовкой, а становится ограничением вывода;
новая находка в коде порождает проверяемую гипотезу, а не готовый вердикт;
результат исследования превращается в артефакт, который может прочитать и оспорить человек.
Поэтому агент не говорит: «ТЗ плохое, вернитесь, когда исправите». Он говорит существенно более полезную вещь: «Вот обязательный результат, который удалось восстановить из имеющихся данных; вот источники; вот противоречие; вот что проверено, а вот что пока нельзя доказать».
Это не отменяет необходимости улучшать постановки. Но качество входной документации — риск процесса, с которым нужно работать, а не формальное условие, позволяющее снять с себя ответственность за анализ.
Тестирование по критериям приёмки и независимый тестовый оракул
Самый опасный сбой при ревью задачи — принять реализацию за требование. Если сначала увидеть diff, а затем сформулировать «что должно быть», критерий почти неизбежно сузится до того, что уже сделано.
До подробного чтения реализации в таком контуре строится независимая модель приёмки:
что является критерием или проблемой;
какое бизнес-постусловие обязательно;
из какого источника оно взято;
чем его можно доказать;
согласовано ли исключение.
После этого код — один из источников фактов, но не источник норматива. Успешный API- или UI-прогон также не равен автоматической приёмке: он подтверждает только то постусловие, которое действительно проверил.
Так появляется практический аналог тестового оракула: не «модель решила, что ответ выглядит хорошо», а заранее сформулированное наблюдаемое ожидание. Эту роль выполняет матрица приёмочных доказательств.
Системное и интеграционное мышление: проверять цепочку состояния
Многие дефекты возникают не внутри одного метода. Пользователь выполняет действие, фронтенд строит запрос, сервер изменяет состояние, данные попадают в производную модель, другой API их читает, а интерфейс отображает уже иной срез. Локальный unit-тест может быть зелёным на каждом участке, а пользовательский сценарий — неверным.
Поэтому для изменений состояния контур прослеживает цепочку:
действие → запрос → серверная обработка → запись → производные модели → API → отображение.
Между «API ответил» и «пользователь увидел» появляется ещё один независимый слой: read-only проверка сохранённого состояния в PostgreSQL. Если критерий требует доказать запись, связь или JSON в хранилище, а GET-ответ может скрывать рассинхрон, агент составляет план с запросами только на чтение. Исполнитель валидирует SQL, маскирует чувствительные поля и не выполняет мутации по умолчанию. Значения строк не должны попадать в отчёты как сырой дамп: в артефакте остаётся факт соответствия ожиданию, а не содержимое базы «для красоты».
Для экранов с несколькими источниками данных добавляется ещё один слой: поле интерфейса → бизнес-смысл → фактический источник → владелец источника → риск расхождения. Это помогает отличить косметическое исправление отображения от устранения причины и не спутать удобный endpoint с источником истины. То же относится к массовым операциям и сравнению с ближайшим рабочим аналогом: новая реализация не может быть единственным доказательством собственного критерия.
Такой анализ не требует заранее знать все доменные особенности конкретного проекта. Он требует уметь задать универсальные вопросы: где возникает состояние, кто его изменяет, где оно читается, в каком месте источники могут разойтись, какое наблюдение докажет нужное постусловие.
Классификация границ: не наказывать задачу за чужую работу
Обратная ошибка — требовать от любой задачи полноценный пользовательский сценарий. Библиотечная, серверная, миграционная или интеграционная задача может быть завершена корректно, хотя отдельная фронтовая задача ещё не сделана.
Перед анализом агент формирует «паспорт области проверки». Он отдельно фиксирует:
способ поставки: самостоятельная, агрегирующая или смешанная задача;
область результата: компонент, backend целиком, frontend целиком, интеграция целиком или бизнес-функция целиком;
обязательные зависимости;
проверки совместимости;
контекст, который не входит в критерий текущей задачи.
Это не бюрократия ради отчёта. Паспорт не позволяет выдать риск соседнего слоя за дефект текущей работы и, наоборот, не позволяет назвать незавершённую сквозную функцию «готовой» только потому, что один компонент реализован.
Стандарт ISO/IEC 25010 полезен здесь как язык качества: он связывает тестовые цели не с абстрактным «всё работает», а с конкретными характеристиками продукта — функциональной пригодностью, производительностью, совместимостью, надёжностью, безопасностью и другими.
Проактивный UX без выдуманных требований
Есть ещё один типичный провал агентного тестирования: модель начинает «улучшать продукт» поверх постановки. Она замечает неудобство, превращает его в дефект и снижает процент — хотя владелец продукта такого критерия не задавал.
После анализа реализации агент может задать доказанный вопрос: не просит ли интерфейс вручную ввести значение, которое система уже однозначно выводит из известного контекста? Но у этого шага жёсткие границы:
наблюдение не входит в матрицу приёмки;
оно не меняет критерии, процент, вердикт, блокеры и статус;
без доказанного системного правила и проверки однозначности вопрос не формируется;
предпочтительный вариант улучшения не выдаётся за ожидаемое поведение.
Иными словами, агент может быть полезным собеседником о качестве опыта, не становясь самоназначенным владельцем продукта. Если наблюдение подтверждено, оно попадает в отчёт и комментарий отдельным пунктом — как вопрос к людям, а не как приговор задаче.
Какие методики применены в работе с ИИ-агентом
Цикл «гипотеза → действие → наблюдение»
Работа агента близка к подходу ReAct: модель чередует гипотезы и действия, а действия возвращают новые наблюдения из внешней среды. В тестировании это выглядит так:
сформулировать проверяемую гипотезу;
прочитать задачу или код, выполнить безопасный инструментальный запрос;
получить наблюдение;
скорректировать план проверки;
сохранить факт и перейти к следующему вопросу.
Сильная сторона такого подхода не в том, что модель «думает вслух». Сильная сторона в том, что гипотеза привязана к наблюдаемым данным, а не остаётся красивым продолжением исходного текста. Агент не обязан верить задаче, коду или комментарию по отдельности: он сопоставляет их.
Планировщик, исполнители и координатор
Контур может работать с одним агентом или с несколькими. Во втором случае после формирования области и критериев независимые задачи — поиск затронутого кода, анализ покрытия и предварительная проверка конфликтов — могут выполняться параллельно. Координатор остаётся владельцем границ, модели приёмки, оценки уверенности и итоговой рекомендации.
Это принципиально. Несколько агентов полезны не потому, что их выводы можно механически усреднить. Они полезны, когда роли разделены, а синтез делает субъект, видящий общую модель задачи. Иначе мультиагентность превращается в несколько независимых галлюцинаций вместо одной проверяемой системы.
Рефлексия: как прошлый промах становится следующей проверкой
Слово «рефлексия» рядом с ИИ легко превращается в маркетинговое обещание: будто система сама становится умнее после каждого диалога. В инженерном контуре полезнее понимать его строже. Рефлексия — это замкнутый цикл, в котором первоначальная рекомендация агента сопоставляется с независимым решением тестировщика, а расхождение превращается в проверяемое правило следующей проверки.
Цикл выглядит так:
рекомендация агента ↓ фактическое решение тестировщика ↓ был ли пропущен факт или неверен вывод? ↓ формализация урока и, при повторяемости, паттерна дефекта ↓ дополнительная гипотеза и сценарий в следующей похожей задаче ↓ новые наблюдения по текущему коду и стенду
После проверки процесс сохраняет:
отчёт и доказательства;
оценку уверенности и риски;
фактический исход из трекера;
пропущенный факт и вывод из пропуска;
повторяющиеся классы дефектов;
историю затронутых областей, файлов и контрактов.
Здесь важен порядок. Сам по себе комментарий тестировщика ещё не становится правилом. Если задача возвращена или принята с замечанием, запись получает статус «требует формализации». Человек или агент должен явно указать пропущенный факт и объяснить, почему прежняя цепочка рассуждений не привела к верному выводу. Только после этого урок считается записанным. Повторяемый урок можно обобщить в паттерн: условия возникновения, сигналы в коде или результатах проверок и рекомендуемые сценарии.
На следующей задаче такая память не выносит вердикт и не доказывает дефект. Она помогает выбрать, что дополнительно проверить. Паттерн превращается в обязательную эскалацию только после того, как его сигналы подтверждены текущими фактами — кодом или исполняемой проверкой. Поэтому прошлый опыт не подменяет независимую модель приёмки и не позволяет объявить похожий код ошибочным по аналогии.
Этот механизм близок к идее Reflexion: прошлый опыт переводится во внешний, проверяемый контекст следующего эпизода, а не требует переобучать веса модели. Но термин надо использовать точно: контур не обучает базовую языковую модель. Он формирует управляемую память процесса тестирования.
Такое различие важно для аудита. Можно увидеть исходную рекомендацию, последующее решение тестировщика, пропущенный факт, сформулированный урок и его применение в следующем плане. Можно также измерить, уменьшается ли число повторных пропусков. Нельзя честно сказать то же самое о неявном «опыте» модели после разговора.
Калиброванная уверенность вместо псевдоточной оценки
Число процентов в отчёте не делает вывод математически точным. Но оно полезно, если отвечает на один и тот же вопрос: «насколько доказано выполнение обязательного результата этой задачи?» — и если его нельзя повысить успешным прогоном не того слоя.
В таком контуре уверенность ограничивается правилами:
невыполненный обязательный критерий исключает положительный вердикт;
недоказанный ключевой критерий ведёт к предварительному выводу или формулировке «недостаточно данных»;
техническая ошибка тестового инструмента не приравнивается к дефекту продукта;
несколько коррелированных сигналов одной причины не должны уменьшать оценку несколько раз;
история возвратов и формализованные пропуски снижают допустимую уверенность в похожих сценариях.
Отдельно усилен слой UI. Если обязательный UI-сценарий упал из‑за селектора, плана, SSO, учётной записи или окружения, это сначала диагностируется и устраняется с повторным запуском до продуктового постусловия. Техническое ограничение остаётся в итоговом отчёте только при жёстком блокере: недоступный стенд, отсутствующая роль или невозможность запустить Playwright после попыток устранения причины. Иначе агент слишком легко «списывает» пробел доказательств на инфраструктуру.
Это не статистическая гарантия. Для неё нужны калибровочные данные, достаточная выборка и отдельная оценка точности прогнозов. Но это уже лучше распространённой альтернативы: поставить 90% потому, что текст отчёта выглядит уверенно.
Безопасность действий и человек в контуре
Система различает чтение, локальное формирование артефакта и внешние мутации. Комментарий в трекере, смена статуса, запись в Git и действия в тестовой среде управляются независимыми настройками и при необходимости требуют явного подтверждения.
У каждого сервиса конфигурация задаёт среду, профиль доступа и разрешение мутаций. Секреты не попадают в планы, отчёты и отслеживаемые файлы. Если стенд, роль или репозиторий недоступны, это фиксируется как ограничение доказательств, а не замалчивается. Для БД по умолчанию разрешено только чтение; отдельный профиль записи, если он вообще нужен, требует точного хеша плана и атомарной транзакции.
Именно так человеческий контроль становится не декоративной фразой «проверяйте ответы ИИ», а набором технических ограничений. NIST AI RMF и профиль для генеративного ИИ требуют определять роли в конфигурации «человек–ИИ», обеспечивать надзор, вести документацию и соизмерять независимую оценку с риском.
Как агент действует при плохих источниках
Можно возразить: если требования неполны, агент всё равно будет ошибаться. Да. Но это не аргумент в пользу бездействия или в пользу оформления формального отказа.
Контур принимает неполноту входных данных как исходное условие и работает с ней открыто:
Собирает несколько источников, а не требует один «правильный» документ.
Показывает происхождение критерия: задача, родитель, вложение, документация, согласованное изменение.
Разводит факт и интерпретацию: текущий код описывает реализацию, но не отменяет исходный бизнес-критерий.
Фиксирует противоречия и не выбирает удобное значение молча.
Превращает дефицит данных в конкретный вопрос: какой доступ, тестовые данные, роль или решение владельца нужны, чтобы закрыть пробел.
Не перекладывает ответственность: агент формирует доступный вывод и честно обозначает его границы, а не сводит весь результат к требованию «сначала оформите источники».
Это не означает, что любая двусмысленность должна решаться моделью. Если источники конфликтуют по ключевому постусловию, корректный ответ — не выдуманный критерий, а предварительный вывод с явно указанным конфликтом. Неполнота данных не даёт агенту права фантазировать; она требует более дисциплинированной работы с доказательствами.
Полезно различать и типы неопределённости. Дефицит знания — например недоступный стенд, неполная постановка или конфликт документов — не является отрицательным результатом продукта. Это основание явно снизить уверенность, запросить данные либо эскалировать решение.
Почему подход переносим, а не привязан к одному отделу
Узко спроектированный агент обычно хранит в промпте имена репозиториев, URL стендов, роли, статусы трекера и частные правила продукта. Он быстро полезен в одном месте, но плохо переносится: при первом новом проекте приходится переписывать логику.
Переносимый контур полезно разделить на четыре слоя:
Движок: нейтральные сценарии агента, правила, исполнители анализа, API/DB/UI-проверок, отчётов и обратной связи.
Конфигурация проекта: репозитории, ветки, трекер, источники документации, среды, сервисы, профили доступа, разрешённые переходы и политика публикации.
Секреты: только локальные файлы или переменные окружения.
Артефакты отдела: отчёты, история, исходы, паттерны дефектов и уроки.
В переносимой реализации конфигурация не должна содержать встроенных имён проектов, репозиториев, стендов, маршрутов, ролей и статусов. Новая команда выбирает локальное или общее хранение артефактов и подключает только нужные адаптеры. Внешние действия можно полностью отключить.
Конфигурационный контракт может предусматривать разные трекеры, однако конкретная реализация всегда ограничена набором доступных адаптеров. Поэтому корректно говорить о переносимом ядре и расширяемой схеме интеграции, а не об универсальной поддержке произвольных трекеров без дополнительной работы.
Состав реализации стоит фиксировать манифестом происхождения и контрольными суммами, исключая секреты, личные отчёты и данные исходной команды. Это защищает от двух типичных проблем: ручных копий, которые расходятся, и «универсальности», в которую незаметно вшит один конкретный процесс.
Универсальность здесь не означает, что один YAML-файл решит всё. Она означает другое: постоянны вопросы процесса, а не ответы предметной области. В любом проекте агенту нужно определить границу результата, источник критерия, путь состояния, доказательства, риски, ограничения и способ обратной связи. Меняются трекер, репозитории, сервисы и терминология — но не логика инженерной проверки.
И это сложнее, чем автоматизировать один привычный маршрут. Универсальное решение обязано явно вынести наружу то, что в узком инструменте можно было бы спрятать в код: конфигурацию, допуски, адаптеры, политику публикации и границы ответственности.
Что действительно стоит измерять
Нельзя доказать пользу агентного контура количеством сгенерированных отчётов или найденных слов в коде. Проверять нужно не красоту текста, а изменение качества решений.
Для пилота разумно заранее зафиксировать:
долю задач, возвращённых после рекомендации агента;
долю пропущенных фактов и ложных тревог;
калибровку уверенности: различаются ли оценки у принятых и возвращённых задач;
время до первого содержательного тестового вывода;
долю критериев, имеющих исполняемое или независимое доказательство — включая случаи, где API недостаточно и нужна проверка хранилища;
долю «ложных дефектов», рождённых из UX-наблюдений без критерия в постановке;
долю возвратов и замечаний, для которых формализованы пропущенный факт и вывод;
повторяемость классов дефектов и то, уменьшается ли число повторных пропусков после добавления уроков;
трудозатраты человека на финальную проверку и разбор отчёта.
Нужна и оговорка о причинности. Изменение этих метрик может быть связано с составом задач, зрелостью команды, изменением стенда или сезонностью, а не только с агентом. Поэтому сильное утверждение требует плана сравнения: исходного периода, сопоставимых групп задач, правил исключения и качественного разбора аномалий.
ИИ становится сильным не там, где ему дают неограниченную автономию, а там, где его сильные стороны — чтение контекста, поиск связей, формирование гипотез и работа с инструментами — заключены в хорошо спроектированный контур доказательств и ответственности.
Вместо вывода
Самое ценное в агентном тестировании — не способность быстро написать отчёт. Отчёт может написать почти любая модель.
Ценность возникает, когда система умеет ответить на более трудные вопросы:
что именно сейчас проверяется;
откуда взялся каждый критерий;
какое наблюдение подтверждает или опровергает его — в коде, через API, в хранилище или в интерфейсе;
где заканчивается факт и начинается предположение;
какой риск относится к текущей задаче, а какой — к соседней;
можно ли улучшить опыт пользователя, не выдавая улучшение за обязательный критерий;
почему агенту можно доверить очередное действие, но нельзя безусловно доверить финальное решение;
чему процесс научился после собственной ошибки.
Описанный контур — попытка зафиксировать эти вопросы в воспроизводимом процессе. Не как универсальную замену людям и не как обещание идеальных входных данных, а как инженерный способ сделать ИИ-агента ответственным участником реальной, несовершенной разработки.
Если хочется углубиться
ISO/IEC/IEEE 29119 — международный стандарт процессов тестирования.
ISTQB Foundation Level — краткая база по рискам, техникам и организации тестирования.
NIST AI RMF — про риск, прозрачность и контроль ИИ-систем.
ReAct — модель цикла «рассуждение → действие → наблюдение».
Reflexion — идея внешней памяти и извлечения уроков из ошибок.