Привет, Дзен! Я занимаюсь автоматизацией тестирования. Работал в крупных компаниях, где внедрял инструменты автоматизации для фронтенда. Но несмотря на все технологии и подходы, которые я применял, я постоянно сталкивался с одной и той же проблемой — автоматизация тестирования всегда работает в догоняющем режиме.
Я выделил три основные причины этой проблемы:
- Во-первых, ручное тестирование появляется раньше, чем автоматизация;
- Во-вторых, писать тест-кейсы проще, чем автотесты;
- В-третьих, изменения верстки часто ломают автотесты.
Эти проблемы мешают командам эффективно использовать автоматизацию.
Кроме того, между ручным тестированием и автоматизацией часто возникает разрыв в понимании: одни описывают тесты на естественном языке, другие — на машиночитаемом. То, что ручной тестировщик формулирует одной строкой, автоматизатор может реализовывать несколько дней.
Именно поэтому я начал искать решения, которые позволят автоматизировать без кода и DOM-структур, перейдя к более человекоориентированному подходу.
Проблемы классической автоматизации
Как я уже говорил, автоматизация тестирования почти всегда работает в догоняющем режиме. Это связано с тем, что компании обычно начинают с найма ручных тестировщиков и только потом задумываются о внедрении автоматизации. Получается, что автоматизаторы приходят тогда, когда уже есть огромная база тест-кейсов, и пока они покрывают одно, успевает появляться новое и меняться старое.
Кроме того, тест-кейсы гораздо проще писать. Ручные тестировщики работают в TMS-системах, где всё описывается на естественном языке. Автоматизаторы же вынуждены переводить эти тесты в машинночитаемый формат, используя языки программирования и фреймворки. И самое сложное — это то, что любые изменения в верстке могут сломать автотесты. Иногда даже сами разработчики могут удалить по незнанию необходимые для автотестов data-атрибуты, что может привести к тому, что все тесты начнут падать.
Почему Gherkin и Cucumber не всегда работают
Одним из популярных подходов к написанию тестов на "человеческом" языке является использование BDD-фреймворков, таких как Cucumber. Они позволяют описывать тесты в виде шагов:
- Дано: пользователь находится на главной странице
- Когда: пользователь вводит "купить молоко"
- Тогда: открывается результат поиска
На первый взгляд, это выглядит идеально. Однако, как показывает практика, такой подход имеет свои ограничения. Во-первых, требуется строгое соблюдение формата. Если тестировщик допустит опечатку или перефразирует шаг, тест может просто не запуститься. Во-вторых, для работы с такими фреймворками необходимо обучать команду, что занимает время. В-третьих, мы не избавляемся от реализации шагов в коде, а соответственно от локаторов и поддержки. Cucumber становится дополнительным слоем абстракции над фреймворком автоматизации тестирования.
Low-code тоже не решает всех проблем
Еще один способ упростить автоматизацию — это использование low-code инструментов, таких как Katalon. Здесь тесты создаются через графический интерфейс, собирая действия в цепочки блоков. Также есть возможность записи действий в браузере.
Однако, как я сам убедился, этот подход тоже не лишен недостатков. Интерфейс таких систем часто оказывается сложным для новых пользователей, поиск ошибок становится трудоемким процессом, а генерируемые локаторы остаются хрупкими и зависят от структуры DOM.
Борьба с селекторами: OpenCV + Cypress
Я пытался решить проблему зависимости от селекторов при помощи плагина для Cypress, который использует библиотеку OpenCV для поиска элементов по скриншотам. Плагин использует метод matchTemplate, который принимает скриншот элемента и полный скриншот интерфейса, а затем возвращает координаты этого элемента. Таким образом, вместо поиска элемента по CSS-селектору или XPath, я могу просто передать изображение нужного элемента.
Пример использования:
cy.searchByImage('todo-list-element.png').click();
Это позволяет отказаться от зависимости от структуры HTML и сделать тесты более устойчивыми к изменениям верстки. Однако этот подход всё равно требует наличия кода и понимания принципов работы с такими библиотеками.
Переход к Vision Language Model (VLM)
Следующий этап эволюции автоматизации — это использование визуальных языковых моделей (Vision-Language Models). Эти модели способны анализировать скриншоты интерфейса, понимать естественный язык и выполнять действия или проверки на основе текстовых инструкций.
Например, можно написать проверку:
Открылась форма редактирования задачи
Модель проанализирует текущее состояние интерфейса и ответит, соответствует ли оно описанию.
Можно получить координаты элемента по его описанию:
Кнопка редактирования слева от кнопки Run в модальном окне
Важно понимать, что такие модели работают не на уровне DOM, а на уровне восприятия — они видят интерфейс так же, как человек, и реагируют на его внешние признаки. Этот подход реализован в платформе BugBuster, которая позволяет писать автотесты на естественном языке без использования кода и без опоры на структуру HTML.
BugBuster: платформа, которая объединяет всё
BugBuster представляет собой гибрид TMS и инструмента автоматизации тестирования.
Тесты пишутся на естественном языке. Вы можете создавать тест-кейсы, как будто вы просто описываете, что нужно сделать:
- В поле поиска ввести "аптека"
- Кликнуть на пункт "Аптека рядом" в саджесте
- Нажать на кнопку "+" в правой части экрана
- Навести курсор на значок с короной рядом с метро Боровицкая
- Открылся попап с названием "Ригла", рейтингом и адресом
Эти тесты понятны всем членам команды, и их может писать даже человек без технической подготовки.
Независимость от DOM. Платформа не использует селекторы. Все действия выполняются на основе анализа скриншотов и контекста, аналогично тому, как это делает человек. Это позволяет игнорировать изменения в структуре HTML, если дизайн интерфейса не изменился.
Поддержка параллельных прогонов и CI/CD. BugBuster позволяет запускать тесты в параллельном режиме, создавать тест-планы и управлять средами выполнения (браузер, ОС, разрешение). Он имеет открытое API, что открывает возможности для интеграции с CI/CD.
Гибридный режим: ручные и автоматические тесты. Вы можете создавать смешанные тест-планы, где одни тесты выполняются автоматически, а другие — вручную. Это позволяет постепенно перевести тестирование в автоматический режим без полного переписывания всех тест-кейсов.
Заменяем код на простые инструкции
Вместо кода и DOM-структур появляются инструменты, которые работают с интерфейсом так же, как человек. Это возвращает нас к исходной идее — писать автотесты на естественном языке. Но в отличие от BDD, новый подход не требует фреймворков, step definition’ов и жестких шаблонов. Сохранив понятность, мы избавились от технических ограничений прошлого.
Платформы вроде BugBuster демонстрируют, что возможно создание no-code решений, которые:
- Понимают естественный язык,
- Умеют находить элементы по описанию,
- Проверяют состояния интерфейса без написания кода.
Это снижает порог входа для тестировщиков, ускоряет внедрение автоматизации и делает процесс более надежным и устойчивым к изменениям.
Попробуйте простую автоматизацию тестирования на естественном языке — без сложной инфраструктуры и кода. Запустить тест-кейс с поддержкой Vision Language Model можно бесплатно.