RTHelper: я делаю инструмент, который превращает ручные UI-проверки в автотесты без кода

В тестировании есть неприятный промежуток между ручной проверкой и нормальной автоматизацией. С одной стороны, руками проходить регресс долго и скучно: открыть форму, ввести данные, нажать кнопку, проверить текст, повторить это на следующем билде. С другой стороны, полноценные автотесты требуют времени, кода, инфраструктуры и поддержки. В итоге часть сценариев живет в состоянии «когда-нибудь автоматизируем», но пока их снова и снова гоняют вручную. Я делаю RTHelper, чтобы закрыть именно этот промежуток. Идея простая: взять знакомый ручной тест-кейс и собрать из него исполняемый сценарий без обязательного написания кода. Не как большая RPA-система на все случаи жизни, а как рабочий помощник для QA: захватить элементы интерфейса, выстроить действия, добавить ожидания и проверки, запустить сценарий, посмотреть понятный отчет о том, где все прошло, а где упало. Сайт проекта: https://rthelper.ru/docs.html

Как я к этому пришел

Изначально мне нужно было сделать утилиту для взаимодействия с UI-элементами в Windows и браузерах. Задача не была напрямую связана с тестированием, но оказалось, что сама идея очень близка к автоматизации рутинных действий: найти кнопку, нажать, прочитать текст, дождаться состояния, повторить. Потом я начал смотреть на это уже глазами тестировщика. Если сценарий можно описать как цепочку «элемент + действие + проверка», почему бы не дать человеку собрать такую цепочку визуально? Так проект постепенно вырос из эксперимента в отдельное приложение.

Что уже работает

Сейчас RTHelper работает с двумя основными типами интерфейсов:

1. Web: сценарии поверх сайтов и веб-приложений через браузерное расширение для Chrome/Edge/Firefox/Yandex...
2. Windows UIA: сценарии для desktop-приложений через UI Automation

Типовой путь выглядит так:

1. Выбираете режим Web или UIA.
2. Добавляете приложение или страницу в дерево.
3. Захватываете нужные поля, кнопки и текстовые элементы.
4. Перетаскиваете их в алгоритм.
5. Назначаете действия: Click, Write, Read, Wait, Assert и другие.
6. Запускаете сценарий обычным запуском или в Debug.

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

Самая сложная часть: не кликнуть, а стабильно найти элемент

В UI-автоматизации основной враг не сам клик. Основной враг — нестабильность интерфейса. Кнопка может переехать. Страница может грузиться дольше обычного, id у элемента может генерироваться фронтендом. В Windows-приложении AutomationId может быть пустым или повторяться. В таблице может быть десять одинаковых кнопок «Открыть». Поэтому RTHelper сохраняет не указатель на элемент, а набор признаков, по которым его можно найти заново: тип, имя, id, class, role, текст, родительский контейнер, положение в дереве и другие атрибуты. Пользователь может уточнить, какие признаки важны, ограничить область поиска, использовать индекс совпадения, подсветить найденные элементы и понять, слишком широкий локатор получился или слишком строгий. Я не хочу делать вид, что это магия. Иногда локаторы все равно приходится настраивать руками. Но цель инструмента — сделать эту настройку наглядной, а не прятать проблему до первого падения на регрессе.

Почему сценарий должен быть не просто записью кликов

Записать клики легко, а получить полезный тест сложнее. Если сценарий нажал «Сохранить», это еще не значит, что проверка прошла. Нужно дождаться результата и явно проверить, что появилось сообщение, изменился статус, API вернул нужное значение или экран визуально соответствует ожиданию. Поэтому в RTHelper рядом с обычными UI-действиями есть:

1. Wait: ждать не секунды, а состояние элемента
2. Assert: сравнивать фактический результат с ожидаемым
3. LoadData: вносить тестовые данные из CSV/XLS/XLSX
4. API-шаги: отправлять HTTP-запросы и проверять ответ
5. Скриншот-тестирование: сравнивать весь экран или выбранную область с эталоном
6. Debug и breakpoint: пошагово разбирать, где сценарий повел себя не так

Отчеты и регулярные запуски

Отдельный блок, который я активно развиваю, — история запусков и отчеты. Когда сценарий падает, мало увидеть «шаг 17 не прошел». Нужно понять, что это был за шаг, какой элемент искался, сколько он ждал, какой результат вернулся и какая ошибка была первой. В приложении есть журнал выполнения, история запусков, скриншоты при падении и студия запусков. В студии можно собрать несколько сценариев в набор: например, smoke перед релизом или небольшой регресс авторизации, платежей и профиля. Результаты можно выгружать в JSON, JUnit XML и Allure, чтобы не запирать пользователя внутри программы и дать возможность подключать сценарии к привычному процессу.

Для чего это

Я не позиционирую RTHelper как замену Playwright, Selenium, Appium или нормальному тестовому фреймворку в команде, где автоматизация уже хорошо выстроена. Скорее это инструмент для ситуаций, где:

1. есть много повторяющихся ручных проверок
2. автоматизация кодом пока не начата или постоянно откладывается
3. QA хочет быстро проверить гипотезу на реальном сценарии
4. нужен понятный визуальный тест, который можно обсудить с командой
5. часть проверки живет в Windows-приложении, а часть в браузере
6. хочется начать без кода, но при необходимости иметь мост к отчетам и C#

У инструмента есть ограничения: он не отменяет необходимость думать о стабильных локаторах, не все старые desktop-интерфейсы хорошо отдают дерево элементов, визуальная сборка не всегда лучше кода. А если сценарий становится слишком сложным, его, возможно, честнее перенести в полноценный автотест. Мне кажется важным говорить об этом заранее, потому что иначе no-code-инструменты быстро превращаются в завышенные ожидания.

Что хочу от публикации

Мне очень нужна обратная связь от тех, кто каждый день работает с регрессом, ручными проверками, UI-автоматизацией или поддержкой автотестов. Особенно интересно:

1. какие ручные сценарии вы бы попробовали автоматизировать первыми
2. где визуальная сборка выглядит полезной, а где сразу хочется писать код
3. каких шагов или проверок не хватает
4. какие интерфейсы, скорее всего, будут проблемными
5. нужен ли такой инструмент одиночным QA, небольшим командам или он слишком нишевый

Попробовать можно здесь: https://rthelper.ru/docs.html

Буду рад критике. Особенно той, после которой становится понятно, что именно нужно исправить в продукте, а не просто «все уже было в Selenium».