Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Я, как профессионал: Почему так много людей начинают автоматизировать с UI-автоматизации?

Я, как тренер: Почему так много курсов автоматизации начинает с UI-автоматизации?

(Кстати, говоря о «UI-автоматизации», я подразумеваю тип E2E или full stack-автоматизации, которая проводится с использованием таких инструментов, как Selenium, Cypress или Playwright. Речь не о юнит-тестах на уровне UI, к примеру).

Не поймите меня неправильно, UI-автоматизация – это важный компонент общей стратегии автоматизации, и он заслуживает времени и внимания. Твердо стоящий на ногах набор UI-тестов, проверяющий важные сценарии приложения – бесценный инструмент демонстрации, что конечные пользователи все еще могут выполнять критические для бизнеса операции. Я люблю хорошо сделанную UI-автоматизацию. И тут и кроется проблема – в «хорошо сделанной».

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

Эта проблема в последние годы стала только серьезнее – появились нагруженные JavaScript веб-приложения, использующие фреймворки вроде Angular, React и Vue. Они предоставляют людям потрясающий пользовательский опыт – анимации, выплывающие меню, спиннеры, сообщающие время ожидания, и многое другое. Но все это только усложняет создание надежной UI-автоматизации по сравнению с временами, когда мы имели дело только со статичными HTML-страницами.

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

Но, повторюсь, с точки зрения автоматизации все становится в разы сложнее. Все эти рюшечки и виджеты, улучшающие жизнь (или как минимум использование приложения) людям, крайне затрудняют создание надежной UI-автоматизации. Взаимодействия стали сложнее (как насчет перетащить и отпустить?) Усложнились стратегии ожидания. Список можно продолжать.

Частично я понимаю, почему люди, особенно новички, стартуют с UI-автоматизации. Зачастую это единственный способ, посредством которого они взаимодействовали с системой, то есть единственный известный им интерфейс.

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

Разве не разумнее начать с других типов тестов? По сравнению с UI-автоматизацией создание тестов более низкого уровня – API или даже кода – куда проще, как только вы научитесь читать, интерпретировать и подключаться к этим интерфейсам (да, код – это тоже интерфейс). Тесты API или кода обычно намного меньше, а это делает их быстрее и дешевле в создании и прогоне.

И если говорить о расширении горизонтов, не будет ли хорошей идеей прекратить цепляться за идею «автоматизации тест-кейсов» в целом и приступить к поиску способов, путем которых инструменты могут помочь нашему тестированию, поддержать его? Я считаю, что тест-автоматизация нужна именно для этого.

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

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

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

Обсудить в форуме