Для автоматизации тестирования разработка надёжных скриптов может оказаться довольно сложной задачей. Расскажу о методах повышения надёжности через призму пирамиды автоматизации тестирования с минимизацией зависимости от пользовательского интерфейса. Затрону швы в коде, локаторы и стратегии поиска UI‑элементов.

В книге «Успех с Agile: разработка программного обеспечения с использованием Scrum» (англ. Succeeding with Agile: Software Development Using Scrum, Mike Cohn) Майк Кон представил пирамиду автоматизации тестирования как модель, описывающую три уровня:

1. Модульный уровень самый близкий к коду. Обычно юнит‑тесты пишут разработчики в процессе работы над функциями, но если не пишут, их можно добавить любому, кто обладает необходимыми знаниями. Если вы забыли, модульные и юнит‑тесты это одно и то же, и это небольшие проверки, что быстро чекают логику отдельных функций не затрагивая другие модули, базы данных или пользовательские интерфейсы. Помимо скорости, они позволяют определить, в какой именно функции возникла ошибка. Юнит‑тесты быстро пишутся, быстро выполняются, они основная часть всей автоматизации тестирования и наибольшее количество автотестов должно быть написано на этом уровне.

2. Сервисный уровень расположен чуть дальше от самого кода, сосредоточен на проверке функциональности, которую обеспечивает код. Состоит из интеграционных сквозных тестов, также известных как E2E, которые обычно работают с API продукта и/или бизнес‑логикой, чтобы проверить, как разные функции взаимодействуют друг с другом. Он должен быть вторым по количеству проверок после модульных.

3. Уровень пользовательского интерфейса — вершина пирамиды и самый дальний от рабочего кода уровень. UI‑тесты здесь имеют свои особенности: их сложнее писать, они выполняются медленнее и сильно зависят от стабильности локаторов. Именно поэтому автотестов на уровне интерфейса должно быть меньше всего.

Через призму пирамиды тестирования

При разработке автоматизированного теста важно определить, какую именно информацию необходимо проверить, а затем выбрать самый низкий уровень, на котором реализовать тест или его части. Дело в том, что на практике, несмотря на знание теории, возникает соблазн сосредоточиться на автоматизации E2E и UI‑тестов, и это объяснимо: хочется убедиться, что приложение клиента выглядит корректно и элементы управления работают. Однако, даже при необходимости тестирования интерфейса, далеко не все шаги сценария должны выполняться на этом уровне. Такой подход помогает сделать тесты более стабильными, быстрыми и в перспективе менее затратными.

Минимизация зависимости от пользовательского интерфейса

Команда создала новую функцию поиска. Естественно, нужно убедиться, что возвращаются правильные результаты, отображаются они как нужно, а фильтрация, сортировка, и что там у вас еще есть, на результат влияют правильно. Если вы автоматизируете один тест‑кейс поиска, то окей — автоматизируйте его через интерфейс, однако, если нужно написать несколько тестов с его участием, спросите себя, нужно ли выполнять все на таком дорогостоящем уровне или вы можете автоматизировать один через пользовательский интерфейс, а остальные — на уровне сервиса или даже модуля.

Допустим, нужно добавить что‑то в корзину и сценарий содержит:

1. Сделать поиск.

2. Выбрать из результатов.

3. Перейти в карточку товара.

4. Нажать на кнопку «Добавить в корзину»

5. Клик по иконке корзины для перехода в нее

6. Проверить, что товар в корзине.

Автоматизировать все эти шаги через пользовательский интерфейс рискованно. Один сбой на ранних шагах не даст тесту дойти до финальной проверки. Если ранее, вы уже проверили поиск через UI, в этом новом сценарии, желательно обойтись без него и без зависимости от функции поиска в этом тесте, так как проверка с ней не связана. Вместо того чтобы искать, идите по URL‑адресу в карточку товара — это сэкономит много времени и снизит риски, за счёт исключения лишних шагов. Тест должен проверять функциональность, ради которой он создан. В данном случае это добавление товара в корзину, а не другие вспомогательные шаги.

