Коротко о событии
Конференция: Heisenbug 2017 Moscow
Дата: 8-9 декабря 2017 года
Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте ^[1].

Какой самый частый вопрос в комментариях на Хабре? «Будет ли запись?» Сразу возьмём быка за рога: запись будет, как всегда, через 3-4 месяца. Но из тех, кто задавал вопрос, смотреть её будет едва ли половина.

Чтобы понять, почему так происходит, нужно разобраться — как мы смотрим видео с конференций, зачем это вообще нужно?

Видео — это не только шоу и повод что-то вместе обсудить. Можно рассматривать его еще и как один из лучших видов документации.

Будучи разработчиками, мы не так часто задумываемся, что существует несколько способов написания документации. На заре появления рунета об этом хорошо написал ^[2] Влад Балин ^[3].

Документация бывает разных типов, как минимум:

• «Договор» — когда несколько человек должны одинаково понять что-то важное;
•  «Справочник» — эталонная информация, с которой сверяются много и часто. Туда же входят всякие международные стандарты, словари и даже описания API типа POSIX; сюда же относятся JavaDoc и комментарии в коде;
• «Обучающий материал» — донесение новых знаний структурированным и понятным образом;

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

Но если доклад о Selenium читает создатель Selenium и заявляет, что в будущем проект будет развиваться определенным образом — это некий договор, зафиксированный на видеозаписи. Можно показать это друзьям и сказать: «Ха, глядите, у нас есть обещание от самого Simon Stewart ^[4], что это будет работать вот так». Счастливчики, пришедшие на конференцию вживую, могут это обещание еще и обсудить в специальной дискуссионной зоне.

Если же докладчик полно и всесторонне описывает какую-то часть системы, то в будущем это можно использовать как справочник. Можно будет обращаться к этому видео раз за разом, обдумывать, пересматривать, использовать данные из него при написании кода или при составлении собственной документации.

Очевидно, что у доклада и его видеоматериала есть некий жизненный цикл. Максимальную ценность доклад имеет на старте, когда человек может быстро и просто впитать всю эту информацию и тут же применить на практике. После того, как конференция закончилась, она потихоньку превращается из учебника в еще и справочник. Пока видео лежит в закрытом доступе — это справочник с особыми ноу-хау, доступными только посетителям конференции. После открытия через 3-4 месяца и выкладывания на YouTube оно становится публичной информацией, на которую можно кинуть ссылку друзьям, с указанием точного времени просмотра. Через полгода-год после выпуска оно начинает устаревать, но эстафетную палочку подхватывает следующая конференция. Устаревание касается в большей степени фреймворков и конкретных технологий, а вот фундаментальные доклады по computer science, построению процесса разработки и тестирования и так далее — ими можно продолжать пользоваться в течение нескольких лет точно. Получается такой глобальный круговорот докладов в природе.

Основная проблема донесения информации в виде лекций и написания документаций-учебников в том, что обычно в организации нет людей, которые могут провести такую лекцию. Или они есть, но заняты чем-то другим. Или они просто не так хороши, как докладчики с конференций — мало кто может рассказать про Selenium лучше, чем Simon Stewart ^[4] — живое воплощение Selenium на земле.

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

К сожалению, не все могут прилететь через полмира вживую. Не всех отпустят работодатели. В конце концов, кому-то могло не хватить бюджета.

Иногда гораздо полезней собраться перед большой плазмой в офисе и обсудить доклад с коллегами — в полный голос, не боясь кому-то помешать, используя всю мощь русского языка и русского мата.

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

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

Как подключиться к трансляции

Раньше мы выкладывали на Хабр ссылки на всевозможные плейлисты на YouTube и предупреждали: «Вот эта ссылка — на первый день, вот эта — на второй, вот эта — еще на что-нибудь». Вам нужно было сохранить ссылку на этот хабрапост и потом следить за его обновлениями.

Есть путь гораздо проще. Бесплатную трансляцию можно смотреть прямо с нашего сайта, вот по этой ссылке:

https://heisenbug-moscow.ru/online-free/ ^[5]

Эта ссылка — конечный источник истины. Именно там отображается самая свежая, актуальная программа. Там же есть и большая оранжевая ссылка «Пообщаться с участниками и задать вопрос спикеру» ^[6], которая ведет на Telegram, пользоваться ей могут участники не только платной, но и открытой трансляции.

Changelog

