редакции
RTHelper: я делаю инструмент, который превращает ручные UI-проверки в автотесты без кода
В тестировании есть неприятный промежуток между ручной проверкой и нормальной автоматизацией. С одной стороны, руками проходить регресс долго и скучно: открыть форму, ввести данные, нажать кнопку, проверить текст, повторить это на следующем билде. С другой стороны, полноценные автотесты требуют времени, кода, инфраструктуры и поддержки. В итоге часть сценариев живет в состоянии «когда-нибудь автоматизируем», но пока их снова и снова гоняют вручную. Я делаю RTHelper, чтобы закрыть именно этот промежуток. Идея простая: взять знакомый ручной тест-кейс и собрать из него исполняемый сценарий без обязательного написания кода. Не как большая RPA-система на все случаи жизни, а как рабочий помощник для QA: захватить элементы интерфейса, выстроить действия, добавить ожидания и проверки, запустить сценарий, посмотреть понятный отчет о том, где все прошло, а где упало. Сайт проекта: https://rthelper.ru/docs.html
Как я к этому пришел
Изначально мне нужно было сделать утилиту для взаимодействия с UI-элементами в Windows и браузерах. Задача не была напрямую связана с тестированием, но оказалось, что сама идея очень близка к автоматизации рутинных действий: найти кнопку, нажать, прочитать текст, дождаться состояния, повторить. Потом я начал смотреть на это уже глазами тестировщика. Если сценарий можно описать как цепочку «элемент + действие + проверка», почему бы не дать человеку собрать такую цепочку визуально? Так проект постепенно вырос из эксперимента в отдельное приложение.
Что уже работает
Сейчас RTHelper работает с двумя основными типами интерфейсов:
- Web: сценарии поверх сайтов и веб-приложений через браузерное расширение для Chrome/Edge/Firefox/Yandex...
- Windows UIA: сценарии для desktop-приложений через UI Automation
Типовой путь выглядит так:
- Выбираете режим Web или UIA.
- Добавляете приложение или страницу в дерево.
- Захватываете нужные поля, кнопки и текстовые элементы.
- Перетаскиваете их в алгоритм.
- Назначаете действия: Click, Write, Read, Wait, Assert и другие.
- Запускаете сценарий обычным запуском или в Debug.
В простом случае это выглядит как расширенный ручной тест-кейс: ввести логин, ввести пароль, нажать кнопку, дождаться результата, проверить текст. В UI-автоматизации основной враг не сам клик. Основной враг — нестабильность интерфейса. Кнопка может переехать. Страница может грузиться дольше обычного, id у элемента может генерироваться фронтендом. В Windows-приложении AutomationId может быть пустым или повторяться. В таблице может быть десять одинаковых кнопок «Открыть». Поэтому RTHelper сохраняет не указатель на элемент, а набор признаков, по которым его можно найти заново: тип, имя, id, class, role, текст, родительский контейнер, положение в дереве и другие атрибуты. Пользователь может уточнить, какие признаки важны, ограничить область поиска, использовать индекс совпадения, подсветить найденные элементы и понять, слишком широкий локатор получился или слишком строгий. Я не хочу делать вид, что это магия. Иногда локаторы все равно приходится настраивать руками. Но цель инструмента — сделать эту настройку наглядной, а не прятать проблему до первого падения на регрессе. Записать клики легко, а получить полезный тест сложнее. Если сценарий нажал «Сохранить», это еще не значит, что проверка прошла. Нужно дождаться результата и явно проверить, что появилось сообщение, изменился статус, API вернул нужное значение или экран визуально соответствует ожиданию. Поэтому в RTHelper рядом с обычными UI-действиями есть: Отдельный блок, который я активно развиваю, — история запусков и отчеты. Когда сценарий падает, мало увидеть «шаг 17 не прошел». Нужно понять, что это был за шаг, какой элемент искался, сколько он ждал, какой результат вернулся и какая ошибка была первой. В приложении есть журнал выполнения, история запусков, скриншоты при падении и студия запусков. В студии можно собрать несколько сценариев в набор: например, smoke перед релизом или небольшой регресс авторизации, платежей и профиля. Результаты можно выгружать в JSON, JUnit XML и Allure, чтобы не запирать пользователя внутри программы и дать возможность подключать сценарии к привычному процессу. Я не позиционирую RTHelper как замену Playwright, Selenium, Appium или нормальному тестовому фреймворку в команде, где автоматизация уже хорошо выстроена. Скорее это инструмент для ситуаций, где: У инструмента есть ограничения: он не отменяет необходимость думать о стабильных локаторах, не все старые desktop-интерфейсы хорошо отдают дерево элементов, визуальная сборка не всегда лучше кода. А если сценарий становится слишком сложным, его, возможно, честнее перенести в полноценный автотест. Мне кажется важным говорить об этом заранее, потому что иначе no-code-инструменты быстро превращаются в завышенные ожидания. Мне очень нужна обратная связь от тех, кто каждый день работает с регрессом, ручными проверками, UI-автоматизацией или поддержкой автотестов. Особенно интересно: Попробовать можно здесь: https://rthelper.ru/docs.html Буду рад критике. Особенно той, после которой становится понятно, что именно нужно исправить в продукте, а не просто «все уже было в Selenium».
Самая сложная часть: не кликнуть, а стабильно найти элемент
Почему сценарий должен быть не просто записью кликов
Отчеты и регулярные запуски
Для чего это
Что хочу от публикации