Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Какие элементы подлежат тестированию на веб-странице? Стоит ли тестировать текст и заголовки?


(ivanst) #1

Уважаемые коллеги, попрошу покритиковать стратегию тестирования UI-элементов на веб-странице.

На картинке представлена веб-страница с пояснениями, какие элементы включены в тестирование, а какие - нет.

Особенно интересует мнение о тестировании статического текста (как видно из примера, заголовки, подзаголовки и текст исключены из авто-тестов).

Картинка:

https://docs.google.com/file/d/0B3oS70vN4K6pVm1DSUpIRVFva0E/edit

 


(Sergey Korol) #2

Мне кажется, что вы вязлись за неблагодарное дело. Затраты на автоматизацию тестирования UI и контента себя не оправдают. Вы потратите уйму времени, чтобы подготовить тестовые наборы данных, анализ локаторов для разных браузеров и т.п., а потом клиент вам скажет - "хочу не дерево, а машинку", дизайнер скажет - "машинку надо сделать с 5ю колесами", в итоге девелопер сделает самокат, а вы поседеете от количества вносимых изменений. UI проще и быстрее проверяется руками и глазами по мокапам и какому-нибудь дженерал чеклисту. Единственное, что здесь можно автоматизировать, так это снятие скринов для кросс-браузерного тестирования: подняли хаб, ноды на удаленках с различными ОС и браузерами, передали тесту набор ссылок и вперед, пусть делает скрины. Ну еще бывает полезным автоматизировать тестирование локализации, если заказчик предоставляет весь контент заранее. Не все мы знаем китайсий или арабский, а отсутствие какой-то палочки может вылиться в скандал. :) В остальном, вы потратите кучу времени и нервов впустую. Касательно обоснованности тестирования контента можно еще сослаться на то, что нередко заказчики сами его добавляют через бэкэнд или CMS, и адекватность вносимых изменений возлагается на их же совесть. :)


(Mykhailo Poliarush) #3

вопрос, что вы тестируете? дизайн или функциональность

согласен с на ArtOfLife 100%


(Artem) #4

 

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

А если вам интересно и у вас есть время, то можете автоматизировать свой UI (Будет опыт).

 

P/S

Большинство ребят, которые используют Webdriver, как раз автоматизируют  UI (локаторы, чекеры и т.д). Если не так, то поправьте меня: Хочу услышать подход как вы тестите веб?

Спасибо

 


(apetrovskiy) #5

Большинство ребят, которые используют Webdriver, как раз автоматизируют  UI (локаторы, чекеры и т.д).

Автоматизируют действия, а действия делаются чаще всего через контролы (вэбэлементы), а контролы надо найти...

Если надо тестировать текст или расположение, необязательно делать это каждый прогон теста функциональности. Лучше отдельно.

И можно вовсе другим способом - дампом страничек на диск и сравнением с эталоном или списком, дампом текста и сравнением со списком, поиском через распознавалку текста/картинок и т.д.

 

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

если проект на несколько месяцев или лет, можно вложитьсяи в тексты (особенно, если грозит локализация).

 

 


(ivanst) #6

На мой взгляд, на указанном слайде, нужно проверить работу Top Menu (сверху) и бокса с координатами компании (внизу справа). Этот функционал генерируется CMS. 

В остальном, Ваша позиция мне ясна, и я с ней согласен.

А ссылочку/видео не дадите для автоматизации скринов под различные браузеры?

 


(ivanst) #7

Хотелось бы всё вместе, но, как было озвучено выше, "не благодарное это дело UI тестировать" :)

Так что, ответом на Ваш вопрос будет "Функциональность".


(Sergey Korol) #8

Со ссылочкой / видео вряд ли получится. Это private проект, созданный для удобства работы нашего тима мануальщиков.

Если в двух словах: я писал тулзу на C#, которая обращается к хабу, получает список доступных нодов и предоставляет юзеру выбор - на каких браузерах он хочет проверить заданный набор ссылок. После ввода всех необходимых данных, тулза запускает параметризованную джобу в Jenkins. Последний вытягивает из репозитария исходники с тестами, собирает и формирует при помощи еще одной самописной на C# тулзы TestNG xml для паралелльного запуска тестов в заданных браузерах. Ну а дальше, все как обычно: запуск тестов, снятие скринов и их отправка на почту.