Развитие конференции очень похоже на развитие программной платформы. Наши языки и платформы постоянно конкурируют между собой: например, Java гонится за .NET по синтаксису основного языка, а .NET пытается догнать Java по кроссплатформенности. Как только появляется новая идея, реализации этой идеи начинают появляться во всех популярных технологиях.

Создание конференций очень похоже на развитие программной платформы. У JUG.ru Group есть своя платформа, список базовых фичей. Как только одна из конференций что-то улучшает, обновление получают и все остальные. За этот год, в том числе этой осенью, было множество конференций, и много всего улучшилось.

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

• Улучшенное качество звука. Микрофоны правильно стоят и лучше работают, продумана акустика зала, решены мелкие технические проблемы;
• Видео в 1440р — дополнительное пространство используется для одновременного отображения спикера и FullHD слайдов (или экрана ноутбука для live coding) в на одном экране. Очень полезная технологичная фича;
• Инфраструктура для работы с видео переехала в облако, что понизило вероятность отказов оборудования. Этим занимаются в SBTG.ru ^[7], которые помогают в записи конференции, а мы только пожинаем плоды их работы;
• Наша сервисная инфраструктура тоже переехала на Amazon. Раньше был просто Hetzner, но качественная бесперебойная трансляция важнее;
• В перерывах между докладами, когда спикеры и участники на площадке удаляются в дискуссионные зоны, зрителям онлайн-трансляции мы показываем репортажи и интервью со спикерами и спонсорами. На этот раз интервью должны быть живее, вести их будут два ведущих (@phillennium ^[8] и @olegchir ^[9]— наши посты вы можете регулярно видеть на Хабре);
• Решено много мелких технических проблем, которые большинство даже не заметило, но они там были. В целом, ощущение от просмотра трансляции должно быть лучше.

Ограничения

• В открытой трансляции доступен только первый зал, включая кейноуты. Вы не сможете смотреть, что происходит в других залах. А там будет много интересного. В следующий раз регистрируйтесь и смотрите все без ограничений.
• Видеозаписей не будет. То есть они, конечно, будут, но только для участников конференции, оставивших фидбэк. А для всех остальных мы традиционно выложим их через 3-4 месяца.
• Открытая трансляция предоставляется по принципу as is: мы уверены, что все будет хорошо, но если вдруг что – не обессудьте! Участникам платной закрытой трансляции оказывается специальная поддержка — они покупают именно сервис.

Программа

Конференция проводится в течение двух дней. Первый день начинается в 10.00, второй — в 10.30. Каждый день оканчивается завершающим кейноутом (в 17.35 и 18.15 соответственно). Актуальную программу первого зала можно увидеть на странице трансляции ^[5].

День первый. 8 декабря.

Белый ящик Пандоры ^[10]

Никита Макаров/Одноклассники

В отрасли тестирования очень много говорится про «черный ящик», но изредка и вскользь упоминается «белый». Связано это в том числе и с тем, что тестирование «белого ящика» всегда считалась прерогативой программистов.

• Как не давать программистам писать неправильный код?
• Как внедрять падения в код так, чтобы не было мучительно больно?
• Зачем вам может понадобиться парсинг исходного кода и что вы можете с этого получить?
• Социальный анализ кода и покрытие — почему и зачем?

В этом докладе мы увидим ответы на эти и другие вопросы, с примерами и наглядной демонстрацией.

Никита Макаров

Работал в аутсорсинге и продуктовых компаниях. Занимался автоматизацией встраиваемых операционных систем на базе Linux, комплексных VPN-решений для бизнеса, программно-аппаратных комплексов. С января 2012 года является руководителем группы автоматизации тестирования в проекте Одноклассники.

---

Инструменты тестировщика ^[11]

Юлия Атлыгина/ALM Works

Цель доклада: показать инструменты, которые можно будет использовать в тот же день, которые ускорят работу ручных тестировщиков, а также аналитиков-разработчиков и прочих. Многие думают, что ускорить ручные тесты можно только автоматизацией — но это не совсем так :)

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

Юлия Атлыгина

В тестировании более 9 лет, последние из которых провела в ALM Works, разрабатывая плагины для Atlassian JIRA и Confluence. Роль тестировщика совмещает с ролями Product Owner и SAFe консультанта. Если есть вопросы по JIRA — не стесняйтесь задавать!

---

Тестирование производительности веб-приложений на стороне браузера (JavaScript, rendering, вот это всё) ^[12]

Владимир Ситников/Netcracker

