Преодоление техдолга по автотестам с помощью паттерна Page Object Model

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

Система развивалась, приоритет сместился в сторону роста, а линейная структура оказалась не готова к масштабированию - со временем стал накапливаться технический долг, который стал тормозить развитие продукта.

Ключевые сложности:

1) Нулевая переиспользуемость. Один и тот же функционал приходилось описывать заново для каждой страницы портала. Каждый тест содержит:

• Вход в систему
• Проверку корректности входа
• Загрузку документов
• Проверку корректности загрузки

И только потом идет основное тело теста. Эти шаги приходилось повторять из теста в тест.

2) Хрупкость тестов. Любое изменение в интерфейсе - даже новый селектор - требовало поиска и правок по всему коду. Данная проблема вытекает из предыдущего пункта. Так как в приложении используются общие элементы, то при добавлении, например, нового фильтра обязательно требуется сделать изменение в каждом из элементов.

3) Высокий порог входа. Новым инженерам было сложно разобраться в «спагетти-коде» из десятков похожих функций.

Перед командой стояла стратегическая задача: преодолеть технический долг и сделать систему автотестов устойчивой, масштабируемой и недорогой в поддержке - даже ценой временных затрат на рефакторинг. Именно поэтому мы приняли решение внедрить Page Object Model (РОМ).

Page Object Model (POM) - способ организовать автотесты так, чтобы каждая страница сайта описывалась отдельным классом. Каждый такой класс описывает элементы страницы (кнопки, поля, ссылки) и действия, которые можно с ними выполнить (например, «ввести логин» или «нажать “Купить”»).

Мы выбрали его, как наиболее популярную структуру в среде программирования, которая известна большинству тестировщиков. Также POM помогает структурно отобразить каждую страницу приложения, как отдельную сущность, превращая тесты в некий набор функций, используемых на данной странице.

Решение: переход на Page Object Model

Переход к POM мы строили поэтапно, чтобы не останавливать процесс тестирования и при этом постепенно перестраивать архитектуру. С чего начали?

1) Выделили общие элементы 

Мы выделили повторяющиеся элементы интерфейса - кнопки, поля ввода, формы - и описали их в виде универсальных классов. Общие элементы занимают порядка 70 % от всего кода, и повторять его из теста в тест нецелесообразно.

2) Описали страницы

Для каждой страницы приложения создали классы-обертки, инкапсулирующие все элементы и возможные действия. Так появилась понятная логика: страница = объекты с методами.

3. Сосредоточились на бизнес-логике в тестах

На верхнем уровне остались чистые тестовые сценарии, которые оперируют не техническими селекторами, а бизнес-методами. Например такими:

loginPage.enterCredentials().clickSubmit().

Теперь их можно читать как историю взаимодействия пользователя с продуктом.

Результаты 

Рассмотрим плюсы нашего решения:

1) Читаемость и качество кода 

Тесты превратились в понятные бизнес-сценарии. Даже начинающие QA-инженеры видят логику выполнения и быстро разбираются в проекте.

2) Снижение стоимости поддержки

Изменения в UI не превращаются в часы рутинных правок. Обновление селектора в одном классе страницы автоматически применяется ко всем связанным тестам. В результате стоимость поддержки существенно снизилась: с новым подходом на поддержку уходило не 80% времени, а около 20%, что позволило увеличить покрытие автотестами до 95% за полгода.

3.Быстрый онбординг

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

4) Устойчивость к изменениям

Теперь даже крупные обновления продукта не вызывают «эффекта домино». Тестовая система стала гибкой, предсказуемой и легко расширяемой. Все новые тесты сразу пишутся с использованием POM, новый рефакторинг не требуется.