Что AI-агент для тестирования делает иначе
Выводит покрытие из вашего продукта. Из спецификации, документа с требованиями или из исследования работающего приложения, а не из того, что кто-то не забыл записать.
Описывает шаги как намерения. «Открыть страницу настроек» вместо пути по DOM — поэтому косметические переделки интерфейса обычно его не ломают.
Возвращает падение так, чтобы его можно было чинить. Что пытались сделать, что произошло, где одно разошлось с другим — в форме, с которой может работать другой агент.
Первый сбой: подгонка под проверку
Если попросить агента сделать так, чтобы тест проходил, он может пойти самым коротким путём — а подправить проверку иногда короче, чем починить продукт. Это не злой умысел, а недоопределённая задача.
Защита обходится дёшево. В каждой проверке называйте конкретную наблюдаемую величину и намеренно что-нибудь ломайте, чтобы убедиться: проверка умеет краснеть. Проверка, которая не может упасть, ничего не защищает.
Второй сбой: уверенное покрытие, которого никто не читал
Агент с удовольствием выдаст двести кейсов. Объём выглядит как прогресс, но покрытие, которое никто не просмотрел, — это покрытие, на которое нельзя положиться: вы не знаете, что именно оно утверждает.
Читайте план, а не код. Вычеркните служебные маршруты, добавьте продуктовые правила, которые нигде не записаны, и относитесь к этому как к пул-реквесту.
Чего он по-прежнему не умеет
Знать ваши бизнес-правила
Что должно произойти, когда применимы две скидки сразу, — это решение, а не то, что выводится.
Придумать сценарий злоупотребления
Авторизацию он проверит. А вот до сценария, который кто-то может обыграть в свою пользу, не додумается.
Починить сломанное окружение
Нестабильность из-за инфраструктуры так и останется нестабильностью.
Как эффективно просматривать план
Основная постоянная плата за такой способ работы — чтение покрытия, которое писали не вы; и именно небрежное чтение порождает оба сбоя выше. Есть быстрый метод.
Читайте только утверждения. На первом проходе полностью пропускайте шаги: шаги механические, а суждение живёт в утверждениях. Любое утверждение, которое оказалось бы истинным и для сломанного продукта, — это то, что нужно исправить; заметить такие легко, когда вы смотрите только на них.
Затем просмотрите список на предмет того, чего в нём нет, а не того, что есть. Сгенерированные планы стабильно полны по существующим эндпоинтам и столь же стабильно молчат о правилах, которые живут у кого-то в голове. Добавить три таких правила ценнее, чем поправить тридцать шагов.
С чего начать
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Ту же настройку можно выполнить в дашборде TestSprite, если вы не хотите ничего ставить локально. Остальные возможности CLI описаны в репозитории CLI.
Важнее триггер, а не механизм. Если привязать запуск к событию деплоя, каждое изменение проверяется без чьего-то отдельного решения; GitHub App делает это из дашборда, а GitHub Actions делает то же самое шагом внутри вашего рабочего процесса.
Что TestSprite делает как агент
Он выводит покрытие из ваших исходников и работающего приложения, описывает шаги как намерения, чтобы косметические изменения их не ломали, прогоняет тесты по развёрнутому приложению и возвращает падение в виде: что пытались сделать, что произошло и где одно разошлось с другим.
Установка добавляет навык проверки в тот кодовый агент, которым вы уже пользуетесь, так что всё это происходит внутри цикла, где пишется код, а не отдельным шагом, о котором кто-то должен вспомнить.
Ценность в том, что цикл замыкается. Изменение проверяется на работающем продукте, падение возвращается в виде, с которым агент может работать, а исправление подтверждается не теми же рассуждениями, которые его породили. На вас остаётся чтение плана и решение о том, что считать правильным, — это час в неделю, а не отдельная роль.
Чем это отличается от генератора тестов?
Генератор выдаёт код, который вы потом запускаете и поддерживаете. Агент ещё и запускает его, читает результат и может итерировать — именно это замыкает цикл.
Может ли он работать без спецификации?
Да — исследуя работающее приложение, хотя со спецификацией или документом с требованиями первый план получается лучше.
Сколько ревью ему требуется?
Прочитайте план перед первым прогоном и после каждой крупной перегенерации. В промежутках просматривайте новые кейсы так же, как просматривали бы код.
Что не даёт расходам разрастись?
Прогоны расходуют кредиты, поэтому перед долгой сессией договоритесь об ожиданиях. Агент, у которого есть инструмент проверки, будет им пользоваться — в этом и смысл, и это стоит заложить в бюджет.
Заменяет ли он QA-инженера?
Он заменяет рутинную половину. Определение того, что считать правильным, и умение мыслить как злоумышленник остаются человеческой работой — и это в любом случае более ценная половина.
Он решает, что проверять. Проверьте, что он решил.
AI-агент для тестирования выводит покрытие, описывает шаги как намерения и возвращает падения, с которыми можно работать. Защищайтесь от проверок, которые не могут упасть, и от покрытия, которого никто не читал, а бизнес-правила и сценарии злоупотребления держите в человеческих руках.