Часто под словом «тестирование производительности» подразумевают только тестирование серверной части. Гораздо реже тестируют непосредственно работу браузера. В простом случае подключаем Яндекс.Метрику и/или Google Analytics, и вперёд. Но есть нюанс: в корпоративной среде отправка данных в ЯМ/GA может быть недоступна, да и простого подключению ЯМ/GA недостаточно, чтобы собирать нужное количество информации о производительности приложения.

В докладе мы рассмотрим то, как измерять длительность операций в браузере. Узнаем, почему времена, получаемые от Selenium, показывают погоду, узнаем, какая польза от Selenium-тестов может быть при замерах производительности. Посмотрим на boomerang.js и узнаем, на какие моменты обращать внимание при интеграции подобных библиотек в проект. Доклад не затрагивает вопросы оптимизации браузера/сервера.

Владимир Ситников

Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. В его обязанности входит планирование нагрузочных замеров, анализ и объяснение полученных результатов. Владимир является commiter’ом в Apache JMeter.

---

Как проверить систему, не запуская её ^[13]

Андрей Сатарин/Яндекс

Системы, которые мы разрабатываем, становятся сложнее с каждым днем. И кажется, нет спасения от вездесущей сложности, которая проникает во всe. Один из аспектов этой сложности — конфигурация. С одной стороны, конфигурация сильно влияет на стабильность и доступность системы, с другой — проверке её корректности уделяется очень мало внимания.

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

Андрей Сатарин

Занимается тестированием распределенных систем в Яндексе. В своей карьере успел поработать в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, систему расчета валютных цен в Deutsche Bank. Интересуется тестированием backend и распределенных систем.

---

The (Ab)use and misuse of test automation ^[14]

Alan Page/Unity

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

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

Alan Page

Алан Пейдж проработал тестировщиком программного обеспечения примерно 25 лет. Он был основным автором книги «How We Test Software at Microsoft» ^[15] и поучаствовал в создании «Beautiful Testing and Experiences of Test Automation: Case Studies of Software Test Automation» ^[16]. Кроме того, он пишет статьи на различные инженерные темы в своем блоге, его посты можно найти повсюду в интернете. Его последняя «книга» является коллекцией эссе на тему автоматического тестирования под общим именем «The A Word». Алан присоединился к Microsoft и стал частью команды Windows 95, и с тех пор работал над множеством релизов Windows, над ранними версиями Internet Explorer и Office Lync. В том числе, Алан два года проработал в Microsoft директором по тестированию. В январе 2017 года Алан ушел из Microsoft на должность директора по качеству в Unity.

---

Бытовая классификация тестировщиков с точки зрения разработчика ^[17]

Николай Алименков/XP Injection

Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо, что-то тут не так? Хотелось бы поговорить о том, как тестировщиков видят сами разработчики. В докладе будет приведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои.

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

Николай Алименков

Практикующий Java-техлид и Delivery Manager. Эксперт в разработке на Java, Agile-практиках и управлении проектами. Разрабатывает на Java более 12 лет, специализируется на разработке сложных распределённых масштабируемых систем. Активный участник и докладчик многих международных конференций. Основатель и тренер тренингового центра XP Injection. Организатор и идеолог конференций Selenium Camp, JEEConf, XP Days Ukraine и IT Brunch. Основатель «Клуба анонимных разработчиков».

---

День второй. 9 декабря.

Простота, доверие, контроль — три кита автоматизации веб-тестирования ^[18]

Артем Ерошенко/Независимый консультант

Доклад про автоматизацию веб-интерфейсов от автора инструментов Allure и HtmlElements.

Давно занимаясь проектами, связанными с автоматизацией веб-тестирования, Артем сформировал свод правил, которые обеспечивают комфортную работу ему и его команде на протяжении жизни всего проекта от первого теста до нескольких тысяч. Этот свод правил условно разделен на три группы: «Простота разработки», «Доверие к результатам» и «Контроль качества».

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

Артем Ерошенко

Более 8 лет занимается автоматизацией тестирования веб-приложений. За это время работал в разных командах и в разных ролях: автоматизатор тестирования, менеджер команды разработки инструментов тестирования, руководитель группы автоматизации тестирования. Артем имеет большой опыт работы с популярными инструментами (Selenium, HtmlElements, Allure, Jenkins). Программирует в основном на Java, Groovy.

---

Разработчик + тестировщик = качество++ ^[19]

Николай Алименков/XP Injection

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

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

