Ручные тест-кейсы копятся быстрее, чем их успевают автоматизировать. Селекторы ломаются после каждого обновления вёрстки. А код автотестов остаётся понятным только разработчикам. В этой статье я разберу ключевые проблемы автотестов и расскажу, как их можно решить.
Меня зовут Даниил Ахетов. Я занимаюсь автоматизацией тестирования уже достаточно давно. В основном пишу на JavaScript. Внедрял инструменты автоматизации тестирования в Яндексе, строил целое направление автоматизации тестирования фронта в SberDevices, но какие бы фреймворки я ни использовал и какие бы команды ни собирал, я всегда сталкивался с одной и той же проблемой: автоматизация тестирования не успевает. Мы постоянно работаем в догоняющем режиме. Причин этому много, но я для себя выделил три основные.
3 причины, по которым автоматизация отстает
Причина №1 - ручного тестирования больше. Как правило, в компаниях первыми специалистами в области тестирования становятся ручные тестировщики, а мысль о том, что, возможно, нужны автоматизаторы, приходит позже. К тому времени уже накапливается огромная база тест-кейсов, и автоматизаторам приходится всё это догонять.
Причина №2 - тест-кейсы писать проще. Они создаются на естественном языке. По сути, мы преобразуем постановку задачи в тест-кейсы. А при автоматизации тестирования нам приходится переводить естественный язык в машиночитаемый.
Причина №3 - изменения в верстке. На фронте нередко меняется DOM-структура, будь то рефакторинг или переход на новый фреймворк, которые ломают прописанные локаторы. Классы перестали иметь постоянные значения, в мире CSS-препроцессоров они генерируются динамически. А атрибуты доступности расставляют далеко не на всех проектах.
Иногда даже если мы, опытные автоматизаторы, стараемся сами добавить дата-атрибуты, приходит стажер-фронтендер и спрашивает: «Зачем эти лишние атрибуты на каждом элементе?» - и удаляет их. В результате все наши тесты падают.
Ручное и автоматизированное тестирование - два параллельных мира?
Есть ли решение этой ситуации?
Для начала хочу отметить: когда ты автоматизатор, к тебе обычно подходит ручное тестирование и задаёт логичный вопрос: «Точно ли вы в своих автотестах проверяете то, что написано в тест-кейсах?». Этот вопрос действительно логичен.
Ручное тестирование и автоматизация живут как будто в разных мирах, между ними - огромная пропасть.
Почему так происходит? Потому что ручное тестирование существует в TMS-системе и использует естественный язык, а автоматизация пишет автотесты на машиночитаемом языке, в IDE и хранит их в каком-то удаленном репозитории. Ручной тестировщик может написать: «Нажать на кнопку Войти», для автоматизатора это обернется целой историей:
составить стабильный локатор для элемента,
подождать загрузки страницы и конкретного элемента,
совершить сам клик
и т.д.
Конечно, можно попытаться преодолеть эту пропасть за счёт организационных процессов - например, вовлечь ручных тестировщиков в автоматизацию или интегрировать автотесты прямо в TMS.
Но это превращается в отдельную задачу, которая требует времени и усилий от команды. Автоматизация перестаёт быть инструментом ускорения и становится дополнительной нагрузкой. Вовлекая ручных тестировщиков, мы рискуем замедлить и сам процесс тестирования, и выход продукта на рынок.
Как сделать автоматизацию доступной для всех
Когда я думал над тем, как решить все эти проблемы, чтобы автоматизация тестирования не отставала, я пришёл к выводу, что в команде автоматизировать должны все.
Любой член команды должен быть способен написать автотест, исправить его или понять почему он упал.
Для этого нужно избавиться от кода, потому что частой преградой является незнание языка программирования. Также важно, чтобы автоматизация не зависела от верстки. Неважно, что фронтенд-разработчики сделали со своим HTML и CSS. Если дизайн не изменился, тесты не должны падать. Они должны реагировать только на серьёзные изменения в дизайне, такие как исчезновение кнопки или её перемещение.
В поисках решения я пробовал разные подходы и инструменты. Cucumber казался отличной идеей: тесты пишутся на естественном языке, барьер для понимания ниже. На практике он оказался слишком чувствителен к формулировкам. Затем я обратился к Katalon, low-code инструменту для UI тестов. Он должен был упростить написание и поддержку тестов, но вскоре проявились другие сложности: громоздкий UI и ненадёжные локаторы. Каждый из этих инструментов по-своему пытался закрыть разрыв между ручным тестированием и автоматизацией, но ни один из них не дал ощущения устойчивости и универсальности.
В этой статье я расскажу о том, как разочаровавшись в этих инструментах, я создал собственный плагин для Cypress с использованием OpenCV, что позволило находить элементы по изображениям, избегая зависимости от HTML/CSS. А также познакомлю вас с продуктом, который мы разработали в компании BugBuster. Это самостоятельный инструмент автоматизации тестирования на естественном языке. Он имеет интерфейс TMS-системы и позволяет автоматизировать проверки без программирования.
Почему Cucumber не всегда работает
Начнём с Cucumber. Конечно, для того, чтобы он заработал, надо написать много кода и это работа автоматизаторов, но я рассматриваю его с точки зрения конечного использования - когда мы уже написали весь фреймворк, реализовали все функции, и ручное тестирование или менеджмент начинают писать тест-кейсы.
Cucumber. Определение степов
Мы заранее определяем функции, например: открываю страницу, ввожу задачу, параметризируем всё это и получаем результат. Когда я пытался внедрить Cucumber, я был в восторге от идеи: пишем на естественном языке, и это понятно всем. Но мечты быстро разбились о реальность.
Cucumber. Тест-кейс
Допустим, есть действие ввожу задачу “Купить молоко”. Я показал это тестировщикам и сказал, что теперь они могут писать так, и будет классно.
Cucumber. Проблема точного описания шага
Но они начали использовать синонимы: добавляю задачу, создаю задачу. Для них это одно и то же, но для Cucumber это критично - любая опечатка или изменение формулировки приведёт к ошибке.
Cucumber. Проблема поиска шага
Следующая проблема возникла, когда я прописал множество команд, и при создании тест-кейсов люди не могли выбрать нужное действие из большого списка. Даже если есть автокомплит, он работает только в IDE, а ручные тестировщики такими инструментами редко пользуются - у них есть TMS.
Cucumber. Проблема дублирования шага
Ещё одна сложность возникла, когда я запустил тесты и обнаружил, что некоторые действия реализованы дважды. Кто-то кроме меня написал ту же функцию, и мне пришлось разбираться, кто, где и зачем это сделал.
Cucumber. Вердикт
Gherkin - это не естественный язык, и на его освоение требуется время. Либо нужно вкладываться в инфраструктуру, чтобы сделать его удобным для работы.
В итоге я остался с локаторами, так как при реализации функций всё равно приходилось использовать те же методы, что и в классических инструментах автоматизации. Необходимо было настраивать автокомплит, использовать линтеры для поиска дубликатов, а также интегрировать всё это с TMS, что требовало множества усилий.
Katalon и его ограничения
После этого я перешёл к инструменту Katalon, который уже является полноценным low-code инструментом, без всяких «но».
Katalon. Интерфейс
Интерфейс у него достаточно сложный. В нем неудобно править тесты: приходится открывать множество окон, чтобы найти причину ошибки. Всё это очень громоздко и требует обучения пользователей.
Katalon. Тест-кейс
Katalon позволяет собирать тест-кейсы из блоков действий. Например: кликнуть на элемент, ввести данные.
Katalon. Рекордер
Есть интересный рекордер, который может записать действия в браузере и преобразовать их в последовательность кликов, ввода текста и других операций.
Katalon. Тест упал :(
Я записал тест-кейс через рекордер, но при запуске он не прошёл.
Оказалось, что при записи действий Katalon сам выбирает локаторы (чаще всего это XPath), но делает это не всегда корректно. Иногда он привязывается к нестабильным атрибутам или к структуре DOM, которая легко меняется, из-за чего тесты становятся хрупкими и начинают падать при малейших изменениях в вёрстке.
Katalon. Опять локаторы
Опять же, используются селекторы, поэтому проблема не исчезает.
Katalon. Вердикт
Отладка тестов и их поддержка отнимают много сил. Интерфейс сложный, команду нужно долго обучать, а автоматические локаторы часто подводят.
Война селекторам: OpenCV и шаблонный поиск
После того как я столкнулся с ограничениями Cucumber и Katalon, я решил попробовать сузить задачу и побороться с главным злом - локаторами. Я написал собственный плагин для Cypress, в котором использовал библиотеку OpenCV, а точнее её метод шаблонного поиска MatchTemplate. Этот подход заключается в том, что на вход подаются два изображения: скриншот всего интерфейса и скриншот конкретного элемента, который мы хотим найти. Алгоритм анализирует оба изображения и возвращает координаты середины шаблона относительно скриншота всего интерфейса.
С помощью этих координат я мог получить сам DOM-элемент через метод ElementFromPoint и взаимодействовать с ним стандартными средствами инструмента автоматизации тестирования - кликать, вводить текст, проверять наличие и т.д. Таким образом, мне удалось полностью исключить зависимость от структуры HTML и CSS. Теперь даже если фронтенд-разработчики меняли классы, удаляли или добавляли новые элементы - мои тесты всё равно находили нужный объект на странице.
Этот опыт стал важным шагом на пути к более гибкой и устойчивой автоматизации. Подробно реализацию данного подхода я описал в статье Компьютерное зрение в автотестах. Поиск элемента по фото / Хабр.
Vision-Language модели - будущее автоматизации
Однако настоящий прорыв произошёл в результате моего знакомства с командой BugBuster и vision-language моделями (VLM). Это мультимодальные нейросети, способные объединить картинку и текст в единое пространство признаков. Они принимают на вход не только скриншот интерфейса, но и инструкцию на естественном языке, например: «Нажми на кнопку редактирования слева от кнопки Run в модальном окне». Модель понимает контекст и определяет, какой именно элемент соответствует этой инструкции, даже если он не имеет уникальных атрибутов или находится внутри Canvas-объекта.
На основе этой технологии мы разрабатываем платформу BugBuster. Главное отличие этой платформы от других - она не генерирует программный код на основе описания шагов, а исполняет их напрямую.
Например, можно создать тест-кейс под названием «Поиск товара по запросу», в котором описать следующие действия:
Подождать, пока загрузится карточка первого товараВвести “Черные наушники” в поле поискаНажать клавишу “Enter”Первыми в списке товаров отображаются наушники черного цветаКликнуть на картинку карточки первого товара с черными наушниками
VLM. Поиск элемента
Модель сопоставляет текстовую инструкцию с визуальным представлением интерфейса и выполняет действие без промежуточного программного слоя.
Если указано: «Наведи мышь на значок с короной на северо-западе от метро Боровицкая», система определяет нужный элемент и выполняет наведение. Чтобы проверить, что при этом появляется нужный поп-ап, в тест-кейсе должна быть явная инструкция на такую проверку - платформа выполняет ровно то, что описано.
Кроме того, платформа позволяет запускать тест-раны - наборы тестов, которые можно группировать, задавать среду выполнения (браузер, ОС, разрешение экрана), а также запускать параллельно.
В рамках одного тест-рана можно одновременно запускать тест-кейсы в автоматическом режиме и проходить ручные сценарии. Пока платформа автоматически исполняет типовые кейсы, вы параллельно можете вручную выполнять более сложные шаги, которые требуют человеческого вмешательства или ещё не автоматизируемы. И если вы не согласны с результатами автоматического прохождения, вы тут же сможете перепройти тест-кейс в ручном режиме.
Контекстные проверки
Вместо такого огромного фрагмента кода теперь можно просто написать открылась страница с товарами. Больше не нужно проверять каждый элемент вручную и писать громоздкий код.
Независимость от локаторов
Вместо сложных локаторов (здесь я специально показал самый ужасный локатор в своей жизни) теперь можно написать: Кликнуть на пункт “Акции” со значком процента.
VLM. Рефлексия
Платформа не просто сообщает, прошёл тест или нет - она объясняет причину.
Например, если тест провалился, система указывает, на каком шаге возникла проблема и почему. Это особенно полезно при регрессионном тестировании, когда важно понимать, какие изменения повлияли на работу приложения.
Что в планах
Мы активно развиваем платформу и фокусируемся на функциональности, которая делает её универсальным решением для разных типов проектов:
Расширение парка браузеров. В ближайшее время появится поддержка других браузеров помимо FireFox - это позволит тестировать в условиях, приближенных к реальным пользовательским конфигурациям.
Поддержка мобильных платформ. Мы выходим за рамки веба и добавляем возможность тестирования нативных мобильных приложений - как Android, так и iOS.
Интеграция API-тестирования. Будет реализована возможность отправки HTTP-запросов прямо в рамках тест-кейсов - для подготовки состояния, проверки логики или обхода сложного UI.
Self-hosted решение. Мы на финальной стадии разработки изолированной версии платформы, которую можно будет запускать в закрытом контуре - на собственных серверах, без подключения к интернету.
Эти направления позволят использовать BugBuster не только для визуального UI-тестирования, но и как единое пространство для автоматизации на всех уровнях: от фронта и API до мобилок - в любых условиях эксплуатации.
Если вы хотите попробовать нашу платформу, переходите по этой ссылке. Мы регулярно выкладываем обучающие видео - учитесь и осваивайте новые возможности. Также доступен Telegram-канал, где проводится бета-тестирование. Все функции, о которых я рассказал, доступны бесплатно, и вы можете протестировать их в своём рабочем процессе.
Автоматизация тестирования должна быть простой, быстрой и понятной всем участникам процесса.
Никто не должен зависеть от знания программирования или от структуры верстки. Автоматизация - это сервис, а не нагрузка. И мы уверены, что наша платформа делает это возможным.