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

Затем входит QE.

Настроение несколько темнеет, и вы внезапно понимаете, что совершили тяжкое преступление против своих приятелей. Вы что-то изменили! Шок Шок Ужас Ужас!

Говоря по опыту

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

В моем последнем проекте мы неустанно работали, чтобы идти в ногу с изменениями разработчиков. Даже когда мы знали, что все изменится. Даже когда мы знали, что что-то сломается. Было сложно уследить за всеми изменениями - изменения в написании текста кнопок, отсутствующие идентификаторы, изменение идентификаторов, изменение формата страницы, ожидание времени загрузки и многое другое. Мы упорно трудились, чтобы максимально абстрагироваться, но найти в DOM объекты, с которыми можно было бы взаимодействовать, было сложно делать последовательно.

OUIA: спецификация Open UI Automation

С переходом к новому проекту появилась возможность сделать все по-другому. QE тесно сотрудничал с разработчиками, чтобы создать спецификацию для автоматизации веб-интерфейса. Эта спецификация подробно описывает ряд аспектов пользовательского интерфейса, направленных на достижение важной цели: более надежное тестирование пользовательского интерфейса и повышение осведомленности разработчиков о том, что нужно команде QE для хорошего тестирования. Мы назвали это OUIA или спецификацией Open UI Automation.

OUIA охватывает три основных момента:

  • Идентификация компонентов
  • Страница / Идентификация действия
  • Управление терпением (ожидание загрузки)

В рамках тестирования Python для этого нового проекта была написана библиотека, которая абстрагирует и моделирует компоненты PatternFly 4. Он способствует взаимодействию с этими компонентами в очень объектно-ориентированной манере, разрешая такие вызовы, как dropdown.open(), dropdown.select(‘name’) и т. Д. Поскольку компоненты поставляются PatternFly, было ясно, что участие команды PatternFly было необходимо.

Просьба заключалась в том, чтобы ввести два атрибута в корневой элемент DOM каждого компонента:

  • ouia-component-type
  • ouia-component-id

ouia-component-type будет описывать тип компонента, например, Dropdown, NavigationItem, Select. Второй атрибут ouia-component-id будет необязательным, если на странице есть только один экземпляр этого компонента. Для нескольких компонентов одного типа требуется, чтобы у каждого был уникальный идентификатор. Ключевым моментом здесь является то, что эти идентификаторы контролируются QE. Это дает QE способ идентифицировать экземпляр компонента и поддерживать его согласованность. Теперь разработчики могут изменить атрибут id, не влияя на тестирование QE. Теперь, когда легко найти компонент по его типу и идентификатору, стили / классы могут менять имя, не влияя на QE.

План был отличным. Однако он встретил сопротивление со стороны команды PatternFly. Они были обеспокоены тем, что страница может раздуться множеством новых атрибутов. Но стремление разработчиков к оптимизации привело к новой идее: что, если мы сделаем эти атрибуты необязательными? Что, если бы QE могло их включить, но по умолчанию они были выключены?

Идея переменной localstorage распространялась как способ гарантировать, что по умолчанию эти дополнительные атрибуты останутся отключенными. Но когда они потребовались QE, их можно было включить простым переключением переменной. Эта идея намного лучше понравилась команде PatternFly, и включение переменной localstorage во время автоматизированных тестовых прогонов было тем, чем QE уже занималась.

Теперь QE имеет возможность легко идентифицировать и нацеливать определенные компоненты PatternFly гораздо более надежным способом. Остальную часть спецификации OUIA несут разработчики. Мы поговорим об этом в следующий раз.