Лучший инструмент ИИ-тестирования для трёх разных пробелов

  • Объём. «У нас почти нет тестов». Вам нужна генерация. Учитывайте, что сгенерированные тесты наследуют допущения самого кода.

  • Сопровождение. «Половина набора красная по причинам, не связанным с продуктом». Вам нужно адаптивное выполнение. Проверьте, что оно падает на изменении поведения, а не просто переживает косметические правки.

  • Доверие. «Тесты зелёные, релизы всё равно ломаются, большую часть кода пишет агент». Вам нужна проверка на работающем продукте.

Вопрос, который разделяет кандидатов

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

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

Второй вопрос

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

Ловушка, общая для всех категорий

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

Демонстрационный трюк, о котором стоит знать

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

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

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

Как проводить оценку по-настоящему

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

Терминал

npm install -g @testsprite/testsprite-cli
testsprite setup

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

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

Под какой пробел создан TestSprite

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

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

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

Какой инструмент действительно лучший?

Для объёма — инструменты генерации. Для сопровождения — адаптивные раннеры. Для доверия к коду, написанному агентом, — проверка на работающем продукте. Сначала назовите свой пробел.

Может ли один инструмент закрыть все три?

Отчасти — и то, вокруг чего он спроектирован, всегда заметно. Спросите, по каким метрикам продукт оценивает сам себя, и вы поймёте, под какую задачу он создавался.

На какие затраты рассчитывать?

Сравнивайте полную стоимость, а не стоимость лицензии. Дешёвый инструмент, которому нужен инженер на сопровождение, дешёвым не является.

А как насчёт бесплатных вариантов?

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

Сколько должна длиться оценка?

Достаточно долго, чтобы в неё попали настоящий релиз и настоящая регрессия. Без них вы оценили только онбординг.

Коротко

Назовите пробел, прежде чем составлять шорт-лист.

Лучший инструмент ИИ-тестирования зависит от того, в чём ваш пробел: в объёме, сопровождении или доверии. Спросите, как выглядит падение, заканчивается ли первая сессия проверкой в вашем пайплайне, и намеренно сломайте что-нибудь во время пробного периода.