Вступление
Как вы уже, наверное, знаете, 8-9 декабря в Москве пройдёт очередной Heisenbug, поэтому мы решили познакомить Хабр с программой предстоящего события.
Но не так быстро! В качестве вступления — небольшая история из жизни. В конце вступления будет один мозговзрывающий факт насчёт этого хабрапоста. Сразу за ним — подробное изложение программы.
Почему тебе, дорогой хаброжитель, вообще стоит слушать какого-то маркетолога, который пишет эту статью? Что он может понимать в нашем нелёгком труде? За этой инфой пришлось лезть в самые тёмные глубины LinkedIn: когда-то давно, в 2010 году я устроился в одну небольшую уютную компанию в Новосибирском Академгородке на первую свою работу Java-программистом. Чтобы немножко изучить продукт, руководство поручило ответственную миссию: вручную бегать по интерфейсу нашего веб-приложения, прокликивать кнопочки и выдергивать оттуда ошибки. Довольно скоро мне поручили придумывать тест-планы, а потом и вовсе дали невероятно ответственную задачу: написать совершенно новый фреймворк для автоматического тестирования.
Как жестоко они ошиблись в моих умственных способностях! Оказалось, что тестирование — это не хухры-мухры. Ближайшие несколько месяцев пришлось изойти на кровь и пот, пытаясь взять штурмом несколько направлений: одновременно написать на Java систему удаленного выполнения тестов (открывая параллельные коннекты по SSH — сначала с помощью костыля в виде вызова Python из Java и pyexpect для ввода пароля — нельзя было авторизовываться по ключам, не спрашивайте, почему). На серверах стоял не весь нужный софт, и админы не хотели ставить нужный, поэтому пришлось написать фреймворк для сборки из исходников небольшого дистрибутива GNU прямо в домашней директории текущего пользователя. Самое чудовищное — это тесты на перформанс, я их не понимал тогда, да и не понимаю сейчас (впрочем, должен ли быть маркетолог особо умным существом? :)
Потом надо было результаты тестов собирать и визуализировать, чтобы отдавать заказчику в PDF. Как сейчас помню, я выбрал для написания и последующей визуализации фреймворк Concordion — это такой BDD-фреймворк для Java. Почему не Cucumber? Его ещё не было. Зато в Concordion было всё так красиво и изящно — тесты внедрялись прямо посреди HTML. Тестов было много, много было своей специфики, приправленной OSGi-безумием со стороны бэкенда. Разработчики меня ненавидели.
Прошли годы, и у нас появилась куча новых инструментов. В 2012 году вышел Cucumber для Java и ещё куча всякого BDD, потом весь мир захватили Селениумы и Докеры, и их влияние со временем только росло. К сожалению, я к тому времени уже ушёл из тестирования и просто со стороны молча завидовал всем этим ништякам. Ещё бы, больше тебе не нужно самому скриптовать постоянно отваливающийся SSH, ведь можно невозбранно заюзать Ansible.
Аналогичным образом изменялись и конференции для тестировщиков: люди всё больше внедряли новые инструменты и могли уже сказать что-то вразумительное. Если в самом начале люди говорили просто о попытке внедрения чего-то нового, то со временем всё больше докладов начало концентрироваться на реальных способах использования, проблемах и решениях, деталях внутреннего устройства инструментов и так далее.
То есть сами конференции качественно изменились. Теперь они о внедрении и масштабировании. Каждое второе слово — про масштабирование. Это может показаться назойливым, но, мне кажется, это хорошо — раньше о масштабировании можно было только мечтать.
Параллельно с общей эволюцией развивались и конференции JUG.ru Group. Качество докладов, организации и видеотрансляций, дискуссионные зоны.
И вот тут хочется поговорить о программе, потому что как глаза — зеркало души, так и программа — отражение окружающей действительности. Там ниже я аккуратно выпишу все основные доклады, но во вступлении — остановимся на трендах.
Во-первых, нужно отметить укрепление направления мобильной разработки. Что общего у Тинькофф, Яндекс и Badoo? Они все пришли на Heisenbug 2017 Moscow. А ещё они все делают доклады про мобилки.
Во-вторых, вечные темы никуда не девались. Jenkins, flaky-тесты, Selenium — от них не скрыться. Я бы сказал, творится какое-то засилье Selenium, он в каждом третьем докладе или явно, или намёками присутствует. А ещё — Docker и масштабирование. При чём тут вообще Docker? Docker — всегда при чём!
- В-третьих, есть и довольно нестандартные темы. Вячеслав Аленьков расскажет про тестирование в Росатоме, точнее — про цифровой запуск АЭС (атомных электростанций). Как вам такой стандарт качества? Рома Поборчий с докладом про A/B тестирование даст возможность почувствовать себя немножечко data scientist'ами. А ещё у нас есть отличный доклад Александра Шукова из World of Tanks, внезапно, про World of Tanks. Уже интуитивно понятно, что в такой популярной игре всё должно быть на очень хорошем уровне, на их примере стоит поучиться. Эти люди рассказывают не о внедрении какой-то новой хипстерской технологии, а об успешном решении проблем в крупных проектах, и решения эти проверены временем и репутацией.
У меня закончились точки-буллеты в списке, поэтому ещё пара интересного в один абзац! На конференциях JUG.ru Group традиционно проводятся доклады со всевозможными паззлерами — вот и до нас они добрались. Доклад с паззлерами будет в самом начале, утром, и кто привык просыпаться не благодаря кофе, а с помощью интересных задачек — милости просим.
Конечно, доклады читают проверенные временем спикеры вроде Николая Алименкова и Артема Ерошенко. У Артема архитектурный доклад про тесты, таких докладов не так много бывает.
А ещё на этой конференции будут реальные звёзды, знаменитости: Саймон Стюарт (человек, являющийся живым воплощением Selenium на Земле) и Алан Пейдж (бывший директор по тестированию в Microsoft, действующий директор по качеству в Unity).
Ну и конечно, в конце будет знатное афтепати! С жидкостями для принятия внутрь, музыкой, тёплыми ламповыми беседами — всё как положено. Просто приходите, будет круто.
Интересный момент: раньше на нас жутко ругались, что мы сразу после закрытия конференции берём спикеров и куда-то уводим. И в результате, на вечеринке не оставалось почти ни одного спикера. На самом деле, в этом есть смысл: кому-то надо прийти в себя после напряженного доклада, у кого-то через час самолёт. Но и в твоем возмущении, дорогой читатель, есть большая доля смысла, и вообще — клиент всегда прав. Поэтому в этот раз мы постараемся, чтобы спикеры пришли на вечеринку и употребляли жидкости вместе с нами. Гарантий дать не могу, мы но постараемся.
Немного дичи об этом посте
Вообще, если человек однажды научился писать код (например, код тестов), от осознания этой своей силы он портится. Становится хитрым ленивым существом, желающим автоматизировать всё, что видит. Если есть тест — его надо автоматизировать! Если есть пост — его эээ… тоже надо автоматизировать!
В ходе написания этого поста мне пришлось перелопатить всю программу конференции — кое-где переформулировать описания докладов, перевести на русский язык английские тексты, превратить полученный объём данных в хабрапост и так далее. Для этого нужно получить данные о докладах в структурированном виде. Такие данные лежат у нас на сайте в разделе «программа», и я мог бы легко взять их из базы. Если бы позаботился об этом с вечера! Дело в том, что я писал этот пост глубокой ночью, когда грехи наиболее сильно скребут душу, и строчки ложатся на бумагу наиболее гладко. В этот час админы спят, и если бы я разбудил админа с просьбой дать дамп базы, разговор получился бы, прямо скажем, напряженным.
Поэтому я взял в руки вебдрайвер и написал простенький скрейпер таблиц с нашего сайта! Принцип его действия простой:
- стартует с помощью
SpringBoot(проект сгенерирован с помощьюSpring Initializr— очень важно быть ленивым), - он скачивает страничку (с помощью
jbrowserdriver), - потом все странички всех докладов по ссылкам,
- аккуратно парсит всё это (в джавовые объекты типа
Talk— объект «Доклад» с полями типа «спикер», «компания, в которой он работает», и т.п.), - и все фотографии спикеров сохраняет на жесткий диск,
- применяет патчи с переводами с русского на английский (простой мердж
ArrayList<Talk>в Java), - трансформирует это в Markdown (с помощью шаблонизатора
Velocity— да, я поклонник старины), - и на выход формирует текстовый markdown-файл для дальнейшей обработки.
Пара заметок. Вначале я пытался использовать Unirest + jSoup, но получился какой-то трэш. То ли у нас сильно умный JavaScript сидит на сайте, то ли в jSoup баги, но в четыре утра заниматься их поиском не хотелось. А вот JBrowserDriver оказался довольно стабильной штукой и нормально отдает DOM, полученный сразу после всех трансформаций, выполняемых браузером после загрузки страниц. Картинки сохраняются на жесткий диск, а не напрямую на HabraStorage, потому что Хабр не дает токен API, а хакать их API поперек их воли — некрасиво. Запуск тестировался относительно Java 9 с параметром --add-opens java.base/java.lang=ALL-UNNAMED и Java 8.
Результаты этой бессмысленной и беспощадной работы можно посмотреть у меня на GitHub.
Главный факап оказался в том, что я не подумавши начал писать это без тестов. В результате изначальная оценка проекта по написанию парсера + получению исходника статьи из 20 минут быстро превратилась в 2 часа.
Стыдно, очень стыдно. Это Олег, и он криворукий. Не будь как Олег, всегда пиши юнит-тесты! Особенно, когда разрабатываешь подобие компилятора (даже такого простого, как парсер веб-странички). С другой стороны, должен ли сотрудник отдела маркетинга быть умным существом? Короче, мне простительно. А вам — нет, так-то!
На этой жизнеутверждающей ноте переходим к самому главному — к программе!
Программа
День первый. 8 декабря.
Тестирование браузерной производительности веб-приложений (JavaScript, rendering, вот это всё)
Владимир Ситников/Netcracker
Часто под словом «тестирование производительности» подразумевают только тестирование серверной части. Гораздо реже тестируют непосредственно работу браузера. В простом случае подключаем Яндекс.Метрику и/или Google Analytics, и вперёд. Но есть нюанс: в корпоративной среде отправка данных в ЯМ/GA может быть недоступна, да и простого подключению ЯМ/GA недостаточно, чтобы собирать нужное количество информации о производительности приложения. В докладе мы рассмотрим то, как измерять длительность операций в браузере. Узнаем, почему времена, получаемые от Selenium, показывают погоду, узнаем, какая польза от Selenium-тестов может быть при замерах производительности. Посмотрим на boomerang.js и узнаем, на какие моменты обращать внимание при интеграции подобных библиотек в проект. Доклад не затрагивает вопросы оптимизации браузера/сервера.
Владимир Ситников
Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. В его обязанности входит планирование нагрузочных замеров, анализ и объяснение полученных результатов. Владимир является commiter’ом в Apache JMeter.
Selenide Puzzlers
Алексей Виноградов/Radio QA; Андрей Солнцев/Codeborne
Puzzlers — это доклад-викторина, в которой все зрители станут непосредственными участниками шоу. Ведущие придумали для вас с полдюжины интересных задачек, почти все из которых взяты из реальной проектной практики авторов. К каждой задачке вам продемонстрируют список вариантов и дадут убедительные аргументы в пользу каждого! Вам всего лишь нужно будет выбрать правильный. Звучит просто? А мы уверены — задачки будут сложнее, чем кажется на первый взгляд. Хотите пари? :) Тема данного Puzzler-а — фреймворк для UI-тестирования Selenide. Вопросы доступны для новичков с поверхностными знаниями фреймворка, но об некоторые из них сломают зубы даже профессионалы. Мы ожидаем, что посетители доклада уже имели дело с Selenide на работе или активно упражнялись дома, вы же не хотите просто угадывать? После каждого задания ведущие конечно же раскроют и объяснят правильный ответ, а также продемонстрируют практическое применение знаний, полученных от решения.
Алексей Виноградов
Работает в IT-проектах в Германии более 15 лет. Консультирует по вопросам тестирования и автоматизации. Младший разработчик фреймворка Selenide. Основатель и один из ведущих подкаста Radio QA.
Андрей Солнцев
Андрей — разработчик в эстонской компании Codeborne. Автор фреймворка Selenide, организатор таллиннского Devclub, частый докладчик на конференциях. Ярый приверженец экстремального программирования, автоматических тестов, парного программирования и чистого кода.
Enterprise Automation with Selenium and why it has very little to do with Selenium
Michael Palotas/Element34 Solutions GmbH
Поскольку Selenium становится стандартом W3C, всё больше и больше организаций начинают использовать его как основной инструмент автоматизации тестирования. Большинство команд фокусируется на написании тестов и борьбе с проблемами с помощью самого Selenium. Тем не менее, по нашему опыту, Selenium — это наименьшая проблема при создании с нуля решения для тестирования, пригодного для использования в enterprise-проектах. В этом докладе будет рассматриваться множество реальных практических примеров того, как автоматизация тестирования с помощью Selenium в конце концов превращается в разработку проекта по созданию большого программного продукта. Нужно с самого начала понимать, что это именно вот такой программный проект, и вести его соответственно. Доклад покажет основные проблемы, не позволяющие командам строить расширяемые и надежные решения на основе инструментов Selenium. Также мы увидим, как можно успешно применять принципы lean в создании подобного решения на основе Selenium.
Michael Palotas
Основатель и CEO компании Element34 Solutions. Один из разработчиков Selenium Grid. Бывший директор Quality Engineering в eBay. Более 10 лет Майкл формировал подход к тестированию в компании eBay International, находясь в должности главы Quality Engineering. Он был руководителем, ответственным за трансформацию eBay International из бездны ватерфолла в очень гибкую организацию, использующую новые пути и подходы, особенно в области инженерных практик. До того, как присоединиться к eBay, Майкл занимал ведущие должности в таких компаниях, как Ericsson, Nortel Networks и Intel.
Разработка и тестирование с Google
Всеволод Брекелов/Grid Dynamics
Доклад для тестировщиков и разработчиков, которым интересно узнать: какие грабли могут возникнуть при работе с Google Cloud Standard Environment, как их избежать (протестировать), какие Google-инструменты можно взять и использовать в своих проектах. Также вы узнаете чуть больше о GAE, Memcache, Task Queues, Objectify, Protobuf, Bazel.
Всеволод Брекелов
Более 5 лет в тестировании программного обеспечения/автоматизации тестирования. Последний год работает Full Stack Developer/Tech Lead. Опыт построения автоматизации тестирования с нуля для mobile, desktop, веб-проектов (в основном для финансовых компаний). Любит участвовать в хакатонах и работать с умными коллегами. Провёл много собеседований (более 200, и уже перестал считать) для инженеров по автоматизации тестирования, разработчиков, аналитиков. Последние несколько лет работает в компании Grid Dynamics. Сейчас проживает в Калифорнии, работая по контракту в Google.
Автоматизация мобильного тестирования родными средствами
Екатерина Батеева/Тинькофф Банк
Популярность и удобство мобильных приложений растёт, и вот уже во многих областях пользователи гораздо чаще используют мобильные девайсы, чем персональные компьютеры. Поэтому автоматизированное тестирование не стоит на месте, и уже существует множество решений, которые подходят для большинства задач. Для тестирования мобильного банка Тинькофф мы искали надежное, конфигурируемое средство, которое также позволит эффективно решать наши задачи. Попробовав решение SeeTest Automation от компании Experitest, мы решили обратиться к средствам автоматизации, которые предоставляют сами разработчики Android и iOS — это UIAutomator, Espresso и XCUITest. В этом докладе мы хотим рассказать про наш опыт применения этих фреймворков, какие мы нашли плюсы и минусы, с какими сложностями мы столкнулись и как их решали. Доклад будет интересен как новичкам в автоматизации мобильного тестирования, так и уже опытным специалистам. Он позволит им расширить свой кругозор, оценить возможность использования того или иного фреймворка в своём проекте или же сделать выбор в пользу других решений.
Екатерина Батеева
Старший инженер по автоматизированному тестированию в Тинькофф Банк. Работает в тестировании с 2012 года, занималась автоматизацией мессенджеров, веб-сервисов, банковских систем. Имеет значительный опыт в функциональном и интеграционном тестировании. Последние несколько лет занимается тестированием мобильных приложений.
Доклад от Сергея Егорова
Сергей является активным участником open source-сообщества, членом Apache Software Foundation и контрибьютором в разного рода проектах (Apache Groovy, TestContainers, Spring Boot, JBoss Modules, Zipkin и не только). Он также является одним из основателей русскоязычного DevOps-подкаста «Two Devs One Ops», где делится своим опытом в вопросах DevOps, облачных решений и современных инфраструктурных решений вроде Docker (пользователь с 2014 года). Сергей сделает доклад на Heisenbug 2017 Moscow, однако тема еще допиливается.
Белый ящик Пандоры
Никита Макаров/Одноклассники
В отрасли тестирования очень много говорится про «черный ящик», но изредка и вскользь упоминается «белый». Связано это в том числе и с тем, что тестирование «белого ящика» всегда считалась прерогативой программистов. В своем докладе ответим на эти и другие вопросы с примерами и наглядной демонстрацией.
Никита Макаров
Работал в аутсорсинге и продуктовых компаниях. Занимался автоматизацией встраиваемых операционных систем на базе Linux, комплексных VPN-решений для бизнеса, программно-аппаратных комплексов. С января 2012 года является руководителем группы автоматизации тестирования в проекте Одноклассники.
Измеряем энергопотребление
Алексей Лавренюк/Яндекс; Тимур Торубаров/Яндекс
Раньше мы умели тестировать только производительность серверных приложений, теперь осваиваем мобильные приложения – это новый тренд. В том числе, мы тестируем энергопотребление телефонов. Мы расскажем, как научились собирать метрику энергопотребления хардверным способом. Мы собрали небольшую схему на базе Arduino, которая измеряет ток, и написали библиотеку для работы с ней. Библиотеку мы выложили в open source (github.com/yandex-load/volta). Расскажем, как подготовить телефоны, собрать коробочки для замеров и как использовать библиотеку.
Алексей Лавренюк
Разработчик в Яндексе в службе нагрузочного тестирования. Делает инструменты и сервисы для тестирования производительности. Участвует в разработке таких open source-инструментов для нагрузочного тестирования, как Yandex.Tank (github.com/yandex/yandex-tank) и Pandora (github.com/yandex/pandora), а также сервиса для нагрузочного тестирования – Overload (overload.yandex.net).
Тимур Торубаров
Занимается производительностью в IT 8 лет. 4 года в телекоме (МТС и сопутствующие web/wap/sms-сервисы), 4 года в Яндексе. Краткая история жизни: «… и неожиданно для нас выдал гораздо больше нагрузки, чем мы хотели...».
Как проверить систему, не запустив ее
Андрей Сатарин/Яндекс
Системы, которые мы разрабатываем, становятся сложнее с каждым днем. И кажется, нет спасения от вездесущей сложности, которая проникает во всe. Один из аспектов этой сложности — конфигурация. С одной стороны, конфигурация сильно влияет на стабильность и доступность системы, с другой — проверке её корректности уделяется очень мало внимания. В докладе расскажем, как мы тестируем конфигурацию и насколько это было полезно в нашем проекте. Этот доклад будет полезен всем, кто хочет узнать простой способ увеличения стабильности и доступности системы в продакшне.
Андрей Сатарин
Занимается тестированием распределенных систем в Яндексе. В своей карьере успел поработать в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, систему расчета валютных цен в Deutsche Bank. Интересуется тестированием backend и распределенных систем.
Как выполнять много UI-тестов параллельно, используя Selenium Grid?
Михаил Подцерковский/Avito
Как выполнять много UI-тестов параллельно, используя Selenium Grid? Никак, Selenium Grid не способен выполнять большое количество тестов параллельно. Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте. Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем медленнее выполняется каждый тест. Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет — вы не можете запустить несколько реплик и поставить перед ними балансировщик. Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет — это не про Selenium Grid. Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится. Хотите знать, как решить все эти проблемы? Тогда приглашаем вас послушать доклад.
Михаил Подцерковский
Михаил работает в Avito, где занимается разработкой инструментов для тестирования.
Automate the impossible: blending the best of Android drivers
Rajdeep Varma/Badoo
Сейчас мы находимся на пороге удивительных изменений — всё больше мобильных разработчиков присматриваются к инструментам для автоматического тестирования с открытым исходным кодом. Это может быть Appium или Calabash, или что-то еще: все они хороши, но также верно, что у всех есть важные ограничения. Как нам выжать максимум из каждого инструмента? Как определить их лучшие стороны? Несмотря на то, что выбранный инструмент может работать весьма хорошо в самом начале, когда вы только-только начали его использовать, всё может резко поменяться при изменении ваших бизнес-требований. К счастью, мир open source достаточно щедр, чтобы дать вам возможность пойти и самостоятельно преодолеть возникшие ограничения. Этот доклад о том, как спикер справился с подобной проблемой. Несмотря на то, что он работал над Calabash-Android в течение нескольких лет, новые бизнес-требования заставили добавить в драйвер дополнительные возможности. Это доклад о конкретной проблеме, как она была решена, и какие у нас вообще есть возможности при решении подобных задач.
Rajdeep Varma
Сейчас работает Senior Test Automation engineer в Badoo. Есть настоящая страсть к автоматизации тестирования, как говорится — автоматизирует все, что движется. Занимался автоматизацией множества мобильных приложений во многих предметных областях в течение более чем семи лет. Rajdeep написал несколько утилит с открытым исходным кодом, включая "parallel_calabash" и "nakal" — они оформлены в виде RubyGems и предназначены для тестирования мобильных приложений.
Инструменты тестировщика
Юлия Атлыгина/ALM Works
Цель доклада: показать инструменты, которые можно будет использовать в тот же день, которые ускорят работу ручных тестировщиков, а также аналитиков-разработчиков и прочих. Многие думают, что ускорить ручные тесты можно только автоматизацией — но это не совсем так :) В данном докладе хотелось бы показать простые инструменты, которые бы позволили тратить меньше времени и при этом помогали бы увеличить тестовое покрытие. Целевая аудитория: ручные тестировщики, а также все, кому хоть иногда нужно что-то анализировать и делать руками.
Юлия Атлыгина
В тестировании более 9 лет, последние из которых провела в ALM Works, разрабатывая плагины для Atlassian JIRA и Confluence. Роль тестировщика совмещает с ролями Product Owner и SAFe консультанта. Если есть вопросы по JIRA — не стесняйтесь задавать!
The (Ab)use and misuse of test automation
Alan Page/Unity
Если вы — тестировщик, пишущий код, то скорее всего, ваша работа включает в себя автоматизацию тестирования — в особенности, написание тестов, которые автоматизируют рабочий процесс пользователя. Будучи ветераном автоматизированного тестирования (уже двадцать лет, и эта цифра продолжает расти!), Алан Пейдж видел множество команд, попытки которых хоть как-то заняться автоматизацией раз за разом оказывались абсолютно неуспешными. Тем не менее, он умудрился поучаствовать в тех немногих командах, у которых всё получилось, и на этом докладе поделится мудростью и паттернами, которые действительно работают (и кучей паттернов, которые никуда не годятся — тоже поделится). Алан покажет успешные стратегии автоматизации, как бороться с flaky-тестами, проведет сквозь опасности автоматизации UI и даст ряд других советов, основываясь на многолетнем опыте в автоматизации тестирования во множестве больших продуктов. Вы можете быть продвинутым тестировщиком, или напротив, только начинать карьеру — в этом докладе найдутся советы для всех, причем такие советы, которые можно применить на практике почти мгновенно.
Alan Page
Алан Пейдж проработал тестировщиком программного обеспечения примерно 25 лет. Он был основным автором книги «How We Test Software at Microsoft» и поучаствовал в создании «Beautiful Testing and Experiences of Test Automation: Case Studies of Software Test Automation». Кроме того, он пишет статьи на различные инженерные темы в своем блоге, его посты можно найти повсюду в интернете. Его последняя «книга» является коллекцией эссе на тему автоматического тестирования под общим именем «The A Word». Алан присоединился к Microsoft и стал частью команды Windows 95, и с тех пор работал над множеством релизов Windows, над ранними версиями Internet Explorer и Office Lync. В том числе, Алан два года проработал в Microsoft директором по тестированию. В январе 2017 года Алан ушел из Microsoft на должность директора по качеству в Unity.
Тестирование геолокации в Badoo: шишки, камни, костыли и селфи-палка
Александр Хозя/Badoo; Николай Козлов/Badoo
Работа с локациями достаточно нетривиальна, и в процессе всплывает очень много моментов, которые сложно предугадать заранее. Мы постараемся осветить проблемы и нюансы, с которыми мы столкнулись, дать советы, рассказать об используемых инструментах. Информации по этому вопросу до сих пор не так много — будем рады поделиться ей со всеми желающими.
Александр Хозя
В тестировании 7 лет, столько же занимается тестированием мобильных приложений :slightly_smiling_face: Ответственный за всё ручное мобильное тестирование в компании Badoo. Обожает всевозможные гаджеты (одна из причин, почему пошёл в мобильное тестирование), тестирование методом свободного поиска, детективную работу по нахождению комплексных проблем.
Николай Козлов
5+ лет опыта Android-гика.
Бытовая классификация тестировщиков с точки зрения разработчика
Николай Алименков/XP Injection
Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо, что-то тут не так? Хотелось бы поговорить о том, как тестировщиков видят сами разработчики. В докладе будет приведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои. Вы сможете лишний раз задуматься над тем, как вас видят со стороны и, возможно, изменить ситуацию к лучшему. Доклад будет также полезен менеджерам проектов и лидерам команд. Вы сможете быстрее распознавать те или иные шаблоны поведения тестировщиков и принимать меры по повышению уровня командной работы. Приходите, будет интересно!
Николай Алименков
Практикующий Java-техлид и Delivery Manager. Эксперт в разработке на Java, Agile-практиках и управлении проектами. Разрабатывает на Java более 12 лет, специализируется на разработке сложных распределённых масштабируемых систем. Активный участник и докладчик многих международных конференций. Основатель и тренер тренингового центра XP Injection. Организатор и идеолог конференций Selenium Camp, JEEConf, XP Days Ukraine и IT Brunch. Основатель «Клуба анонимных разработчиков».
День второй. 9 декабря.
Строим свой тестовый фреймворк, c Jenkins Pipeline и библиотеками
Олег Ненашев/CloudBees
Появление Pipeline изменило подходы к автоматизации задач в Jenkins, особенно в случае параллельных сборок и тестов. В нем можно построить свой тестовый фреймворк и предоставить его автоматизаторам как набор библиотек. На примере Java-проектов покажем, как можно строить Pipeline-библиотеки для задач QA и переносить проекты на новую платформу. Мы интегрируем Docker, Maven, JUnit, FindBugs, Сoverity, а потом реализуем динамическую параллелизацию тестов. Также поговорим о подводных камнях и о том, как можно эффективно разрабатывать, тестировать и поддерживать подобные фреймворки.
Олег Ненашев
Разработчик в CloudBees, состоит в core team проекта Jenkins. C 2008 года занимается автоматизацией, инфраструктурой и фреймворкостроением для крупных программно-аппаратных проектов с помощью Jenkins и десятков других тулов. Пишет код, поддерживает ядро и плагины Jenkins, организует митапы в СПб и других городах.
Как у вас в компании сломана статистика пользовательского поведения
Роман Поборчий/Независимый консультант по презентациям
Мы поговорим об области, смежной с тестированием. После того, как вы проверили, что функциональность реализована нормально, она выкатывается в эксперимент, чтобы узнать, нравится ли новая версия пользователям. Замечали, что обычно люди, ответственные за эксперименты, в итоге говорят, что данных недостаточно для решения? Часто это действительно так, но нередко всё дело в поломках системы экспериментов и учёта пользовательской статистики. Мы рассмотрим типичные поломки, которые там встречаются, и у вас появится возможность, вернувшись на рабочее место, немножко побыть data scientist'ами и найти ошибки у себя в компании. Какие-то из них там наверняка есть.
Роман Поборчий
До 2004 года работал в Sun Microsystems, принимал участие в разработке JDK. Затем работал в Intel, где тоже занимался проектами, связанными с Java. После этого шесть лет провёл в Яндексе, где строил метрики качества поиска. С 2015 года сменил род деятельности, ушёл на вольные хлеба и теперь готовит спикеров для технических конференций и ведёт тренинги по выступлениям.
Flaky tests
Андрей Солнцев/Codeborne
Flaky tests — головная боль автотестеров. Ещё вчера тест был зелёный, а сегодня он вдруг покраснел — ни с того ни с сего. Никто ничего не менял. Просто луна не в той фазе. Просто матрица шутит над тобой. Мы разберём кучу реальных примеров flaky-тестов из моей домашней коллекции. И разберёмся, как писать тесты, чтобы они были стабильными и независимыми от кармы разработчика. Доклад будет интересен и тестировщикам, и разработчикам — всем, кто балуется автотестами или просто любит разгадывать неразрешимые загадки.
Андрей Солнцев
Андрей — разработчик в эстонской компании Codeborne. Автор фреймворка Selenide, организатор таллиннского Devclub, частый докладчик на конференциях. Ярый приверженец экстремального программирования, автоматических тестов, парного программирования и чистого кода.
Использование staging и differential testing для регрессионного тестирования
Андрей Кулешов/Deutsche Bank
Повторное возникновение ошибок после внесения изменений в код — достаточно частое явление, которое тратит много сил, нервов и времени любого разработчика. Поэтому регрессионное тестирование — важнейшая часть контроля качества программного продукта. Но что делать тестировщику, если необходимо следить за высоконагруженной системой с большим объемом входных данных и разнообразным функционалом? Параллельное тестирование (Prod Parallel) — подход, при котором одновременно с релизной версией разворачивается система с новой версией, получающая на вход тот же массив данных, что и продукт, находящийся в релизе. Именно этот подход приходит на помощь в случае, когда приложение имеет большой функционал, а команда тестировщиков крайне мала. Он экономит ресурсы QA, позволяет следить за изменением продукта и берет на себя часть регрессионного тестирования. В докладе будет рассказано, как выстроить процесс тестирования с использованием параллельной версии продукта, каковы плюсы и минусы этого подхода. Автор поделится своим успешным опытом такого тестирования на примере одного из компонентов платформы для биржевой торговли. Доклад может быть интересен как мануальным тестировщикам, так и QA-автоматизаторам.
Андрей Кулешов
В настоящее время Андрей работает в Deutsche Bank, занимается разработкой высоконагруженного server-side-приложения для биржевой торговли. Андрей — выпускник ВМК МГУ им. Ломоносова. Ранее работал в компании Intel в отделе разработки компиляторов, участвовал в написании тестового фреймворка и тестировании Intel C/C++ и open source Clang-компиляторов. Интересуется разработкой, автоматизацией процессов тестирования, оптимизацией процесса разработки ПО.
Scaling Selenium
Simon Stewart/The Selenium Project
Представьте, что у вас всего один тест на Selenium. Что может сделать его нестабильным? Что может его ускорить? Теперь представьте два теста. Теперь — сотни. Как бы заставить их выполняться быстрее? Какие проблемы встретятся по пути увеличения размера пачки тестов? В этом докладе мы начнем путешествие вместо с Саймоном и набором тестов, начиная с самого первого теста, и дальше, вплоть до запуска сотен тестов параллельно. Мы изучим встречающиеся по дороге проблемы и получим практические рекомендации о том, как с ними бороться. Здесь будет много кода! Обсуждение железа тоже будет. Мы поговорим, как с умом подходить к инфраструктуре сборки и тестирования.
Simon Stewart
Саймон Стюарт — создатель WebDriver и глава проекта Selenium. В прошлом он был главой команды, занимающейся инструментами сборки в Facebook, разрабатывал графовую утилиту сборки Buck, и яро выступал за использование монорепозиториев. До того, как присоединиться к Facebook, он почти пять лет подряд провёл в Google и три года — в ThoughtWorks. Он видел реально много кода. Кроме того, Саймон серьезно интересуется воспроизводимыми байт-в-байт сборками.
Рецепт приготовления веб-тестов
Артем Ерошенко/Независимый консультант
Несколько лет назад мы рассказывали про то, как мы в Яндексе пишем веб-тесты. На тот момент мы использовали трехслойную архитектуру тесты <-> степы <-> пейджи. Много времени утекло с тех пор, мы немного изменили подход, сделали упор на скорость написания тестов и отсутствие контекста. В этом докладе расскажем, как эволюционировала наша модель написания веб-тестов на Java.
Артем Ерошенко
Более 8 лет занимается автоматизацией тестирования веб-приложений. За это время работал в разных командах и в разных ролях: автоматизатор тестирования, менеджер команды разработки инструментов тестирования, руководитель группы автоматизации тестирования. Артем имеет большой опыт работы с популярными инструментами (Selenium, HtmlElements, Allure, Jenkins). Программирует в основном на Java, Groovy.
Как сообщать пользователю, если «Упс, что-то пошло не так»
Антонина Хисаметдинова/Собака Павлова
При разработке любого ПО команды — как большие, так и маленькие — уделяют проработке сценариев с ошибками и сбоями слишком мало времени. Многие просто создают однотипные интерфейсные окна типа «Ошибка № 392904» или «Упс, что-то пошло не так», не задумываясь, что почувствует пользователь. А ведь он может разозлиться, расстроиться или, хуже того, потерять доверие к продукту. Доклад поможет взглянуть на ошибки программного обеспечения глазами обычных людей. Мы поговорим о том, как научить интерфейс грамотно сообщать об ошибках и сбоях, чтобы не бесить пользователей. Доклад ориентирован на всех членов команды разработки.
Антонина Хисаметдинова
Занимается проектированием пользовательских интерфейсов 5 лет. Области профессиональных интересов: проектирование взаимодействия человека и техники, исследования пользователей и аналитика данных, методики обучения, рисование интерфейсов головой.
Тестирование «капитальных» объектов
Вячеслав Аленьков/Росатом
Мы уже привыкли, что запуск тестов производится нажатием одной кнопки. Проверки проходят автоматически при каждом коммите, статистики собираются без участия тестировщика. А баги заводятся в полуавтоматическом режиме. В общем, мы привыкли применять технологии программной и системной инженерии к нашим программным проектам. А теперь представьте себе, что перед вами стоит задача протестировать работу атомной электростанции. Нужно не только протестировать её софт, но и провести испытания всех её составляющих. Разумеется, никто не сможет сначала построить станцию и потом перенести несущую стену из-за того, что система вентиляции не сможет быть смонтирована в текущей конфигурации. Поэтому процессы реального мира всё больше уходят в «цифру». Как вам понравится комментарий к коммиту «Перенос капитальной стены на 2 метра севернее»? При проектировании и тестировании АЭС применяется полностью цифровой подход: создаётся информационная модель, к ней применяется классическая V-модель управления жизненным циклом. Таким образом, АЭС превращается в тиражируемый и полностью цифровой объект. Тестирование и запуск современных АЭС происходит в цифровом виде, и только после этого строители приступают к монтажу, используя всё те же цифровые модели. В докладе вы узнаете о том, что представляет собой современная информационная система, как происходит разработка и тестирование «капитальных» объектов на примере АЭС.
Вячеслав Аленьков
Директор по Системной инженерии и ИТ в Атомстройэкспорт-НИАЭП.
Selenoid — сотни параллельных UI-тестов легко и быстро
Павел Сенин/EPAM Systems
Браузерные тесты являются одними из самых медленных и ненадежных способов тестирования приложений. В докладе на примере реального проекта будет продемонстрировано, как Selenoid может помочь в решении этой проблемы. Будет проведено сравнение Selenium Server и Selenoid.
Павел Сенин
Test Automation Engineer в компании EPAM Systems. Карьеру в ИТ начал более 10 лет назад сисадмином и постепенно перешёл в тестирование. Уверен, что если на проекте есть здравая стратегия тестирования и грамотное сочетание инструментов автоматизации, то автотесты обязательно принесут существенную ценность для бизнеса, т.к. будут предоставлять актуальную и достоверную информацию о текущем состоянии продукта.
Loading time testing and results visualisation of web games
Andrejs Kalnacs/Evolution Gaming
Время загрузки приложения — очень важная метрика, если хочется достичь максимально хорошего user experience, и не притащить каких-нибудь регрессий. Она особенно важна для игр с веб-интерфейсом, поскольку, когда пользователь загружает игру в первый раз, все её ассеты загружаются из интернета и начинают визуализироваться с помощью различных платформ (JS/HTML5, Flash) и устройств (Android и iOS, телефоны и планшеты). Этот доклад состоит из двух частей: в первой части мы рассмотрим не только все необходимые элементы для построения полностью автоматизированного пайплайна для тестирования времени загрузки игры с веб-интерфейсом, используя такие технологии, как Selenium WebDriver, Selenium Grid, Appium, Zaproxy, контроль трафика в Linux, Jenkins и Docker — но ещё и изучим наиболее важные метрики, какие данные мы можем собирать, и как именно их стоит хранить. Вторая часть доклада будет посвящена визуализации результатов тестирования, причем её можно будет применить не только для тестирования времени загрузки игр, но и для множества других задач, с использованием InfluxDB и Grafana.
Andrejs Kalnacs
Andrejs занимается автоматизацией тестирования и качеством программного обеспечения, и особенно хорошо разбирается в веб-разработке для мобильных приложений. Он имеет десятилетний опыт в индустрии тестирования, в различных областях — игры, мобильные телекоммуникации, биометрия, банкинг, ритейл. Сейчас работает на должности «Lead Software Developer in Test» в Evolution Gaming, выводя тестирование веб-приложений на новый уровень — реализуя не только решения для функционального тестирования, но и для нефункционального — такого, как тестирование перформанса или времени загрузки. Кроме того, он известен как человек, всегда готовый помочь коллегам — обучать их, мотивировать, вдохновлять и думать вне рамок и ограничений, учиться и применять более эффективные инструменты и технологии.
BDD в розовом цвете
Анна Чернышева/EPAM Systems
Наверняка многие сталкивались со сложностями внедрения автоматизации тестирования в процесс Continuous Delivery. Как быстро стартануть автоматизацию сразу в нескольких командах, обеспечить единство технических решений, не потерять в качестве, да ещё и техдолга не нахвататься? Что, если любой член команды сможет писать автотесты, которые к тому же будут генерировать документацию на UI? В докладе мы расскажем о том, как в Альфа-Лаборатории нам удалось разработать и внедрить BDD-библиотеку шагов для написания автотестов и какие технические решения позволяют нам за недельный спринт доносить до клиента новую протестированную фичу, полностью покрытую автотестами, да ещё и с готовой, актуальной документацией.
Анна Чернышева
Lead Software Test Automation Engineer в EPAM Systems. Является ярым сторонником BDD. Успела поработать со многими инструментами автоматизации, принять участие в разработке тестовых фреймворков для крупных e-commerce-проектов. Сейчас участвует в разработке BDD-библиотеки для автоматизации тестирования и занимается внедрением DevOps-практик в Альфа-Лаборатории.
Автотесты в World of Tanks: боты на страже качества
Александр Шуков/Wargaming.net
В данном докладе коснемся общих проблем и подходов автоматизации тестирования в GameDev на примере проекта World of Tanks. Расскажем, как, перепробовав всё (от кликеров до инъекций кода в клиент-сервер), мы пришли к «bot-net» – тестовому фреймворку для «World of Tanks» со сценариями тестов на Python, посмотрим на его устройство и применение. Доклад больше фокусируется на вопросах построения инфраструктуры и среды для тестов, чем на самих тестах для игр. Доклад будет интересен QA в GameDev, а также всем любознательным, кого интересует жизнь за пределами WebDriver, JUnit, PyTest и так далее.
Александр Шуков
С 2011 года работает в Wargaming.net на проекте World Of Tanks в должности QA-инженера, пройдя путь от «джуна на все руки» до лида автоматизации. Последние 2 года занимается функциональными автотестами и нагрузочным тестированием игрового сервера.
Завершающий кейноут: Truths about technical testing
Alan Page/Unity
Большинство из нас слышали от уважаемых людей (или читали в интернете) «техническом тестировании». Конечно, технические знания — критически важная вещь для успеха. Но, несмотря на то, что большинство докладов о техническом тестировании заключается в обсуждении проблем автоматизации тестирования, как правило, нашим техническим ноу-хау существуют куда более ценные применения. В этом завершающем кейноуте Алан Пейдж поделится своим подходом к техническому тестированию, причинами, почему в своей команде они уменьшают количество автоматизации и как именно тестировщики могут более эффективно распорядиться своим техническим бэкграундом, чтобы внести больший вклад в работу команды. Кроме всего прочего, Алан покажет примеры наиболее любимых и практичных инструментов тестирования и расскажет о пользе наработки мощного и разностороннего набора инструментов.
Alan Page
Алан Пейдж проработал тестировщиком программного обеспечения примерно 25 лет. Он был основным автором книги «How We Test Software at Microsoft» и поучаствовал в создании «Beautiful Testing and Experiences of Test Automation: Case Studies of Software Test Automation». Кроме того, он пишет статьи на различные инженерные темы в своем блоге, его посты можно найти повсюду в интернете. Его последняя «книга» является коллекцией эссе на тему автоматического тестирования под общим именем «The A Word». Алан присоединился к Microsoft и стал частью команды Windows 95, и с тех пор работал над множеством релизов Windows, над ранними версиями Internet Explorer и Office Lync. В том числе, Алан два года проработал в Microsoft директором по тестированию. В январе 2017 года Алан ушел из Microsoft на должность директора по качеству в Unity.
Заключение
Теперь доступна почти вся информация, позволяющая определиться «идти ли на конференцию». Надеюсь, программа получилась хорошей, и вы уже захотели к нам приехать — если так, то билеты есть на официальном сайте. А если ответ — «сходил бы, если бы находился в Москве», то и этот вопрос мы решили: можно приобрести билеты онлайн-трансляции. Ждём 8-9 декабря на конференции и у мониторов!
lxsmkv
olegchir это редкость когда в одной небольшой, но полезной утилите собрано несколько технологий, можно использовать как туториал. Я вот раньше не сталкивался со SpringBoot — возьму на заметку.
Круто было бы если бы Вы еще и тесты залили. Очень хочется посмотреть и думаю другим тоже интересно а кому-то и полезно будет. Все-таки тема поста как бы намекает.