AI-тестирование: три разных вещи, которые под этим понимают

Почему «AI-тестирование» — бесполезная категория

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

Первый вид: AI, который пишет тесты за вас

Какую проблему решает: у вас есть код без тестов, а писать их руками медленно и скучно.

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

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

Это вам нужно, если: ваш пробел — это объём. Есть большой массив непокрытого кода, и ни у кого нет времени.

Второй вид: AI, который запускает и поддерживает тесты

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

Как это выглядит: раннер подстраивается, когда интерфейс смещается. Кнопка, у которой изменилась подпись или позиция, всё равно находится, потому что шаг понимается как намерение, а не как жёсткий путь по DOM.

Где проходит граница: адаптация — палка о двух концах. Набор тестов, который «чинит» себя в обход настоящей регрессии, хуже упавшего набора: он прячет ровно то, что вы хотели узнать. Полезная версия отличает изменение интерфейса от изменения поведения и прощает только первое.

Это вам нужно, если: ваш пробел — это поддержка. Тесты есть, а налогом стало удержание их зелёными.

Третий вид: проверка кода, который написал AI

Какую проблему решает: ваша команда выкатывает код от кодинг-агента быстрее, чем кто-либо успевает его прочитать, и ревью, которое раньше ловило ошибки, незаметно превратилось в формальность.

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

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

Это вам нужно, если: ваш пробел — это доверие. Объём кода вырос, пропускная способность ревью — нет, и никто не может уверенно сказать, сломали ли что-нибудь последние двадцать слияний.

Какой вид AI-тестирования нужен именно вам

Короткая диагностика — в том порядке, в котором стоит задавать вопросы.

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

Один вопрос, который отделяет серьёзные инструменты от демо

Какой бы вид вы ни рассматривали, спросите, что происходит при падении.

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

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

Второй вопрос: работает ли это без вас

Любая из этих категорий обращается в ноль, если тесты запускаются только тогда, когда кто-то о них вспомнит. Набор тестов, который срабатывает по расписанию или на каждый pull request, делает работу. Набор, который ждёт, пока его запустит человек, — это документ о работе, которую кто-то собирался сделать.

Поэтому вопрос при внедрении не в том, у какого инструмента приятнее синтаксис проверок. Вопрос в том, какой из них завершает первую сессию проверкой, встроенной в ваш пайплайн, а не отчётом на экране.

Где во всём этом мы, если прямо

TestSprite сделан для третьей проблемы. Он открывает ваше работающее приложение, пользуется им как настоящий пользователь и возвращает всё сломавшееся одним пакетом, с которым может работать ваш кодинг-агент. Он и кейсы генерирует, но это служит проверке, а не является её смыслом.

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

Для какой из трёх задач сделан TestSprite

Для третьей. TestSprite существует для команд, у которых тесты зелёные, релизы всё равно ломаются, а код всё чаще приходит от агента быстрее, чем кто-либо успевает его отревьюить.

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

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