Продолжение интервью «Кому еще нужен Selenium? Использует ли кто BDD в 2020? Машинное обучение в Selenium»

В диалоге участвовали:

• Всеволод Брекелов и Дарья Манухина(программный комитет конференции Heisenbug);
• Анна Чернышова, разработчик библиотеки Akita и нового инструмента Healenium;
• Иван Крутов, разработчик Selenoid.

В конце статьи можно узнать вывод, которым делятся Иван и Анна, а именно ответ на вопрос: «Стоит ли изучать Selenium или выбрать что-то другое?». Помимо этого нам удалось поговорить про:

• Человека-маркировщика и узнать, кто он такой;
• Ценных сотрудников в компаниях;
• Инструментарий тестировщика;
• Инфраструктуру для Selenium тестов;
• Конкурентов Selenium.

Если вы еще не прочитали первую часть интервью, то вот несколько скриншотов о том, что больше всего запомнилось читателям:



Прошлая статья оборвалась на вопросе про машинное обучение. С него и начнем.

— Если машинное обучение будет действительно таким крутым, какая часть останется живым людям, тестировщикам?

Аня: Первое время нужно будет всё валидировать так или иначе. Это хорошо работает, когда у нас есть четкий ответ на вопрос, который машинное обучение решает: «да» или «нет». В зависимости от этих «да» или «нет» машина принимает решение. Когда четкого ответа на этот вопрос нет, там уже нужен…

— Человек-маркировщик специальный.

Иван: Любое машинное обучение состоит из двух частей.

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

Во-вторых, машинное обучение — это в первую очередь про поиск, все поисковые машины в интернете очень активно этим оперируют. Для того чтобы улучшать качество этих алгоритмов приходится обрабатывать огромные объемы данных. Роль человека может свестись к тому, чтобы поддерживать безумного размера инфраструктуру, которая эти данные будет эффективно анализировать. Саму работу будет делать, возможно, алгоритм. Но обеспечить все условия, чтобы этот алгоритм мог работать и чтобы у него было хорошее качество, это всё равно будет человеческая работа.

Обеспечить все условия, чтобы алгоритм мог работать и чтобы у него было хорошее качество, это всё равно будет человеческая работа.

Например, чтобы обучить какое-то большое количество, какой-то хороший алгоритм, нужен распределённый кластер вычислений, какой-нибудь MapReduce бешеный. Для того, чтобы это работало, всё равно нужны люди, которые его либо настроят и будут смотреть за тем, чтобы он нормально работал, или которые его ещё и напишут специально под эту задачу. Машинное обучение — это не очень простая тема. Чем больше хочется, чтобы это работало лучше, тем больше нужно вкладывать. Каждый следующий процент качества, это какие-то бешеные неимоверные увеличения не на проценты, а на порядки.

На начальном этапе это, можно у себя на ноутбуке запустить, а потом, чем лучше хочется, чтобы это работало, тем больше нужно вкладывать.

— То есть даже при наличии такой машинерии мы всё равно не уйдём от того, чтобы запускать тесты на какой-то инфраструктуре, на каких-то машинах. Этот CI/CD с тестами никуда не денется. Поэтому, например, Selenoid точно не уйдёт в прошлое, чего не скажешь про Selenium IDE.

Ваня: Selenium IDE подвержен больше не исчезновению, а тому, что он станет более нишевым инструментом, как и всё, что я до этого говорил. У него, есть команды, кому это реально удобно. Кому-то удобно писать с нуля автотесты, кому-то удобно записать и воспроизвести. Я не склонен прямо так всё хоронить, мне кажется, что это эволюционный процесс.

— Ну да. «Кобол» даже и в тестировании есть, получается.

Ваня: Я же говорю, мейнфреймы! У кого-то Cobol, мейнфреймы и всё работает. Мне кажется, что мы говорим больше про всякие технологические проблемы, а ещё же есть другой нюанс. В конце концов всё упирается в деньги, когда это всё начинает распухать.

Если у нас всё как-то бешено разрослось, например, расходы на машинное обучение, то в какой-то момент встанет вообще вопрос: «Эти расходы вообще оправданы?»

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

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

Если у нас всё как-то бешено разрослось, например, расходы на машинное обучение, то в какой-то момент встанет вообще вопрос: «Эти расходы вообще оправданы?»

Кто такой «полезный сотрудник»?

