Test Engineer Noveo Юлия рассказывает об удобном и достаточно новом способе идентифицировать элементы на веб-странице при тестировании UI, а именно — об атрибуте data-qa.

Каждый, кто интересуется или непосредственно занимается автоматизацией тестирования UI, знает о том, как порой сложно выбрать подходящий селектор.

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

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

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

В HTML5 появилась новая возможность: data-* атрибуты. Это универсальный атрибут, который можно добавить для любого элемента (тега) на странице. Он позволяет создавать кастомные атрибуты для хранения каких-либо значений. Главные правила: название атрибута всегда должно начинаться с «data-», а также могут использоваться только латинские буквы, дефис, двоеточие и подчеркивание.

Если такой атрибут используется для автоматизации тестирования, самыми логичными вариантами выглядят «data-qa» или «data-test», но можно использовать любые другие наименования. В тексте этой статьи атрибут носит название «data-qa», но на практике оно может быть любым другим по усмотрению.

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

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

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

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

Если принято решение внедрить использование атрибутов data-qa на проекте, то это, конечно, лучше делать как можно раньше. Хороший воркфлоу можно описать таким образом:

1. Тестирование документации, исправление ошибок;
2. Тестирование файлов дизайна (мокапов), исправление ошибок;
3. Определение элементов, которые будут использоваться для последующей автоматизации тестирования;
4. Определение наименований атрибутов data-qa для этих элементов, фиксирование в документации;
5. Разработка задачи и добавление атрибутов data-qa для элементов в коде страницы;
6. Тестирование задачи, тестирование наличия атрибутов data-qa.

Теперь посмотрим, как могут выглядеть сами атрибуты data-qa.

На мой взгляд, имеет смысл ввести два базовых правила:

• все атрибуты должны иметь схожую структуру;
• если элементы имеют какие-то общие признаки (например, расположены на одной странице или являются элементами одного типа, как «поле ввода» или «кнопка»), эти признаки должны быть отражены в тексте атрибута data-qa.

Например, в общем виде атрибут может выглядеть как:

<название страницы>_<название элемента>

Например:

HOME_TITLE

Где HOME — название страницы («главная страница»), TITLE — заголовок страницы. Или

SETTINGS_PASSWORD_CHANGE_INPUT

Где SETTINGS — название страницы («настройки»), PASSWORD_CHANGE — форма смены пароля, INPUT — указание на поле ввода

Теперь на примере нескольких страниц абстрактного веб-проекта посмотрим, как это будет выглядеть.

Начнем с самого первого и базового, что обычно тестируется, — страницы авторизации.

Здесь:

[0] = LOGIN_FORM_PAGE — сама страница авторизации (LOGIN_FORM) и указание на то, что это целая веб-страница (PAGE).

[1] = LOGIN_FORM_TITLE — заголовок, наследует название страницы, на которой расположен (LOGIN_FORM), и т.к. заголовок на странице один, имеет универсальное обозначение (TITLE).

[2] = LOGIN_FORM_LOGIN_INPUT — текстовое поле ввода логина (LOGIN_INPUT).

[3] = LOGIN_FORM_PASSWORD_INPUT — текстовое поле ввода пароля (PASSWORD_INPUT).

[4] = LOGIN_FORM_LOGIN_INPUT_ALERT_MESSAGE  — информационное сообщение (ALERT_MESSAGE), которое содержит информацию о поле ввода логина (LOGIN_INPUT).

[5] = LOGIN_FORM_PASSWORD_INPUT_ALERT_MESSAGE — информационное сообщение (ALERT_MESSAGE), которое содержит информацию о поле ввода логина (LOGIN_PASSWORD).

[6] = LOGIN_FORM_SUBMIT — кнопка подтверждения входа (SUBMIT).

[7] = LOGIN_FORM_BADGE_SCAN_GOTO — переход на страницу сканирования бейджа (BADGE_SCAN). Т.к. после нажатия этой кнопки пользователь попадает на другую страницу/форму, атрибут имеет обозначение GOTO.

Теперь рассмотрим абстрактную страницу корзины интернет-магазина.

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

Data-qa можно разместить следующим образом:

[0] = BASKET_PAGE — непосредственно страница (PAGE) корзины (BASKET).

[1] = BASKET_RETURN_BACK — кнопка возвращения на предыдущую страницу. Так как предыдущая страница может быть не всегда одной и той же, обозначить эту кнопку имеет смысл просто как RETURN_BACK.

