Инструменты автоматизации UI: три категории и допущения каждой из них

Три категории инструментов автоматизации UI

• Кодовые фреймворки. Вы пишете тесты на настоящем языке программирования. Допущение: инженеры, у которых есть время на написание и поддержку.

• Запись и low-code. Человек собирает сценарии в редакторе. Допущение: человек, чья работа — создавать тестовые сценарии.

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

Какое допущение не оправдывается чаще всего

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

Первое допущение не оправдывается медленнее. Инженеры действительно могут писать тесты, но это конкурирует с выпуском функций, поэтому набор тестов растёт первый квартал, а потом останавливается.

Вопросы, которые полезнее сравнительной таблицы

• Кто напишет двухсотый тест? Первые десять пишутся во время оценки. Спрашивайте про шестой месяц.

• Что произойдёт, когда UI переделают? Это и есть регулярные издержки, и ответ резко отличается от категории к категории.

• Как выглядит падение теста для того, кто будет его чинить? Всё чаще это кодовый агент, а он не умеет интерпретировать скриншот.

• Считается ли успешным прогон, который так и не дошёл до проверок? Это стоит проверить намеренно, потому что иногда ответ — да.

Издержки, которых нет в сравнении

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

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

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

Как проводить оценку

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

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

Два пути, и выбор здесь на самом деле о том, кто отвечает за пайплайн. Подключение GitHub App из панели управления не требует вообще никаких изменений в репозитории: оно реагирует на деплой, который ваша сборка и так выпускает. Добавление шага GitHub Actions помещает проверку в репозиторий, где она проходит ревью так же, как остальная сборка.

Какое допущение делает TestSprite

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

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

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