Каждый раз, когда натыкаюсь на новую статью про то, как использовать BDD-подход и как он улучшает жизнь разработки, тестирования и менеджмента — я хватаюсь за лицо. (А сейчас не знаю как быть. Не хватаюсь за лицо, а просто грущу). Впрочем, такие же ощущения могут вызывать задачи по написанию Selenium тестов. Захотелось поговорить об этом с теми, кто сталкивается с Selenium тестами и разрабатывает различные инструменты для удобной работы с ними.
Мы (Всеволод Брекелов и Дарья Манухина, программный комитет конференции Heisenbug) пообщались с Анной Чернышовой, разработчиком библиотеки Akita и нового инструмента Healenium (ее доклад про BDD), и Иваном Крутовым, разработчиком Selenoid. Иван занимается инфраструктурой для Selenium тестов не первый год (Один из его мастер классов). Обсудили:
— Аня, Ваня, расскажите о себе. Начнем с Ани: расскажи вкратце чем в основном занимаешься.
Аня: У меня сейчас две основные активности: первая — я в EPAM работаю в центре компетенций по тестированию. Это такая группа людей, к которым обращаются за консультациями, за помощью в старте проекта, подборе технологий. Много занимаюсь аудитом тестирования на проектах. Я разбираюсь что не так, что хорошо, что плохо, рекомендую улучшения, делаю PoC. В основном такой консалтинг внутри компании. Второе направление — это акселератор, наш новый Healenium, мы его заопенсорсили относительно недавно, это штука, которая умеет чинить в рантайме поломанные локаторы и держать тесты в актуальном состоянии.
— Здорово! Ваня, а ты? Я знаю, что ты разработчик Selenoid.
Ваня: Я по специализации разработчик. Java, Go — в основном такие вот языки. Хотя начинал сто лет назад. Писал ещё на PHP, когда самое простое было там. В школе писал на всяких паскалях, как и все. В итоге последние лет 6 я занимаюсь тем, что сейчас называется модным словом DevOps, это такая штука на стыке. По должности на русском языке это может называться, например, инженер-программист, это одновременно и разработчик, и человек, который занимается поддержанием инфраструктуры. Например, я отвечаю за работоспособность большого кластера Selenium с достаточно большим количеством браузеров, он отказоустойчивый, распределённый и так далее. Это первая часть. Вторая часть — я занимаюсь всякими опенсорсными и не только проектами. Мы пишем Selenoid, небезызвестный всем в опенсорсе. Также у нас есть коммерческие инструменты. Например, Selenium для Kubernetes — это отдельный продукт, делаем облачные решения для Selenium, ну и многое другое. Есть ещё продуктовое направление, профессионально разрабатываем инструменты для Selenium: открытые и закрытые — разные. Такая деятельность. По конференциям, естественно, езжу, выступаю, просвещаю людей, как эффективно строить Selenium на основе имеющегося у меня опыта.
— Ты сказал немного про Selenoid. Я знаю, что Selenoid — это проект организации Aerokube. Можешь рассказать как это? Это сообщество или это организация? Коммерческая организация или как это вообще появилось?
Ваня: Это и то и другое. На самом деле изначально это было просто сообщество, завели организацию фактически на GitHub для того, чтобы делать опенсорсные эффективные инструменты для Selenium. Это делалось в свободное от работы время, от основной работы. Получилось сделать первый инструмент Selenoid, потом в итоге мы поняли, что для того чтобы иметь возможность нормально обеспечивать, так сказать, эффективную разработку этого Selenoid нужно одно из двух.
Все хорошие опенсорсные продукты развиваются по одному из двух направлений. Первое — когда они делаются в какой-то крупной компании, которая их просто спонсирует, платит зарплату разработчикам, а второй вариант — когда есть бесплатное опенсорсное решение, а есть какой-то платный продукт, похожий или другой, за счёт которого монетизируется разработка. В итоге, когда у нас Selenoid полетел, мы просто приняли решение и оформили это в виде компании. Теперь это уже коммерческая организация, которая имеет опенсорс и имеет свои продукты.
— То есть ты в ней работаешь, получается?
Ваня: Да.
— Хорошо. Аня, ты писала библиотеку Akita, которая разрабатывалась в Альфа-Банке. Ты до сих пор используешь её где-то активно? Или она так и осталась в Альфе и всё?
Аня: Она разрабатывалась как раз в рамках Альфа-Банка. В первую очередь она была для их нужд. Потом мы её заопенсорсили, потому что показалось, что она может быть ещё кому-то полезна. Насколько я знаю, в банке её сейчас используют, конечно, и ещё, может, около десятка сторонних организаций. Но я сейчас с ней не работаю.
— Ты продвигала BDD. Ты где-то его сейчас продвигаешь или это уже не та тема, которой ты активно занимаешься?
Аня: Это тоже зависит от ситуации. Если приходит заказчик и говорит, что я хочу быть в курсе того, что происходит, тогда да, им этот подход хорошо ложится. Если этим занимаются фича-команды, либо тестирование вынесено отдельно как сервис, то тогда в этих случаях я это не продвигаю. С BDD я какое-то время уже не работала, сейчас в основном это self-healing автоматизация.
— BDD в 2020 году это окей?
Аня: Я думаю, что окей, но зависит от ситуации. Сейчас у нас в этом же Альфа-Банке self-healing с BDD тестируют и всё нормально. Типа его можно апдейтить, именно этот BDD-подход делать более стабильным и тогда это хорошо работает.
Ваня: По сути BDD — это же для менеджеров было изначально. Чтобы человек, не имеющий очень глубоких компетенций в разработке тестов мог тем не менее довольно легко прочитать, как тестируется продукт, разобраться. Мне кажется, до тех пор, пока организационно вся разработка строится так, что есть руководители-менеджеры, которые имеют разные компетенции и есть разработчики, я думаю, что BDD имеет смысл, почему нет?
Аня: Ещё есть ситуации, например, как в банке были, что в командах просто не было тестировщика, и нужно было это как-то тестировать, и аналитики сказали: «вот мы хотим!». Для них как раз этот инструмент в том числе и разрабатывался. Приходили практически к этой идеальной формулировке BDD, что аналитики тоже задействованы в написании сценариев, и им было удобно руководствоваться этим верхнеуровневым описанием шагов, чтобы составлять тесты, и они могли автоматически запускаться.
— Этот холивар до сих пор идёт, кто же всё-таки должен писать тесты на BDD? Например, есть какая-то организация, у которой нет ещё BDD, и непонятно нужен он или не нужен, и кто должен эти тесты писать. В идеальном мире что бы вы посоветовали?
Ваня: Мне кажется, это сильно зависит от количества всего.
Аня: Да, и от ситуации сильно зависит. Если это feature team, где есть все представители этих ролей и какой-нибудь тестировщик с хорошими хард скиллами, и таких команд много, и именно так организация строится, то им BDD вряд ли нужен будет. Если это команда, где нет тестировщика, либо у тестировщика слабые хард скиллы, например, это в основном ручное тестирование, то тогда этот подход тоже будет применим, потому что тестировщик сможет ещё и автоматизацией заниматься сразу же.
— То есть если у вас очень много денег и вы наняли очень много людей, которые некомпетентны технически, то BDD вам подходит?
Аня: В принципе можно так сказать.
Ваня: Мне вообще кажется, что не только BDD, а любое тестирование при планировании должно сильно отталкиваться от денег.
У нас так сложилось, что большинство конференций всё-таки в техническую или в философскую сторону двигаются. Не принято что ли говорить о том, что в любом случае всё равно мы работаем в компаниях, у которых есть бюджеты, у которых есть какое-то ограниченное количество денег. Все решения, которые принимает руководство, оно всё равно в конце концов упирается в эти самые деньги. Тут никуда не денешься. Просто программисты, тестировщики и аналитики, мы варимся в таком «ограниченном» мире, где нам про них не говорят, могут сказать только «делаем» или «не делаем». Мне кажется, что и тестирование, и планирование разработки, и всё остальное — нужно всегда отталкиваться от имеющегося бюджета, не более того. Всё равно всё упирается туда.
— Если говорить о том, BDD для аутсорсного проекта и для внутреннего — есть какая-то разница или нет? Если бюджет позволяет, нужен BDD на аутсорс?
Аня: Здесь опять-таки да, всё в бюджет упирается. Не знаю, на аутсорс я, наверное, лично BDD бы не отдавала, но если, конечно, заказчик прям сильно не хочет. Если говорит: «хочу BDD и всё, мне вот всё равно!» — вот тогда да. Но на это нужны будут такие скилованные ребята, чтобы они красиво это всё обернули в какой-нибудь красивый фреймворк. Обычно на аутсорс приходят клиенты, которые говорят: «Я быстро хочу какую-нибудь автоматизацию», — или — «У меня нет автоматизации, постройте», — или — «У меня всё плохо, давайте что-то как-то обновим». Обычно в таких ситуациях их решение требует более глубокого технического понимания и автоматизации на техническом уровне.
Хотя если ложится клиенту хорошо и можно быстро стартануть автоматизацию, тоже, наверное, от времени зависит. Если можно таким способом быстро стартануть и достичь цели, которую хочет клиент, то тогда да, может лечь.
— Кажется, что BDD для аутсорса это не только про то, как написать им проект, выяснив требования, а ещё про то, чтобы научить клиентов вообще понимать, что там. Потому что обучение каких-нибудь аналитиков или даже менеджеров пониманию того, как они должны сценарии составлять, если будут в дальнейшем — это тоже отдельная история.
Аня: Да, в этом могут быть свои сложности.
Ваня: Возвращаясь к вопросу о том, является ли BDD нормальным в 2020 году, мне кажется, есть какая-то определённая эволюция, это я так в философскую сторону ухожу…
У нас со временем появляются всякие новые подходы и технологии, и мне кажется, не бывает такого, чтобы технология полностью умерла. Например, 40 лет назад, когда развивались именно компьютеры, были мейнфреймы эти огромные машины, которые сейчас практически умерли, тем не менее остались определённые ниши, где они до сих пор существуют и отлично работают.
Фотография с сайта www.kmd.dk
Я буквально недавно общался с человеком, он как-то с банками связан, с какими-то старыми американскими, он говорит: «У нас стоит всё сорокалетней давности, всё работает, потому что дешевле это всё поддерживать, чем переписать на новое». Точно так же, я думаю, и в тестировании, появляются новые подходы, появилось BDD. Я не думаю, что оно вообще умрёт, оно останется в каких-то нишах, даже если придумают что-то лучше этого. Так с любым продуктом, с любой технологией. Нельзя, с одной стороны, полностью, на сто процентов захватить весь рынок, с другой стороны, и умереть тоже полностью — нужно постараться, чтобы это произошло, всегда остаются какие-то ниши. Вопрос в том, какая их доля в общей массе людей.
— Все решения очень бизнес-ориентированы всегда, и как ты сказал, обычные инженеры не особо думают о деньгах, о бизнесе и о рисках бизнеса и не понимают, может быть, зачастую, почему такие решения.
Ваня: Часто задают вопрос: как вырасти в компании? Приходят младшие разработчики, джуниоры и, естественно, у них в голове цель — как бы вырасти. В конечном счёте в какой-то момент начинаешь чувствовать бизнес-требование, что там деньги нужно считать и так далее. По сути дела, способ вырасти в какого-то более высокого уровня начальника-разработчика — это начать даже на такой невысокой должности думать о том, а как бы ты с точки зрения бизнеса это начал делать. Не с точки зрения, какой бы я сейчас клёвый новый язык попробую или ещё что-то, это круто для личной экспертизы собственной, но с точки зрения бизнеса, если хочется вырасти, мне кажется, нужно вот про это больше думать.
В своё время слышал умного человека. Он рассказывал, что существуют разные способы вырасти карьерно. Он перечислил три основных способа. Первый способ — это быть чьим-то родственником. Такого обычно мало, маленькое количество людей, у кого есть какие-то там родственники высокие руководители. Второй способ — это заниматься манипуляциями. Всякие интриги плести в компании и так далее. Таких людей, которые умеют это делать, тоже мало. И третий способ — это доказывать работой свою полезность компании. Основная идея роста заключается в том, чтобы в компании найти такую нишу, в которой есть проблемы. И предложить своему руководству, как эти проблемы эффективно решить, вот в таком случае можно сильно вырасти.
— Ваня, ты сказал, что для того чтобы развиваться разработчик должен думать о бизнесе дальше. Должны ли разработчики общаться с пользователями своих продуктов? У меня, например, есть в команде ребята, которые говорят: «Ой, знаете, я пришёл писать код, для того чтобы с миром вообще не общаться! Пишите мне ТЗ хоть километровое, я буду сидеть, писать код».
Ваня: Тут всё очень сильно зависит от человека и от команды. По большому счёту, если человек хочет развиваться и расти, ему всё равно в какой-то момент придётся это делать. До какого-то момента времени за него будет общаться менеджер, если он у него есть, но если он в итоге хочет развиваться, ему придётся это делать. Чем ведущий разработчик отличается от старшего? Тем, что у него есть очень хорошая экспертиза и тем, что он умеет решать такие уже полуменеджерские задачи. Он умеет нести полную ответственность за тот продукт, который он делает от составления требований до непосредственно разработки, вот в этом отличие, мне кажется.
Аня: Да, здесь идёт понимание того, для чего ты что-либо делаешь, а не просто так сделать — клёво будет.
— Давайте поговорим про Selenium, раз уж тут собрались специалисты этой тематики. Есть вопрос от телезрителя: «Почему кто-то до сих пор выбирает писать тесты на Selenium? Насколько вообще это оправданный выбор, учитывая что можно писать на разных уровнях тесты и, может быть, вообще никогда не добраться до тестов на Selenium?»
Аня: Сейчас часто говорят, что Selenium умирает. Какие-то другие инструменты приходят на его место. Мне кажется, что это не совсем так и всё равно всё зависит от экспертизы. В любом случае большинство проектов сейчас на Selenium делается и делалось на нём. Нужна будет поддержка, и если как специалист по тестированию хочешь куда-нибудь устроиться, то, скорее всего, это будет Selenium. Экспертизы в этой области, наверное, гораздо больше, плюс когда выходят какие-то новые технологии на рынок, она может бомбануть и потом скатиться куда-нибудь. Selenium покрывает, я бы сказала, все возможности юайного тестирования. И это такая как бы мощная штука, которая в ближайшее время точно не умрёт.
Ваня: Я ещё хочу дополнить. С технологиями всегда есть определённая инерция. Selenium, как известно, существует с 2004 года, ему уже 15 лет. Он, конечно, тоже меняется сам по себе, тем не менее за это время накопилось довольно большое количество уже готовых проектов. Для программирования 15 лет назад — это каменный век по сравнению с тем, что есть сейчас. И накоплено больше опыта именно в Selenium. Просто начать даже съезжать на какую-то новую технологию, если ты уже опытный автоматизатор, это сложно, это реально инерция.
Поскольку продукт существует долго, по нему накоплена большая база знаний, подводные камни, даже если — это проблема не только Selenium, это вообще проблема любой новой технологии, — чтобы она полетела, нужно набрать какую-то критическую массу из знаний, пользователей и так далее.
У Selenium есть критическая масса пользователей, есть форумы, сообщества, Stack Overflow, куча документации, куча конференций и специалистов, которые могут эти знания передавать постоянно. Как только возникает новая технология, она может полететь сейчас только в том случае, если в неё будет вбухана куча денег — и всё упирается в деньги.
Есть пример не про тестирование, а про разработку. Есть язык программирования Kotlin. Он сейчас, как выяснилось, полетел в мобильном направлении, прям летит-летит. Говорят, ходят какие-то слухи о том, что просто в его продвижение вложено довольно приличное количество денег, чтобы он в конференциях везде упомянался, чтобы люди разрабатывали фреймворки. Так много с чем происходит. Чтобы преодолеть инерцию, нужно затратить какое-то количество ресурсов. Просто сделав хороший продукт, даже если он реально лучше Selenium, сложно его продвинуть.
Почему Selenium? Потому что это теперь стандарт. Есть конкретный World Wide Web Консорциум, который взял и зафиксировал стандарт Selenium. Всегда лучше работать с инструментами, которые стандартизованы. Выбирая между двумя инструментами, можно сказать: «Здесь у нас всё зафиксировано, API стабильное, всё хорошо, а вот есть какое-то непонятное поделие сбоку, которое тоже делает какая-то компания, непонятно сколько она просуществует». При выборе между этими двумя инструментами, как правило, разумный менеджер обычно делает выбор в пользу чего-то более стандартного. Мне кажется, что писать тесты на Selenium имеет смысл, потому что даже какому-то начинающему специалисту сейчас проще это сделать. Порог входа будет ниже — больше тех, у кого можно спросить про Selenium.
Вторая причина, почему нужно продолжать писать тесты на Selenium, почему вообще нужно писать тесты на UI. Фактически написание тестов на UI, таких вот end-to-end — это единственный способ проверить, что приложение работает ровно так же, как это увидит пользователь. Даже если мы пишем всякие юниты и всё остальное, покрываем разными типами тестирования, это не даёт стопроцентной гарантии. Только проиграв те же самые действия, которые будет делать пользователь приложения, мы можем быть на сто процентов уверены, что у нас приложение работает. Понятно, что не нужно все сто процентов кода таким образом проходить. Обычно покрываются самые критически важные сценарии в приложении, но тем не менее это важно.
Аня: По поводу новых инструментов хотела ещё добавить. Когда-то слышала умного дядьку на конференции. Он рассказывал про старт новых технологий и как понять, какая технология умрёт, какая задержится. У любой технологии, которая на рынок выходит, она начинает набирать то, что Ваня как раз говорит, критическую массу. Потом у неё происходит бум, и вот этот бум нужно как бы переждать, потому что после этого бума либо эта технология остаётся, его выдерживает, дальше у неё будет своё развитие и скачок, либо она после этого умрёт. Это тоже зависит от инвестиций, от того, успевает ли команда разработки справиться с тем потоком пользователей, которые на них приходят, потоком багов, либо направлений для дальнейшего развития, либо нет. Вот так сразу хвататься за что-нибудь, что находится на хайпе и переводить свои тесты на эту технологию, это, мне кажется, будет неоправданно.
— Как вам кажется, много ли изменилось в Selenium? Изменилось ли вообще что-то за последние два года драматически в этом инструменте и эволюционирует ли он как-то?
Ваня: Мне кажется, он довольно сильно меняется. Года два или три назад было ощущение, что в нём какой-то застой был, потому что по сути дела Selenium придумали в 2004 году, потом он развивался-развивался-развивался, потом в 2008-2009 году придумали Selenium WebDriver, придумали Selenium Grid. После этого лет пять они просто допиливали его, выкатывали какие-то небольшие фичи, в общем сильно ничего не менялось. У всех стоял Selenium Grid, у всех была стандартная библиотека Selenium.
А вот последние года 2-3 пошёл бум всяких новых продуктов, основанных на Selenium. Мы, например, сделали Selenoid. Ребята, которые работали в тот момент в компании Zalando, на основе Selenium Grid сделали такой инструмент как Zalenium, тоже Selenium-совместимое решение. По сути оба инструмента были сделаны для того, чтобы решить какие-то конкретные проблемы, для которых не было решения в оригинальном коде. Потом появились ещё другие, конкуренты самого Selenium. Сейчас, мне кажется, последние года два или три пошла какая-то такая движуха-движуха.
Мне кажется, что Selenium развивается, плюс ещё в начале 2018 года зафиксировали стандарт. Поэтому Selenium, конечно, с одной стороны, как инструмент довольно сильно заматерел. С другой стороны команде, которая развивала первоначально основной код, удалось навязать ответственность за поддержание совместимости со стандартом другим командам разработчиков браузеров. Если раньше фактически весь Selenium был какой-то единый, в котором всё лежало, все драйверы, то теперь им удалось договориться со всеми командами. Apple для Safari делает поддержку, потому что есть стандарт и не нужно ни с кем согласовывать. Google делает для Chrome поддержку, Mozilla делает для Firefox. Фактически теперь это уже распределённая экосистема, там есть несколько разных точек. Сейчас Microsoft тоже делает для своих браузеров своё, для Edge он делал свой драйвер, и им удалось ответственность распределить. За счёт этого, мне кажется, произошёл довольно приличный скачок в качестве.
— Да, три года назад, я помню, чтобы тесты на Selenium на Safari бежали, нужно было себя так выкрутить. В общем больно было.
Ваня: А теперь всё по стандарту сделано более-менее. Там, конечно, есть какие-то свои особенности, но по сути всё стало единообразно, то есть произошла такая унификация того, как это всё работает внутри. Мне кажется, это круто, там много усилий было вложено в это всё. Поэтому я не считаю, что сейчас в Selenium есть какой-то застой. Сейчас там есть здоровая конкуренция разных решений.
Мы в каком-то смысле конкурируем с ребятами, которые делают основной код Selenium. Приезжаем на конференции, говорим, что ребята, ваше не эффективное потому, потому и потому. Чтобы как-то доказать, что всё-таки они тоже молодцы, им приходится делать своё. Происходит здоровая конкуренция.
Аня: По поводу Selenium IDE ещё хочется добавить, про которую вообще, мне кажется, все давно забыли. С появлением новых инструментов по script-less автоматизации они опять взялись за Selenium IDE. В течение 2019 года очень сильно её развивали и планируется масштабный релиз в начале 2020 года, где они что-то представят. Очень сильно поменялся интерфейс у IDE и она стала более стабильной и удобной, скажем так.
Ваня: Хотел ещё добавить, что сейчас к Selenium стали пытаться прикладывать разные технологии, которые до этого не применялись, например, то же самое машинное обучение.
Это одно из направлений, которое до сих пор не существовало в Selenium. Люди, попользовавшись Selenium лет 10, обнаружили какое-то количество задач, которые, как выяснилось, могут быть частично или полностью решены при помощи машинного обучения. Всякие рутинные операции.
— Аня, расскажи, что за проблемы вы решаете машинным обучением? Всё за нас будут писать? У нас сейчас искусственный интеллект начинает проникать вообще везде. Если вбить в Google «AI и Selenium» — там начинают люди разрабатывать свои какие-то библиотеки, выкладывать, ещё что-то, то есть развитие идёт.
Аня: Относительно Selenium могу сказать, что в последнее время гораздо удобнее на основе него делать всякие решения, ну в частности это за счёт его стандартизации. По поводу возможностей, самое главное нужно — это взаимодействовать с элементами на странице. И соответственно эта часть уже ложится, на тестировщиков, как это взаимодействие описать, используя Selenium. Если это описывать чисто используя Selenium, то могут быть нестабильные тесты, потому что какие-то там изменения произойдут на UI, какого-то элемента не дождутся и так далее. Машинное обучение начинают именно к этому месту прикладывать, чтобы можно было эти тесты стабилизировать. Чтобы эти тесты можно было сгенерить на основе информации, которая имеется у нас на странице, и на основе поведения пользователя.
В тренде было Record and Play, то, что делает как раз Selenium IDE: мы заходим на страницу, накликиваем действие, у нас создаются тесты. Эти тесты должны быть стабильные. Машинное обучение нужно там именно для этого. Обычно локаторы захардкожены, поэтому при изменениях на UI их необходимо обновить. Healenium, который мы сейчас делаем, например, позволяет в рантайме их обновить, и наш тест, соответственно, пройдёт.
Сейчас появляется такая тенденция не чисто к Record and Play тестам, а к возможности генерации тестов. Мы знаем, какие у нас есть элементы на странице. Мы можем нарисовать некую логическую схему нашего сайта. Мы знаем, что у нас есть главная страничка, от неё страничка логина и ещё чего-то. Основываясь на этих логических связях и действиях, которые мы можем делать на этой странице, мы можем сгенерировать тесты. Но таких инструментов на рынке, которые прям очень хорошо это сделали, я пока не знаю. Healenium мы хотим развивать как раз в этом направлении.
С развитием этих подходов и знаний в области machine learning в ближайшее время будет уклон в развитие и появление таких инструментов. Например, краулеров сайтов, которые могут автоматически провести тестирование вместо написания тест-кейсов.
— Вот Ваня сказал, что Selenium IDE обновляют. В общем, не то они делают. Скоро машинное обучение всё за них решит и это IDE даже не нужно будет.
А если машинное обучение будет действительно таким крутым, то какая часть останется живым людям, тестировщикам?
Предлагаю обсудить этот вопрос в комментариях. А в продолжении этого интервью мы узнаем ответы Анны и Ивана. Кстати, на конференции Heisenbug 2020 Piter, которая пройдет в онлайне, можно будет пообщаться с ними и подробнее узнать про Healenium, Selenoid и использование Chrome DevTools протокола в Kubernetes кластере.
Недавно вышла вторая часть интервью с ответом на вопрос про ML в тестировании: узнали, кто такой человек-маркировщик, и разобрались, нужно ли изучать Selenium в 2020 году.
Мы (Всеволод Брекелов и Дарья Манухина, программный комитет конференции Heisenbug) пообщались с Анной Чернышовой, разработчиком библиотеки Akita и нового инструмента Healenium (ее доклад про BDD), и Иваном Крутовым, разработчиком Selenoid. Иван занимается инфраструктурой для Selenium тестов не первый год (Один из его мастер классов). Обсудили:
- BDD подход в 2020;
- Selenium и его развитие;
- Карьерный рост;
- Машинное обучение и Selenium.
Интервью состоит из двух частей: во второй поговорили про инфраструктуру Selenium-тестов, инструментарий тестировщика и ответили на вопрос, который прозвучал в конце этого поста.
Много букв про собеседников
— Аня, Ваня, расскажите о себе. Начнем с Ани: расскажи вкратце чем в основном занимаешься.
Аня: У меня сейчас две основные активности: первая — я в EPAM работаю в центре компетенций по тестированию. Это такая группа людей, к которым обращаются за консультациями, за помощью в старте проекта, подборе технологий. Много занимаюсь аудитом тестирования на проектах. Я разбираюсь что не так, что хорошо, что плохо, рекомендую улучшения, делаю PoC. В основном такой консалтинг внутри компании. Второе направление — это акселератор, наш новый Healenium, мы его заопенсорсили относительно недавно, это штука, которая умеет чинить в рантайме поломанные локаторы и держать тесты в актуальном состоянии.
— Здорово! Ваня, а ты? Я знаю, что ты разработчик Selenoid.
Ваня: Я по специализации разработчик. Java, Go — в основном такие вот языки. Хотя начинал сто лет назад. Писал ещё на PHP, когда самое простое было там. В школе писал на всяких паскалях, как и все. В итоге последние лет 6 я занимаюсь тем, что сейчас называется модным словом DevOps, это такая штука на стыке. По должности на русском языке это может называться, например, инженер-программист, это одновременно и разработчик, и человек, который занимается поддержанием инфраструктуры. Например, я отвечаю за работоспособность большого кластера Selenium с достаточно большим количеством браузеров, он отказоустойчивый, распределённый и так далее. Это первая часть. Вторая часть — я занимаюсь всякими опенсорсными и не только проектами. Мы пишем Selenoid, небезызвестный всем в опенсорсе. Также у нас есть коммерческие инструменты. Например, Selenium для Kubernetes — это отдельный продукт, делаем облачные решения для Selenium, ну и многое другое. Есть ещё продуктовое направление, профессионально разрабатываем инструменты для Selenium: открытые и закрытые — разные. Такая деятельность. По конференциям, естественно, езжу, выступаю, просвещаю людей, как эффективно строить Selenium на основе имеющегося у меня опыта.
— Ты сказал немного про Selenoid. Я знаю, что Selenoid — это проект организации Aerokube. Можешь рассказать как это? Это сообщество или это организация? Коммерческая организация или как это вообще появилось?
Ваня: Это и то и другое. На самом деле изначально это было просто сообщество, завели организацию фактически на GitHub для того, чтобы делать опенсорсные эффективные инструменты для Selenium. Это делалось в свободное от работы время, от основной работы. Получилось сделать первый инструмент Selenoid, потом в итоге мы поняли, что для того чтобы иметь возможность нормально обеспечивать, так сказать, эффективную разработку этого Selenoid нужно одно из двух.
Все хорошие опенсорсные продукты развиваются по одному из двух направлений. Первое — когда они делаются в какой-то крупной компании, которая их просто спонсирует, платит зарплату разработчикам, а второй вариант — когда есть бесплатное опенсорсное решение, а есть какой-то платный продукт, похожий или другой, за счёт которого монетизируется разработка. В итоге, когда у нас Selenoid полетел, мы просто приняли решение и оформили это в виде компании. Теперь это уже коммерческая организация, которая имеет опенсорс и имеет свои продукты.
— То есть ты в ней работаешь, получается?
Ваня: Да.
— Хорошо. Аня, ты писала библиотеку Akita, которая разрабатывалась в Альфа-Банке. Ты до сих пор используешь её где-то активно? Или она так и осталась в Альфе и всё?
Аня: Она разрабатывалась как раз в рамках Альфа-Банка. В первую очередь она была для их нужд. Потом мы её заопенсорсили, потому что показалось, что она может быть ещё кому-то полезна. Насколько я знаю, в банке её сейчас используют, конечно, и ещё, может, около десятка сторонних организаций. Но я сейчас с ней не работаю.
— Ты продвигала BDD. Ты где-то его сейчас продвигаешь или это уже не та тема, которой ты активно занимаешься?
Аня: Это тоже зависит от ситуации. Если приходит заказчик и говорит, что я хочу быть в курсе того, что происходит, тогда да, им этот подход хорошо ложится. Если этим занимаются фича-команды, либо тестирование вынесено отдельно как сервис, то тогда в этих случаях я это не продвигаю. С BDD я какое-то время уже не работала, сейчас в основном это self-healing автоматизация.
Использование BDD в 2020 году. Это шутка?
— BDD в 2020 году это окей?
Аня: Я думаю, что окей, но зависит от ситуации. Сейчас у нас в этом же Альфа-Банке self-healing с BDD тестируют и всё нормально. Типа его можно апдейтить, именно этот BDD-подход делать более стабильным и тогда это хорошо работает.
Ваня: По сути BDD — это же для менеджеров было изначально. Чтобы человек, не имеющий очень глубоких компетенций в разработке тестов мог тем не менее довольно легко прочитать, как тестируется продукт, разобраться. Мне кажется, до тех пор, пока организационно вся разработка строится так, что есть руководители-менеджеры, которые имеют разные компетенции и есть разработчики, я думаю, что BDD имеет смысл, почему нет?
Аня: Ещё есть ситуации, например, как в банке были, что в командах просто не было тестировщика, и нужно было это как-то тестировать, и аналитики сказали: «вот мы хотим!». Для них как раз этот инструмент в том числе и разрабатывался. Приходили практически к этой идеальной формулировке BDD, что аналитики тоже задействованы в написании сценариев, и им было удобно руководствоваться этим верхнеуровневым описанием шагов, чтобы составлять тесты, и они могли автоматически запускаться.
— Этот холивар до сих пор идёт, кто же всё-таки должен писать тесты на BDD? Например, есть какая-то организация, у которой нет ещё BDD, и непонятно нужен он или не нужен, и кто должен эти тесты писать. В идеальном мире что бы вы посоветовали?
Ваня: Мне кажется, это сильно зависит от количества всего.
Аня: Да, и от ситуации сильно зависит. Если это feature team, где есть все представители этих ролей и какой-нибудь тестировщик с хорошими хард скиллами, и таких команд много, и именно так организация строится, то им BDD вряд ли нужен будет. Если это команда, где нет тестировщика, либо у тестировщика слабые хард скиллы, например, это в основном ручное тестирование, то тогда этот подход тоже будет применим, потому что тестировщик сможет ещё и автоматизацией заниматься сразу же.
— То есть если у вас очень много денег и вы наняли очень много людей, которые некомпетентны технически, то BDD вам подходит?
Аня: В принципе можно так сказать.
Ваня: Мне вообще кажется, что не только BDD, а любое тестирование при планировании должно сильно отталкиваться от денег.
У нас так сложилось, что большинство конференций всё-таки в техническую или в философскую сторону двигаются. Не принято что ли говорить о том, что в любом случае всё равно мы работаем в компаниях, у которых есть бюджеты, у которых есть какое-то ограниченное количество денег. Все решения, которые принимает руководство, оно всё равно в конце концов упирается в эти самые деньги. Тут никуда не денешься. Просто программисты, тестировщики и аналитики, мы варимся в таком «ограниченном» мире, где нам про них не говорят, могут сказать только «делаем» или «не делаем». Мне кажется, что и тестирование, и планирование разработки, и всё остальное — нужно всегда отталкиваться от имеющегося бюджета, не более того. Всё равно всё упирается туда.
BDD в аутсорсе или у себя?
— Если говорить о том, BDD для аутсорсного проекта и для внутреннего — есть какая-то разница или нет? Если бюджет позволяет, нужен BDD на аутсорс?
Аня: Здесь опять-таки да, всё в бюджет упирается. Не знаю, на аутсорс я, наверное, лично BDD бы не отдавала, но если, конечно, заказчик прям сильно не хочет. Если говорит: «хочу BDD и всё, мне вот всё равно!» — вот тогда да. Но на это нужны будут такие скилованные ребята, чтобы они красиво это всё обернули в какой-нибудь красивый фреймворк. Обычно на аутсорс приходят клиенты, которые говорят: «Я быстро хочу какую-нибудь автоматизацию», — или — «У меня нет автоматизации, постройте», — или — «У меня всё плохо, давайте что-то как-то обновим». Обычно в таких ситуациях их решение требует более глубокого технического понимания и автоматизации на техническом уровне.
Хотя если ложится клиенту хорошо и можно быстро стартануть автоматизацию, тоже, наверное, от времени зависит. Если можно таким способом быстро стартануть и достичь цели, которую хочет клиент, то тогда да, может лечь.
— Кажется, что BDD для аутсорса это не только про то, как написать им проект, выяснив требования, а ещё про то, чтобы научить клиентов вообще понимать, что там. Потому что обучение каких-нибудь аналитиков или даже менеджеров пониманию того, как они должны сценарии составлять, если будут в дальнейшем — это тоже отдельная история.
Аня: Да, в этом могут быть свои сложности.
Ваня: Возвращаясь к вопросу о том, является ли BDD нормальным в 2020 году, мне кажется, есть какая-то определённая эволюция, это я так в философскую сторону ухожу…
У нас со временем появляются всякие новые подходы и технологии, и мне кажется, не бывает такого, чтобы технология полностью умерла. Например, 40 лет назад, когда развивались именно компьютеры, были мейнфреймы эти огромные машины, которые сейчас практически умерли, тем не менее остались определённые ниши, где они до сих пор существуют и отлично работают.
Я буквально недавно общался с человеком, он как-то с банками связан, с какими-то старыми американскими, он говорит: «У нас стоит всё сорокалетней давности, всё работает, потому что дешевле это всё поддерживать, чем переписать на новое». Точно так же, я думаю, и в тестировании, появляются новые подходы, появилось BDD. Я не думаю, что оно вообще умрёт, оно останется в каких-то нишах, даже если придумают что-то лучше этого. Так с любым продуктом, с любой технологией. Нельзя, с одной стороны, полностью, на сто процентов захватить весь рынок, с другой стороны, и умереть тоже полностью — нужно постараться, чтобы это произошло, всегда остаются какие-то ниши. Вопрос в том, какая их доля в общей массе людей.
Карьерный рост
— Все решения очень бизнес-ориентированы всегда, и как ты сказал, обычные инженеры не особо думают о деньгах, о бизнесе и о рисках бизнеса и не понимают, может быть, зачастую, почему такие решения.
Ваня: Часто задают вопрос: как вырасти в компании? Приходят младшие разработчики, джуниоры и, естественно, у них в голове цель — как бы вырасти. В конечном счёте в какой-то момент начинаешь чувствовать бизнес-требование, что там деньги нужно считать и так далее. По сути дела, способ вырасти в какого-то более высокого уровня начальника-разработчика — это начать даже на такой невысокой должности думать о том, а как бы ты с точки зрения бизнеса это начал делать. Не с точки зрения, какой бы я сейчас клёвый новый язык попробую или ещё что-то, это круто для личной экспертизы собственной, но с точки зрения бизнеса, если хочется вырасти, мне кажется, нужно вот про это больше думать.
Способ вырасти в какого-то более высокого уровня начальника-разработчика — это начать даже на такой невысокой должности думать о том, а как бы ты с точки зрения бизнеса это начал делать.
В своё время слышал умного человека. Он рассказывал, что существуют разные способы вырасти карьерно. Он перечислил три основных способа. Первый способ — это быть чьим-то родственником. Такого обычно мало, маленькое количество людей, у кого есть какие-то там родственники высокие руководители. Второй способ — это заниматься манипуляциями. Всякие интриги плести в компании и так далее. Таких людей, которые умеют это делать, тоже мало. И третий способ — это доказывать работой свою полезность компании. Основная идея роста заключается в том, чтобы в компании найти такую нишу, в которой есть проблемы. И предложить своему руководству, как эти проблемы эффективно решить, вот в таком случае можно сильно вырасти.
— Ваня, ты сказал, что для того чтобы развиваться разработчик должен думать о бизнесе дальше. Должны ли разработчики общаться с пользователями своих продуктов? У меня, например, есть в команде ребята, которые говорят: «Ой, знаете, я пришёл писать код, для того чтобы с миром вообще не общаться! Пишите мне ТЗ хоть километровое, я буду сидеть, писать код».
Ваня: Тут всё очень сильно зависит от человека и от команды. По большому счёту, если человек хочет развиваться и расти, ему всё равно в какой-то момент придётся это делать. До какого-то момента времени за него будет общаться менеджер, если он у него есть, но если он в итоге хочет развиваться, ему придётся это делать. Чем ведущий разработчик отличается от старшего? Тем, что у него есть очень хорошая экспертиза и тем, что он умеет решать такие уже полуменеджерские задачи. Он умеет нести полную ответственность за тот продукт, который он делает от составления требований до непосредственно разработки, вот в этом отличие, мне кажется.
Аня: Да, здесь идёт понимание того, для чего ты что-либо делаешь, а не просто так сделать — клёво будет.
Selenium. Нужен ли он еще?
— Давайте поговорим про Selenium, раз уж тут собрались специалисты этой тематики. Есть вопрос от телезрителя: «Почему кто-то до сих пор выбирает писать тесты на Selenium? Насколько вообще это оправданный выбор, учитывая что можно писать на разных уровнях тесты и, может быть, вообще никогда не добраться до тестов на Selenium?»
Аня: Сейчас часто говорят, что Selenium умирает. Какие-то другие инструменты приходят на его место. Мне кажется, что это не совсем так и всё равно всё зависит от экспертизы. В любом случае большинство проектов сейчас на Selenium делается и делалось на нём. Нужна будет поддержка, и если как специалист по тестированию хочешь куда-нибудь устроиться, то, скорее всего, это будет Selenium. Экспертизы в этой области, наверное, гораздо больше, плюс когда выходят какие-то новые технологии на рынок, она может бомбануть и потом скатиться куда-нибудь. Selenium покрывает, я бы сказала, все возможности юайного тестирования. И это такая как бы мощная штука, которая в ближайшее время точно не умрёт.
Если как специалист по тестированию хочешь куда-нибудь устроиться, то, скорее всего, это будет Selenium.
Ваня: Я ещё хочу дополнить. С технологиями всегда есть определённая инерция. Selenium, как известно, существует с 2004 года, ему уже 15 лет. Он, конечно, тоже меняется сам по себе, тем не менее за это время накопилось довольно большое количество уже готовых проектов. Для программирования 15 лет назад — это каменный век по сравнению с тем, что есть сейчас. И накоплено больше опыта именно в Selenium. Просто начать даже съезжать на какую-то новую технологию, если ты уже опытный автоматизатор, это сложно, это реально инерция.
Поскольку продукт существует долго, по нему накоплена большая база знаний, подводные камни, даже если — это проблема не только Selenium, это вообще проблема любой новой технологии, — чтобы она полетела, нужно набрать какую-то критическую массу из знаний, пользователей и так далее.
У Selenium есть критическая масса пользователей, есть форумы, сообщества, Stack Overflow, куча документации, куча конференций и специалистов, которые могут эти знания передавать постоянно. Как только возникает новая технология, она может полететь сейчас только в том случае, если в неё будет вбухана куча денег — и всё упирается в деньги.
Есть пример не про тестирование, а про разработку. Есть язык программирования Kotlin. Он сейчас, как выяснилось, полетел в мобильном направлении, прям летит-летит. Говорят, ходят какие-то слухи о том, что просто в его продвижение вложено довольно приличное количество денег, чтобы он в конференциях везде упомянался, чтобы люди разрабатывали фреймворки. Так много с чем происходит. Чтобы преодолеть инерцию, нужно затратить какое-то количество ресурсов. Просто сделав хороший продукт, даже если он реально лучше Selenium, сложно его продвинуть.
Почему Selenium? Потому что это теперь стандарт. Есть конкретный World Wide Web Консорциум, который взял и зафиксировал стандарт Selenium. Всегда лучше работать с инструментами, которые стандартизованы. Выбирая между двумя инструментами, можно сказать: «Здесь у нас всё зафиксировано, API стабильное, всё хорошо, а вот есть какое-то непонятное поделие сбоку, которое тоже делает какая-то компания, непонятно сколько она просуществует». При выборе между этими двумя инструментами, как правило, разумный менеджер обычно делает выбор в пользу чего-то более стандартного. Мне кажется, что писать тесты на Selenium имеет смысл, потому что даже какому-то начинающему специалисту сейчас проще это сделать. Порог входа будет ниже — больше тех, у кого можно спросить про Selenium.
Вторая причина, почему нужно продолжать писать тесты на Selenium, почему вообще нужно писать тесты на UI. Фактически написание тестов на UI, таких вот end-to-end — это единственный способ проверить, что приложение работает ровно так же, как это увидит пользователь. Даже если мы пишем всякие юниты и всё остальное, покрываем разными типами тестирования, это не даёт стопроцентной гарантии. Только проиграв те же самые действия, которые будет делать пользователь приложения, мы можем быть на сто процентов уверены, что у нас приложение работает. Понятно, что не нужно все сто процентов кода таким образом проходить. Обычно покрываются самые критически важные сценарии в приложении, но тем не менее это важно.
Всегда лучше работать с инструментами, которые стандартизованы.
Аня: По поводу новых инструментов хотела ещё добавить. Когда-то слышала умного дядьку на конференции. Он рассказывал про старт новых технологий и как понять, какая технология умрёт, какая задержится. У любой технологии, которая на рынок выходит, она начинает набирать то, что Ваня как раз говорит, критическую массу. Потом у неё происходит бум, и вот этот бум нужно как бы переждать, потому что после этого бума либо эта технология остаётся, его выдерживает, дальше у неё будет своё развитие и скачок, либо она после этого умрёт. Это тоже зависит от инвестиций, от того, успевает ли команда разработки справиться с тем потоком пользователей, которые на них приходят, потоком багов, либо направлений для дальнейшего развития, либо нет. Вот так сразу хвататься за что-нибудь, что находится на хайпе и переводить свои тесты на эту технологию, это, мне кажется, будет неоправданно.
— Как вам кажется, много ли изменилось в Selenium? Изменилось ли вообще что-то за последние два года драматически в этом инструменте и эволюционирует ли он как-то?
Ваня: Мне кажется, он довольно сильно меняется. Года два или три назад было ощущение, что в нём какой-то застой был, потому что по сути дела Selenium придумали в 2004 году, потом он развивался-развивался-развивался, потом в 2008-2009 году придумали Selenium WebDriver, придумали Selenium Grid. После этого лет пять они просто допиливали его, выкатывали какие-то небольшие фичи, в общем сильно ничего не менялось. У всех стоял Selenium Grid, у всех была стандартная библиотека Selenium.
А вот последние года 2-3 пошёл бум всяких новых продуктов, основанных на Selenium. Мы, например, сделали Selenoid. Ребята, которые работали в тот момент в компании Zalando, на основе Selenium Grid сделали такой инструмент как Zalenium, тоже Selenium-совместимое решение. По сути оба инструмента были сделаны для того, чтобы решить какие-то конкретные проблемы, для которых не было решения в оригинальном коде. Потом появились ещё другие, конкуренты самого Selenium. Сейчас, мне кажется, последние года два или три пошла какая-то такая движуха-движуха.
Мне кажется, что Selenium развивается, плюс ещё в начале 2018 года зафиксировали стандарт. Поэтому Selenium, конечно, с одной стороны, как инструмент довольно сильно заматерел. С другой стороны команде, которая развивала первоначально основной код, удалось навязать ответственность за поддержание совместимости со стандартом другим командам разработчиков браузеров. Если раньше фактически весь Selenium был какой-то единый, в котором всё лежало, все драйверы, то теперь им удалось договориться со всеми командами. Apple для Safari делает поддержку, потому что есть стандарт и не нужно ни с кем согласовывать. Google делает для Chrome поддержку, Mozilla делает для Firefox. Фактически теперь это уже распределённая экосистема, там есть несколько разных точек. Сейчас Microsoft тоже делает для своих браузеров своё, для Edge он делал свой драйвер, и им удалось ответственность распределить. За счёт этого, мне кажется, произошёл довольно приличный скачок в качестве.
— Да, три года назад, я помню, чтобы тесты на Selenium на Safari бежали, нужно было себя так выкрутить. В общем больно было.
Ваня: А теперь всё по стандарту сделано более-менее. Там, конечно, есть какие-то свои особенности, но по сути всё стало единообразно, то есть произошла такая унификация того, как это всё работает внутри. Мне кажется, это круто, там много усилий было вложено в это всё. Поэтому я не считаю, что сейчас в Selenium есть какой-то застой. Сейчас там есть здоровая конкуренция разных решений.
Мы в каком-то смысле конкурируем с ребятами, которые делают основной код Selenium. Приезжаем на конференции, говорим, что ребята, ваше не эффективное потому, потому и потому. Чтобы как-то доказать, что всё-таки они тоже молодцы, им приходится делать своё. Происходит здоровая конкуренция.
Аня: По поводу Selenium IDE ещё хочется добавить, про которую вообще, мне кажется, все давно забыли. С появлением новых инструментов по script-less автоматизации они опять взялись за Selenium IDE. В течение 2019 года очень сильно её развивали и планируется масштабный релиз в начале 2020 года, где они что-то представят. Очень сильно поменялся интерфейс у IDE и она стала более стабильной и удобной, скажем так.
Ваня: Хотел ещё добавить, что сейчас к Selenium стали пытаться прикладывать разные технологии, которые до этого не применялись, например, то же самое машинное обучение.
Это одно из направлений, которое до сих пор не существовало в Selenium. Люди, попользовавшись Selenium лет 10, обнаружили какое-то количество задач, которые, как выяснилось, могут быть частично или полностью решены при помощи машинного обучения. Всякие рутинные операции.
— Аня, расскажи, что за проблемы вы решаете машинным обучением? Всё за нас будут писать? У нас сейчас искусственный интеллект начинает проникать вообще везде. Если вбить в Google «AI и Selenium» — там начинают люди разрабатывать свои какие-то библиотеки, выкладывать, ещё что-то, то есть развитие идёт.
Аня: Относительно Selenium могу сказать, что в последнее время гораздо удобнее на основе него делать всякие решения, ну в частности это за счёт его стандартизации. По поводу возможностей, самое главное нужно — это взаимодействовать с элементами на странице. И соответственно эта часть уже ложится, на тестировщиков, как это взаимодействие описать, используя Selenium. Если это описывать чисто используя Selenium, то могут быть нестабильные тесты, потому что какие-то там изменения произойдут на UI, какого-то элемента не дождутся и так далее. Машинное обучение начинают именно к этому месту прикладывать, чтобы можно было эти тесты стабилизировать. Чтобы эти тесты можно было сгенерить на основе информации, которая имеется у нас на странице, и на основе поведения пользователя.
В тренде было Record and Play, то, что делает как раз Selenium IDE: мы заходим на страницу, накликиваем действие, у нас создаются тесты. Эти тесты должны быть стабильные. Машинное обучение нужно там именно для этого. Обычно локаторы захардкожены, поэтому при изменениях на UI их необходимо обновить. Healenium, который мы сейчас делаем, например, позволяет в рантайме их обновить, и наш тест, соответственно, пройдёт.
Сейчас появляется такая тенденция не чисто к Record and Play тестам, а к возможности генерации тестов. Мы знаем, какие у нас есть элементы на странице. Мы можем нарисовать некую логическую схему нашего сайта. Мы знаем, что у нас есть главная страничка, от неё страничка логина и ещё чего-то. Основываясь на этих логических связях и действиях, которые мы можем делать на этой странице, мы можем сгенерировать тесты. Но таких инструментов на рынке, которые прям очень хорошо это сделали, я пока не знаю. Healenium мы хотим развивать как раз в этом направлении.
С развитием этих подходов и знаний в области machine learning в ближайшее время будет уклон в развитие и появление таких инструментов. Например, краулеров сайтов, которые могут автоматически провести тестирование вместо написания тест-кейсов.
— Вот Ваня сказал, что Selenium IDE обновляют. В общем, не то они делают. Скоро машинное обучение всё за них решит и это IDE даже не нужно будет.
А если машинное обучение будет действительно таким крутым, то какая часть останется живым людям, тестировщикам?
Предлагаю обсудить этот вопрос в комментариях. А в продолжении этого интервью мы узнаем ответы Анны и Ивана. Кстати, на конференции Heisenbug 2020 Piter, которая пройдет в онлайне, можно будет пообщаться с ними и подробнее узнать про Healenium, Selenoid и использование Chrome DevTools протокола в Kubernetes кластере.
Недавно вышла вторая часть интервью с ответом на вопрос про ML в тестировании: узнали, кто такой человек-маркировщик, и разобрались, нужно ли изучать Selenium в 2020 году.
Для тех, кто хочет расширить кругозор и посетить не одну конференцию, а сразу 8 — мы кое-что подготовили.