[2] = BASKET_IN_STOCK_GOTO — переход на вкладку (GOTO) с товарами в наличии (IN_STOCK).

[3] = BASKET_OUT_STOCK_GOTO — переход на вкладку (GOTO) с товарами не в наличии (OUT_STOCK).

[4] = BASKET_SEARCH_INPUT — текстовое поле (INPUT) для ввода поискового запроса (SEARCH).

[5] = BASKET_SEARCH_CLEAR_INPUT — кнопка очистки (CLEAR_INPUT) текстового поля поиска (SEARCH).

[6] = BASKET_QUANTITY_TITLE — заголовок (TITLE) столбца, в котором отображается количество товаров одного типа (QUANTITY).

[7] = BASKET_NAME_TITLE — заголовок столбца, в котором отображается название товара (NAME).

[8] = BASKET_DESCRIPTION_TITLE — заголовок столбца, в котором отображается краткое описание товара (DESCRIPTION).

[9] = BASKET_UNIT_PRICE_TITLE — заголовок столбца, в котором отображается цена за единицу товара (UNIT_PRICE).

[10] = BASKET_TOTAL_PRICE_TITLE — заголовок столбца, в котором отображается цена за все товары одного типа (TOTAL_PRICE).

[11] = BASKET_NO_RESULTS_ALERT_MESSAGE — предупреждающее сообщение (ALERT_MESSAGE), содержащее информацию об отсутствии соответствующих поисковому запросу товаров.

[12] = BASKET_TOTAL_PRICE — нередактируемое текстовое поле с общей стоимостью (TOTAL_PRICE) всего заказа.

[13] = BASKET_ORDER_DELETE_SUBMIT — кнопка подтверждения (SUBMIT) удаления заказа (ORDER_DELETE).

[14] = BASKET_ORDER_PAY_SUBMIT — кнопка подтверждения (SUBMIT) оплаты заказа (ORDER_PAY).

И, наконец, рассмотрим ту же страницу, только с пустой поисковой строкой и одним товаром в корзине.

В данном случае многие элементы точно те же, что и на предыдущем изображении, поэтому заново их можно не размечать, data-qa будут такими же.

Здесь:

[1] = BASKET_PRODUCT_DECREASE_QUANTITY_{ID} — кнопка уменьшения (DECREASE) количества (QUANTITY) конкретного товара (PRODUCT). Идентификатор ID нужен для указания на конкретную строку таблицы (конкретный товар).

[2] = BASKET_PRODUCT_QUANTITY_{ID} — нередактируемое текстовое поле для отображения количества (QUANTITY) конкретного товара (PRODUCT).

[3] = BASKET_PRODUCT_INCREASE_QUANTITY_{ID} — кнопка увеличения (INCREASE) количества конкретного товара.

[4] = BASKET_PRODUCT_NAME_{ID} — нередактируемое текстовое поле для отображения названия товара (NAME).

[5] = BASKET_PRODUCT_DESCRIPTION_{ID} — нередактируемое текстовое поле для отображения краткого описания товара (DESCRIPTION).

[6] = BASKET_PRODUCT_UNIT_PRICE_{ID} — нередактируемое текстовое поле для отображения цены за единицу товара (UNIT_PRICE).

[7] = BASKET_PRODUCT_TOTAL_PRICE_{ID} — нередактируемое текстовое поле для отображения цены за все товары одного типа (TOTAL_PRICE).

[8] = BASKET_PRODUCT_DELETE_{ID} — кнопка удаления товара из корзины (DELETE).

[9] = BASKET_PRODUCT_{ID} — строка товара целиком без указания на конкретный столбец.

Как можно хранить документацию для атрибутов data-qa? В любом удобном виде. В качестве примера приведем таблицу:

Mockup с размеченными data-qa	Список data-qa атрибутов	Ссылки на связанные тикеты	Development status	QA review status
Макет страницы, на котором указаны номера атрибутов data-qa	Список атрибутов data-qa с названиями и номерами, соответствующими обозначениям на дизайн-макете	Список тикетов, которые связаны с веб-страницей, отображенной на макете, и атрибутами data-qa этой страницы	Статус разработки атрибутов data-qa. Например: * пустое поле (не сделано) * в процессе * сделано	Статус тестирования атрибутов data-qa. Например: * пустое поле (не тестировалось) * есть ошибки (MISSING со списком недостающих атрибутов) * проверено (PASSED)

На этом всё. Надеемся, что эта информация окажется полезной. Спасибо за прочтение!