— Но ведь то, как быстро продукт попадает к пользователю, влияет на экономику. Автоматизация как раз пытается сократить время доставки, чтобы увеличить прибыль и конкурентное преимущество, не так ли?

Ваня: Верно. И сотрудник, который воспринимает деятельность своей компании, как будто это была бы его личная компания. Он считает деньги, думает по крайней мере на эту тему, не считает их в реальных единицах, но думает, что вот это нам будет, наверное, дешевле стоить. Такой сотрудник будет всегда ценным для компании, который будет это говорить на каждой встрече: «Смотрите, ребята, сейчас мы сэкономим, — например, — и поэтому мы прибыли больше получим». Даже если он младший разработчик.

— Кажется, что таких людей на рынке я очень редко встречал.

Ваня: Ну вот! Их мало. Мало, кто думает.

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

Аня: Это зависит от развития организации, от культуры, которую она пропагандирует для своих сотрудников. Я недавно читала книгу «Открывая организации будущего», там есть разные категории организаций, они делятся по цветам.

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

Использование Selenium в 2020

— Как сейчас используют Selenium?

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

Аня: Можно ещё как UI-нагрузочное тестирование его использовать.

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

По сути Selenium это же просто API, которое позволяет кодом с браузерами работать, всё. Любая задача, для которой такой инструмент подходит, может его использовать, не обязательно тестирование, всё что угодно может быть.

Инструментарий тестировщика

— Для решения задач автотестирования, какие инструменты помимо Selenium инженеры обычно выбирают? Берут Java, Allure, Selenoid, Selenide, крутят это всё вместе и получают хороший пулемет, чтобы решать свои повседневные задачи. Или есть ещё что-то?




Аня: Здесь нужно понять из каких уровней будет состоять этот подход к автоматизации. На каждый уровень можно свой инструмент какой-нибудь накрутить.

Первый уровень — это выбрать на чём писать, это Java, .NET, JS? Я больше с Java работала, про неё и буду говорить. Собственно, на чём построить проект — Java. Собрать его можно с помощью Maven или Gradle. Сейчас у Maven прикольные в YAML формате описания pom-ника есть, с ним удобно работать.

Дальше, выбрать чем эти тесты запускать — это JUnit или TestNG какие-нибудь. Я с JUnit 5 в последнее время работаю.

Потом выбрать уровень взаимодействия с элементами. Это Selenium, либо обёртка над ним какая-нибудь, например, Selenide. С ним можно скоратить время на написание тестов.

Дальше нужно проверять результаты тестов. Здесь очень большой выбор инструментов. Можно из JUnit 5 использовать те же самые Assertions, они сейчас в нём довольно удобно сделаны. Либо библиотека Hamcrest, мне она очень нравится. Либо AssertJ тоже удобная вещь. Когда для запуска тестов выбираете этот раннер, то нужно подумать о параллельности запуска тестов, как её будет лучше организовать. В JUnit 5 это удобно, там аннотация просто делается.

Потом уже само написание тестов, это может быть какая-нибудь BDD обёртка, тот же Cucumber. Если выбираете JUnit, то к нему ещё дополнительные вещи потребуются.

Плюс инфраструктура. Я в последнее время с Selenoid работала, мне с ним удобнее всего было.

Ещё отчёты.

— Ну отчёты это, конечно, Allure?

Аня: Ну или ReportPortal.
Я могу объяснить, когда лучше Allure, когда лучше ReportPortal. Allure хорошо, когда маленький проект, тогда он идеально вообще заходит. Если это какой-нибудь большой проект, где 100500 тысяч тестов или это энтерпрайзное решение, или есть понимание, что тестов должно быть очень много и они должны все в какой-нибудь отчёт складываться, то тогда хорош ReportPortal, там удобнее обрабатывать результаты именно большого количества тестов. Когда тестов немного, тогда Allure удобнее.

Ваня: Не знаю, знаете вы или нет, что в первом Allure ещё и я участвовал. Изначально Allure появился в Яндексе, как всем известно, но в итоге получилось, что ребята пошли отдельно его делать. В итоге они просто ту функциональность, которая есть в том же ReportPortal, всякие сложные вещи: хранение истории и так далее, стали делать как отдельный коммерческий продукт, поэтому в обычном Allure это всё не появляется. И они это пытаются продавать. Если вы хотите какой-то опенсорсный отчет для большого количества тестов, то, наверное, ReportPortal, хотя я сам никогда не пробовал. Для небольших проектов каких-то Allure, мне кажется, за глаза.

