Агент тестирования: три свойства, которые делают его полезным

Агент тестирования хорош ровно настолько, насколько хороши его отчёты о провалах

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

Это вдвойне важно, когда чинит кодинг-агент: он не может посмотреть на скриншот и догадаться о замысле. Просите показать настоящий провал, а не успешный прогон.

Второе: может ли проверка провалиться

Во время оценки сломайте что-нибудь намеренно. Сохранение, которое больше не сохраняет; фильтр, который молча возвращает всё подряд. Если проверка остаётся зелёной, она никогда не была связана с вашим продуктом.

Здесь возможны два варианта сбоя. Проверка, слишком расплывчатая, чтобы иметь исход, — и прогон, который завершается по таймауту, не дойдя до своих утверждений, но отмечается как успешный. Второй хуже, потому что выглядит как покрытие.

Третье: запускается ли он без просьбы

• Только по запросу. Полезен во время сессии, незаметен после.

• При изменении. Запускается по pull request или по деплою. Именно этот вариант вас защищает.

• По расписанию. Ловит дрейф окружения и изменения во внешних зависимостях.

Агент тестирования, который действует, только когда к нему обращаются, — это просто более удачный ручной тестировщик: польза в этом есть, но покупали вы не это.

За чем следить в первую неделю

Помимо трёх свойств, есть два наблюдения первой недели, по которым видно, сработает ли всё это.

Отражает ли созданное им покрытие ваш продукт — или форму вашей спецификации. Агент, работающий по документу API, добросовестно покроет каждый эндпоинт, включая те, которыми никто не пользуется, и пропустит единственное правило, которое живёт в комментарии. Прочитав первый план, вы поймёте, что у вас получилось, и исправить это на раннем этапе намного дешевле, чем на двухстах тест-кейсах.

И читает ли кто-нибудь отчёты о провалах. Агент тестирования даёт больше сигнала, чем ручной процесс, а сигнал, который никто не разбирает, — это просто издержки. Если через неделю провалы принимают к сведению, а не разбирают, дело обычно не в команде, а в формате отчёта о провале, и об этом стоит сказать, пока привычка не закрепилась.

Оценка за полдня

Опишите три сценария. Сломайте одну вещь. Влейте какие-нибудь изменения. Если агент ловит поломку, сообщает о ней так, что с этим можно работать, и замечает слияние без просьбы — он делает свою работу. Если хотя бы одно из трёх не выполняется, никакой список функций этого не компенсирует.

Если вы предпочитаете ничего не устанавливать, то же самое делает дашборд. Всё остальное, что умеет командная строка, — в репозитории CLI.

Триггер важнее механизма. Если нацелить его на событие деплоя, каждое изменение проверяется без чьего-либо отдельного решения; GitHub App делает это из дашборда, а шаг GitHub Actions — изнутри вашего workflow.

Как на эти три вопроса отвечает TestSprite

Провал возвращается как описание того, что пытались сделать, как повело себя приложение и где одно разошлось с другим, — в форме, с которой кодинг-агент может работать без того, чтобы это сначала истолковал человек. Проверки содержат конкретные утверждения, а прогон, который так и не дошёл до своих утверждений, не отмечается как успешный. И он запускается по изменению: подключите репозиторий — и прогоны будут стартовать от того деплоя, который ваш пайплайн и так создаёт.

Покрытие генерируется по вашему продукту и уточняется обычным языком, а при установке навык проверки добавляется в тот кодинг-агент, которым вы уже пользуетесь, — так что создание и запуск проверки происходят внутри работы, а не рядом с ней.

В итоге вы получаете пройденную оценку за полдня: агент ловит поломку, сообщает о ней так, что с этим можно работать, и замечает слияние без просьбы.