Ещё пример. Нужно протестировать возможность изменить количество позиций в корзине. Шаги воспроизведения могут включать:

1. Сделать поиск.

2. Выбор из результатов.

3. Переход в карточку товара.

4. Нажать на кнопку «Добавить в корзину».

5. Клик по иконке корзины для перехода в нее.

6. Увеличить количество у позиции.

7. Проверить количество товаров в корзине.

Опять же, процесс поиска и даже добавления товара необязательно выполнять здесь, а выполняя, тратим время, создаём зависимости, дублируем код и повышаем уязвимость тестов. Тут можно использовать такие способы, как обратиться к API или взять готовую функцию добавления товара в корзину, а затем перейти непосредственно на URL‑адрес корзины и начать тестирование. Меньше зависимостей от интерфейса и локаторов — это быстрее и с меньшей вероятностью приведёт к сбою.

Швы в коде и локаторы

Точки расширения и подмены зависимостей — это примеры швов, точек взаимодействия внутри приложения, которые позволяют тестам обходить пользовательский интерфейс и напрямую работать с логикой приложения. В английском языке используется термин Code seams с простым определением — места в коде, где можно подставить другую функциональность. Это значительно упрощает автоматизацию. Когда встретите упоминание инъекций зависимостей, это тоже из этой темы. Некоторые швы предусмотрены в приложении по умолчанию, например уникальные URL‑адреса разных страниц. В коннекте с разработчиками можно получить дополнительные, например, возможность отправлять быстрые HTTP‑запросы в приложение и методы для очистки данных после завершения тестового прогона. Такой подход идеально подходит тест‑кейсам для E2E‑тестирования уровня интеграций.

Локаторы — средство обнаружения HTML‑элементов, используются для работы с элементами интерфейса (UI). Их ненадёжность часто становится причиной нестабильной работы тестов. Когда разработчики создают новые веб‑элементы, для последующей автоматизации крайне важно, чтобы HTML‑элементы имели идентификаторы. Это могут быть атрибуты ID или Name, или пользовательские атрибуты, предназначенные специально для автоматизации (data‑test‑id, data‑testid). Обычно этому не учат фронтенд‑разработчиков, когда они учатся программировать и даже если вы сообщаете, что это необходимо, они всё равно могут забыть об этом, поэтому необходимо сделать это частью культуры вашей команды.

Стратегии поиска UI элементов

Я знакома с примером, где тестировщик самостоятельно дописывала ID‑идентификаторы к элементам проекта, для использования их в автоматизации тестов — имеет место быть, требует доступа к коду и право на внесение изменений, а можно внедрить другие процессы, чтобы обеспечить наличие стабильных локаторов:

• Предложите правила для добавления уникальных атрибутов ко всем ключевым элементам UI. Сделайте это частью командной работы и документации.

• Планирование. Заранее встречайтесь с разработчиками и обозначайте макет элементов необходимы атрибутами.

• Включите поиск этих упущений в код‑ревью.

• Интеграция с CI/CD. Добавьте проверку, чтобы код не проходил, если в элементе отсутствуют необходимые атрибуты.

Автоматизации тестирования это полноценный проект по разработке программного обеспечения. Прежде чем приступать, нужно многое обдумать и создавать проект таким образом, чтобы его можно было масштабировать. Надеюсь, эта статья помогла вам лучше понять основы автоматизации с точки зрения пирамиды тестирования, подготовит к успешной разработке эффективных и устойчивых тестов, и ускорит ваш процесс автоматизации.

Ресурсы:

Succeeding with Agile: Software Development Using Scrum, Mike Cohn

Hybrid Tests: Blurring the lines of the Automation Pyramid

UPD: Благодарю @kompilainenn2 за комментарий, дополнила статью и подробнее раскрыла понятие швы.