Эти же все инструменты писались под сложные тесты с довольно длинными сценариями, где нужно было хорошо визуализировать все шаги, что делается во время теста. Эти отчёты не особо подходят под юнит-тесты, потому что там просто ответ «да/нет», упало — не упало.

Инфраструктура для Selenium-тестов

— Ваня, а можешь рассказать подробнее про серверную часть и как часто приходится людям касаться её? (инженерам QA, DevOps-ам).


Изображение: Unsplash

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

Есть тот самый Selenium обычный старый, Selenium или Selenium Grid, или Selenium Server — это приложение, написанное на Java, которое самое старое и самое простое с точки зрения фич. Года три назад от Selenium стандартного, от Selenium Grid отпочковался проект Zalenium. Он уже умеет запускать браузеры в Docker-контейнерах. Этот проект реализует полностью весь стандарт, поддерживает возможность видеозаписи, возможность хранения логов, имеет интерфейс лучше, чем у стандартного Selenium.

Мы же сделали с нуля проект под названием Selenoid. Это тоже совершенно независимая реализация Selenium-протокола. Она написана на Go, не требуется установки Java, ничего не нужно, просто в бинарнике запускается и нужен Docker.

Кроме опенсорса мы делаем реализацию для Kubernetes, это Moon. Это тоже совершенно независимая реализация, которая нужна, если у вас есть Kubernetes. Мы делали упор на то, чтобы развернуть инфраструктуру было просто легко с помощью пары команд. Людям это нравится, что ты две команды ввел и у тебя уже всё работает.

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

Аня: У меня был опыт с SauceLabs, там тоже довольно удобно всё. Просто указываешь в каком браузере запустить, они даже мобильное тестирование поддерживают. И запускаешь. Но они дорого стоят.

Кроссбраузерность и тестирование в мобильных браузерах

— Как, с точки зрения кроссбраузерности и мобилок, работает Selenium, и есть ли какие-то проблемы с инфраструктурой с этим? Я знаю, что некоторые тестируют определенные браузеры на мобилках. К счастью, не тестировал это руками в Selenium, не знаю, насколько это сложно всё настраивать.

Ваня: Это геморно и достаточно дорого. Цель — протестировать, что если мы откроем на каком-то телефоне наше приложение, в каком-нибудь мобильном Chrome, у нас всё работает точно так же. Естественно, мы хотим, как и в случае настольных браузеров, делать это кодом.

Первоначальная простая идея состоит в том, чтобы накупить телефонов разных моделей, положить их на стол. Есть готовые инструменты, например, Appium, которые реализуют стандарт Selenium. Это тоже реализация Selenium-расширения, которая позволяет работать как раз с мобильными. Изначально это делалось как раз под ферму реальных телефонов и планшетов. Проблема в том, что просто опыт эксплуатации таких ферм телефонов показывает, что это очень дорого. Это постоянно ломается, нужно эти телефоны заменять, у них распухают батарейки, это требует довольно специальных систем, которые заряжают эти телефоны, туда нужно ставить обновления, следить, чтобы там ничего не разломалось.

Сейчас всё потихонечку двигается в сторону того, чтобы запускать это всё в эмуляторах. Существуют специальные программы — эмуляторы, которые показывают на экране обычного компьютера или сервера ровно то же самое, что видит пользователь на своём телефоне или планшете. Существуют эмуляторы для Android и для iOS. Проблема заключается в том, что, с точки зрения Android, это виртуалки, такие эмуляторы нельзя запустить на абы каком железе. Если вы хотите Android эмуляторы, вам нужно брать железные сервера, это дорого.

Если вы хотите тестировать на эмуляторах под iOS, вам нужно брать эппловское железо, то есть MacMini, MacPro, MacBook или что-то подобное, это тоже дорого. Это связано с лицензионными ограничениями компании Apple. Поэтому тестирования на мобильных в принципе возможно, понятно как делать инфраструктуру. Даже в Docker можно запускать Android, но это достаточно дорого. Если люди хотят такое делать, им нужно сильно подумать.

Основная задача тестирования на мобильных — найти баги, которые воспроизводятся только на мобильных. Существуют разные способы сделать это дешевле. Есть возможность запускать настольные браузеры вроде Chrome, в котором подсовывается юзер-агент, подсовывается нужное разрешение экрана. Решение о том, нужно ли тестировать на настоящих эмуляторах, на телефонах, нужно принимать исходя из того, можете ли вы отловить баги только на эмуляторе или на телефоне.

