Home

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

 «Каким способом лучше начать изучать автоматизацию?»

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

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

Первые проекты, над которыми я работал, можно было полностью описать одним предложением:

«Мы хотим, чтобы вы автоматизировали существующие тесты регресса».

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

До некоторой степени объяснимо, почему люди начинают автоматизацию именно с этого. Могу представить ряд причин:

• Это то, что людям знакомо. Как тестировщики, мы привыкли взаимодействовать с приложением через графический пользовательский интерфейс. Следовательно, логично было бы начать автоматизацию именно с этого, правда?
• Как написано в статье по ссылке выше, команды зачастую начинают применять автоматизацию с «автоматизации тестов регресса». Так как они обычно написаны с точки зрения конечного пользователя, то много ссылаются на графический пользовательский интерфейс.
• Так как большое количество автотестов все еще, к сожалению, зачастую пишется (сильно) после создания кода приложения, о тестируемости особо не думают. В результате UI – зачастую единственный доступный для автоматизации интерфейс.

Однако автоматизировать на уровне GUI очень сложно. На самом деле это вообще самая сложная из существующих форм автоматизации.

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

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

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

Машины, однако – не люди, а люди – не машины. Попытка воспроизвести то, как человек интерпретирует интерфейс и взаимодействует с ним, на уровне машины (автоматизации) непросто, как все мы уже знаем.

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

Это не значит, что у вас вообще не должно быть GUI-автоматизации, но вы должны быть очень осторожны, решая, что автоматизировать на этом уровне – и это заставляет меня задуматься, почему так много нас начинает учиться автоматизации именно с этого.

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

Это по большей части можно снизить, имитируя части системы, которые не играют важной роли в предоставлении нужной для теста информации. Я, к примеру, большой поклонник тестирования пользовательского интерфейса при помощи юнит-тестов. Скажем, фреймворки вроде React позволяют тестировать UI-логику и компоненты изолированно от остального кода. В качестве альтернативы можно решить имитировать API (и все, что за ним скрывается), вызываемого через UI, и использовать инструменты вроде Selenium или Playwright для (вроде как) тестирования UI в изоляции.

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

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

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

Как я писал в упомянутой выше электронной книге, развитие навыков автоматизатора требует куда большего.

Это включает, но не ограничивается:

• Становления отличным тестировщиком. Рекомендация: курсы Rapid Software Testing.
• Становления приличным программистом. Рекомендация: практика, практика и еще раз практика, передача своего кода на ревью коллегам, и снова практика.
• Улучшение навыков автоматизации с помощью курсов, выходящих за рамки трюков в конкретных инструментах. Рекомендация: помимо моих собственных курсов, рассмотрите курс вроде Automation in Testing.

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

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

Повторюсь – некоторый уровень автоматизации на уровне пользовательского интерфейса может сыграть роль, но это еще не все. Далеко, далеко не все.

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