В докладе мы поговорим о мотивации парной работы разработчика с тестировщиком, конкретных практиках и подходах на разных этапах работы над задачами, а также преимуществах, которые могут извлечь обе стороны из такой работы.

Николай Алименков

Практикующий Java-техлид и Delivery Manager. Эксперт в разработке на Java, Agile-практиках и управлении проектами. Разрабатывает на Java более 12 лет, специализируется на разработке сложных распределённых масштабируемых систем. Активный участник и докладчик многих международных конференций. Основатель и тренер тренингового центра XP Injection. Организатор и идеолог конференций Selenium Camp, JEEConf, XP Days Ukraine и IT Brunch. Основатель «Клуба анонимных разработчиков».

---

Строим свой тестовый фреймворк, c Jenkins Pipeline и библиотеками ^[20]

Олег Ненашев/CloudBees

Появление Pipeline изменило подходы к автоматизации задач в Jenkins, особенно в случае параллельных сборок и тестов. В нем можно построить свой тестовый фреймворк и предоставить его автоматизаторам как набор библиотек.

На примере Java-проектов покажем, как можно строить Pipeline-библиотеки для задач QA и переносить проекты на новую платформу. Мы интегрируем Docker, Maven, JUnit, FindBugs, Сoverity, а потом реализуем динамическую параллелизацию тестов. Также поговорим о подводных камнях и о том, как можно эффективно разрабатывать, тестировать и поддерживать подобные фреймворки.

Олег Ненашев

Разработчик в CloudBees, состоит в core team проекта Jenkins. C 2008 года занимается автоматизацией, инфраструктурой и фреймворкостроением для крупных программно-аппаратных проектов с помощью Jenkins и десятков других тулов. Пишет код, поддерживает ядро и плагины Jenkins, организует митапы в СПб и других городах.

---

Разработка и тестирование с Google ^[21]

Всеволод Брекелов/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.

---

Flaky tests ^[22]

Андрей Солнцев/Codeborne

Flaky tests — головная боль автотестеров. Ещё вчера тест был зелёный, а сегодня он вдруг покраснел — ни с того ни с сего. Никто ничего не менял. Просто луна не в той фазе. Просто матрица шутит над тобой.

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

Андрей Солнцев

Андрей — разработчик в эстонской компании Codeborne. Автор фреймворка Selenide, организатор таллиннского Devclub, частый докладчик на конференциях. Ярый приверженец экстремального программирования, автоматических тестов, парного программирования и чистого кода.

---

Завершающий кейноут: Truths about technical testing ^[23]

Alan Page/Unity

Большинство из нас слышали от уважаемых людей (или читали в интернете) «техническом тестировании». Конечно, технические знания — критически важная вещь для успеха. Но, несмотря на то, что большинство докладов о техническом тестировании заключается в обсуждении проблем автоматизации тестирования, как правило, нашим техническим ноу-хау существуют куда более ценные применения.

В этом завершающем кейноуте Алан Пейдж поделится своим подходом к техническому тестированию, причинами, почему в своей команде они уменьшают количество автоматизации и как именно тестировщики могут более эффективно распорядиться своим техническим бэкграундом, чтобы внести больший вклад в работу команды. Кроме всего прочего, Алан покажет примеры наиболее любимых и практичных инструментов тестирования и расскажет о пользе наработки мощного и разностороннего набора инструментов.

Alan Page

Алан Пейдж проработал тестировщиком программного обеспечения примерно 25 лет. Он был основным автором книги «How We Test Software at Microsoft» ^[15] и поучаствовал в создании «Beautiful Testing and Experiences of Test Automation: Case Studies of Software Test Automation» ^[16]. Кроме того, он пишет статьи на различные инженерные темы в своем блоге, его посты можно найти повсюду в интернете. Его последняя «книга» является коллекцией эссе на тему автоматического тестирования под общим именем «The A Word». Алан присоединился к Microsoft и стал частью команды Windows 95, и с тех пор работал над множеством релизов Windows, над ранними версиями Internet Explorer и Office Lync. В том числе, Алан два года проработал в Microsoft директором по тестированию. В январе 2017 года Алан ушел из Microsoft на должность директора по качеству в Unity.

---

Заключение

Теперь доступна вся информация, позволяющая определиться «смотреть ли открытую трансляцию». Надеюсь, программа получилась хорошей, и вы захотели к нам подключиться. Адрес трансляции вы уже знаете ^[5]. Ждём 8-9 декабря на конференции и у мониторов!

Автор: olegchir

Источник ^[24]