Решение о том, нужно ли тестировать на настоящих эмуляторах или на телефонах, нужно принимать исходя из того, можете ли вы отловить баги только на эмуляторе или на телефоне.

Конкуренты Selenium

— Кстати, есть разные инструменты вроде Puppeteer, Playwright, которые позволяют достаточно точно эмулировать и делать кроссбраузерное тестирование в т.ч. в мобильных браузерах. Может на них уже давно все пересели или пересаживаются?

Ваня: Фронтендеры, больше никто не пересел.

Аня: Это клёвые штуки, но у них есть ограничения в плане кроссбраузерности. У Cypress для Firefox вроде выйдет обновление скоро. Ты можешь очень круто быстро писать тесты, всё удобно, но ты ограничен только Chromium-ом.

Ваня: Начнем с Cypress. В 2004-2005 году Selenium работал следующим образом.

Запускался браузер, в него загружалось специальное расширение, в которое запихивались команды по автоматизации браузера. Через 15 лет появились ребята, которые посмотрели на это. От этого подхода в Selenium отказались, потому что не всё можно делать при помощи расширения. Поскольку Javascript, то выполнять можно не всё в браузере, нельзя обращаться к файлам на файловой системе. В Selenium перешли на нативный подход, стали писать отдельные бинари, отдельно стоящие от браузера. Прошло 15 лет. Ребята на JavaScript сделали похожим образом инструмент.

Puppeteer ровно то же самое. Puppeteer это Google Chrome, Chromium, в котором реализован специальный протокол для работы с этой отладочной панели. В Chrome есть отладочная панель, чтобы там можно было сообщения в консоли смотреть, сетевые запросы и так далее.

— Developer tools очень крутая, конечно.

Ваня: Да-да, для разработчика удобная. Как выяснилось, эта штука взаимодействует с браузером по специальному протоколу. Основная идея заключается в том, чтобы в этот протокол не руками мышкой кликать, а чтобы можно было точно так же, как в Selenium, команды слать кодом. Ребята просто написали Javascript-библиотеку, которая реализует протокол.

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

Ваня: По большому счёту эти инструменты хорошие, они нормальные. Они просто нишевые, они хорошо подходят для фронтендеров, потому что у них свои задачи, какие-то тесты погонять быстренько локально, но проблема в том, что они не покрывают требования, которые уже есть.

Есть пачка тестов, например, на Java написанных — бешеный объем, их нужно быстро прогонять, их нужно быстро масштабировать и так далее. Эта задача не решена.

Я не говорю, что эти инструменты плохие. На самом деле даже команды, которые делают Cypress, или команды, которые делают Puppeteer, говорят, что это то же самое, что Selenium. Есть Глеб Бахмутов, который делает Cypress, его спрашивали: Cypress это Selenium или нет? Он отвечал, что это нормальный нишевый инструмент для фронтенд-разработчиков, и я согласен. Мне кажется, что они имеют какую-то общую функциональность, решают какую-то общую задачу, но всё равно у них разные сферы применения.

— Ребята, у вас огромный опыт в использовании Selenium, если бы вы сейчас только начинали тестирование UI, то какой бы инструмент вы сейчас выбрали? С чего всё-таки лучше начинать?

Аня: Я бы начала с Selenium всё равно. Потому что это стандарт.

— Java и Selenium, да?

Аня: Ну можно не Java, можно .NET, Python, но всё равно Selenium к ним, потому что он жил, живёт и будет жить.

Selenium жил, живёт и будет жить.

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

Selenium это простой понятный всем инструмент, которым можно выполнить задачу. Найдётся 100500 миллионов человек, которые расскажут, как пилой распилить бревно. Что-то более нишевое, с одной стороны, в этой нише оно будет круто пилить, но для задач общего назначения всё равно Selenium на данный момент это лучшее, что есть.

Аня: Selenium — это база, которую нужно знать, чтобы потом уметь развиваться дальше и какие-нибудь интересные плюшки к нему добавлять.

— Спасибо вам! Надеюсь, что полученная информация пригодится нашим читателям.

Напоминаем, что конференция Heisenbug 2020 Piter пройдет в онлайне. Там можно будет пообщаться с Ваней и Аней и подробнее узнать про Healenium, Selenoid и использование Chrome DevTools протокола в Kubernetes кластере.

Для тех, кто хочет расширить кругозор и посетить не одну конференцию, а сразу 8 — мы кое-что подготовили.