No-code тестирование: что оно решило, а что просто перенесло

Что no-code тестирование действительно решило

• Доступ к созданию тестов. Человек, который знает продукт, но не знает фреймворк, может собрать тест. Это правда, и это важно.

• Понятность для неинженеров. Визуальный сценарий понятен продакт-менеджеру так, как никогда не будет понятен файл с кодом.

• Первые тесты появляются быстрее. Время до первой работающей проверки заметно сократилось.

Что оно перенесло, а не убрало

Ничто из этого не смертельно. Именно поэтому обещание выглядит выполненным наполовину, и именно поэтому многие no-code наборы тестов перестают расти после первого квартала.

Допущение, на котором всё держится

No-code платформы исходят из того, что есть человек, чья работа — собирать тестовые сценарии. Там, где такая роль есть, они работают хорошо. Там, где её нет, платформа простаивает: разработчики визуальным редактором, как правило, пользоваться не станут, а больше некому.

Невыполнение этого допущения — самая частая причина, по которой no-code набор тестов перестаёт расти, и причина эта организационная, а не техническая.

Проблема передачи дел

У этой категории инструментов есть характерный сбой, который стоит предусмотреть заранее, потому что наступает он внезапно, а не постепенно.

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

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

Что меняет новое поколение

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

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

Ничего из этого не требует терминала. Создайте проект в дашборде TestSprite, опишите проверку обычными словами и направьте его на ваше приложение. Разработчики в вашей команде могут делать то же самое из командной строки, если им так удобнее, — это описано в репозитории CLI.

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

Что меняет описание проверки

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

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

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