Коротко о событии
Конференция: Heisenbug 2017 Moscow
Дата: 8-9 декабря 2017 года
Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте.
Какой самый частый вопрос в комментариях на Хабре? «Будет ли запись?» Сразу возьмём быка за рога: запись будет, как всегда, через 3-4 месяца. Но из тех, кто задавал вопрос, смотреть её будет едва ли половина.
Чтобы понять, почему так происходит, нужно разобраться — как мы смотрим видео с конференций, зачем это вообще нужно?
Как вы уже, наверное, знаете, 8-9 декабря в Москве пройдёт очередной Heisenbug, поэтому мы решили познакомить Хабр с программой предстоящего события.
Но не так быстро! В качестве вступления — небольшая история из жизни. В конце вступления будет один мозговзрывающий факт насчёт этого хабрапоста. Сразу за ним — подробное изложение программы.
Почему тебе, дорогой хаброжитель, вообще стоит слушать какого-то маркетолога, который пишет эту статью? Что он может понимать в нашем нелёгком труде? За этой инфой пришлось лезть в самые тёмные глубины LinkedIn: когда-то давно, в 2010 году я устроился в одну небольшую уютную компанию в Новосибирском Академгородке на первую свою работу Java-программистом. Чтобы немножко изучить продукт, руководство поручило ответственную миссию: вручную бегать по интерфейсу нашего веб-приложения, прокликивать кнопочки и выдергивать оттуда ошибки. Довольно скоро мне поручили придумывать тест-планы, а потом и вовсе дали невероятно ответственную задачу: написать совершенно новый фреймворк для автоматического тестирования.
Как вы уже, наверное, знаете, 8-9 декабря в Москве пройдёт очередной Heisenbug, поэтому мы решили познакомить Хабр с программой предстоящего события.
Но не так быстро! В качестве вступления — небольшая история из жизни. В конце вступления будет один мозговзрывающий факт насчёт этого хабрапоста. Сразу за ним — подробное изложение программы.
Почему тебе, дорогой хаброжитель, вообще стоит слушать какого-то маркетолога, который пишет эту статью? Что он может понимать в нашем нелёгком труде? За этой инфой пришлось лезть в самые тёмные глубины LinkedIn: когда-то давно, в 2010 году я устроился в одну небольшую уютную компанию в Новосибирском Академгородке на первую свою работу Java-программистом. Чтобы немножко изучить продукт, руководство поручило ответственную миссию: вручную бегать по интерфейсу нашего веб-приложения, прокликивать кнопочки и выдергивать оттуда ошибки. Довольно скоро мне поручили придумывать тест-планы, а потом и вовсе дали невероятно ответственную задачу: написать совершенно новый фреймворк для автоматического тестирования.
Есть много хороших статей о том, как начать писать автоматизированные браузерные тесты, используя версию Selenium, предназначенную для Node.js.
В некоторых материалах говорится о том, как оборачивать тесты в Mocha или Jasmine, в некоторых всё автоматизируют с помощью npm, Grunt или Gulp. Во всех подобных публикациях можно найти сведения о том, как установить и настроить всё необходимое. Там же можно посмотреть простые примеры работающего кода. Всё это весьма полезно, так как, для новичка, собрать работающую среду тестирования, состоящую из множества компонентов, может оказаться не так уж и просто.
Однако, в том, что касается подводных камней Selenium, в том, что относится к разбору лучших практических приёмов разработки тестов, эти статьи обычно ожиданий не оправдывают.
Сегодня мы начнём с того, на чём обычно заканчиваются другие материалы по автоматизации браузерных тестов с помощью Selenium для Node.js. А именно, мы расскажем о том, как повысить надёжность тестов и «отвязать» их от непредсказуемых явлений, которыми полны браузеры и веб-приложения.
Читать полностью »
В этой статье я хочу показать, как с помощью фреймворка Selenium Webdriver можно, исходя из данных Wikipedia, составить генеалогическое древо заданной персоны (например, легендарного основателя первой династии русских правителей Рюрика).
В статье будет рассказано, как определить имя персоны, вычислить ссылки на страницы детей персоны, а также будет построен алгоритм генерации генеалогического древа.Читать полностью »
Привет!
Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.
Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.
Процесс разработки образовательной программы очень похож на процесс разработки нового продукта. И там, и там ты пытаешься вначале понять, а есть ли спрос на то, что ты собираешься производить? Существует ли в реальности та проблема, которую ты хочешь решить?
В этот раз для нас всё было довольно просто. Несколько выпускников нашей программы «Специалист по большим данным» в течение, наверное, года просили:
Сделайте для нас еще одну программу, где мы бы могли научиться работать с Kafka, Elasticsearch и разными инструментами экосистемы Hadoop, чтобы собирать пайплайны данных.
Потом со стороны работодателей стали «прилетать» запросы, которые собирательно можно описать так:
Data Engineer'ы – это очень горячие вакансии!
Реально их уже на протяжении полугода никак не можем закрыть.
Очень здорово, что вы обратили внимание именно на эту специальность. Сейчас на рынке очень большой перекос в сторону Data Scientist'ов, а больше половины работы по проектам – это именно инженерия.
С этого момента стало понятно, что спрос есть, и проблема существует. Надо бросаться в разработку программы!
Читать полностью »
Как вы уже могли заметить мы в команде Aerokube продолжаем упрощать жизнь в инфраструктуре тестирования. Сейчас мы усиленно работаем над удобными инструментами для, браузерного тестирования на основе Selenium. Одним из инструментов, о котором я уже рассказывал раньше, является Selenoid. Selenoid — это легковесный сервер, запускающий изолированные браузеры в Docker контейнерах. В предыдущих статьях (раз, два) я описал два возможных сценария использования Selenoid — работа с Docker и использование исполняемых файлов веб-драйверов в операционных системах, где отсутствует поддержка Docker. Сегодня я расскажу о новых возможностях, которые могут помочь в отладке браузерных тестов.
Привет! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.
Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.
В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.
Читать полностью »
Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?
И тут кто-то произносит слово «автотесты».
И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.
