Всем привет! Я Алексей Платковский, драйвер QA SPb Community в EPAM. И сегодня я расскажу вам про свой опыт организации хакатона для автоматизаторов, от идеи до финала. Не обойдём стороной и ошибки, выученные уроки, и в финале поделимся планами на будущий год.
После второго митапа мы задумались: делиться знаниями и помогать аудитории прокачивать навыки — это здорово, но что, если мы посмотрим, что умеют другие? Как пригласить выступать всех желающих? Любое общение более продуктивно, когда оно двухстороннее. Формат митапов этого сделать не позволяет, и тогда мы вспомнили про хакатоны.
Первым делом надо было определиться с темой хакатона — и это стало едва ли не самым сложным. С чем у всех ассоциируется работа автоматизатора? Накидал фреймворк (или взял один из самых популярных на рынке), подключил Allure, запилил тесты, воткнул это всё на Jenkins — и радуйся жизни. Интересно провернуть такое на хакатоне? Кому-то, наверное, да, но не нам.
Да — потому что, как показывает практика, даже здесь есть некое разнообразие. JUnit или TestNG? Изобретать свой фреймворк или взять Selenide? Какие паттерны применить для написания тестов? BDD или не BDD? Maven против Gradle?
К тому же, как показывает практика и опросы, не все имели возможность построить автоматизацию на проекте с нуля, многим она достаётся в наследство от уволившихся (или даже действующих) коллег или от заказчика. Так что попробовать построить фреймворк с нуля в рамках хакатона — отличная идея.
С другой стороны, опытный человек делал это уже 100500 раз, он составит pom-файл едва ли не по памяти, а то и вовсе держит где-нибудь на git’e «каркас» готового проекта, куда только мелкие изменения внести — и можно тесты писать.
После небольшого мозгового штурма было принято решение не зацикливаться на самих тестах ― конечно, интересно проверить, как человек их пишет, знает ли теорию тестирования, но это больше похоже на задание при приёме на работу, чем на соревнование. Да и просто подтянуть десяток зависимостей в maven или gradle тоже творчеством не назовёшь.
«Голь на выдумки хитра» — эта фраза лучше всего описывает то, к чему мы в итоге пришли. Запретить всё, кроме базовых вещей, и посмотреть, что команда может показать в таких условиях. Итоговое задание было сформулировано следующим образом:
Фреймворк команды должен содержать:
Во-первых, мы надеялись, что к осени локдауны уйдут в прошлое. Во-вторых, хоть летом кодить сутки на пролёт при белых ночах и выглядит заманчивее, но сезон отпусков может не позволить всем желающим принять участие в хакатоне.
Старт рекламной кампании мы запланировали на третью декаду августа и предполагали закончить её буквально за пару дней до хакатона. Принять участие могла команда от 2 до 6 человек, и мы рассчитывали набрать хотя бы 10 команд. Однако, с переносом мероприятия в онлайн, мы увеличили этот лимит до 50 — ведь исчезало ограничение проверять всё здесь и сейчас, чтобы участники могли успеть на поезд, самолёт или просто могли спокойно ехать домой отсыпаться. Каково же было наше удивление, когда уже в первые 7 дней мы привлекли порядка 40 команд! В итоге мы закрыли регистрацию уже на 10-й день, существенно опередив график.
После досрочного закрытия регистрации мы пригласили всех участников в телеграм-канал, для координации и оперативных оповещений. Примерно за сутки до самого мероприятия мы огласили технические требования и ограничения в использовании готовых решений — и тут началось!
Задание вызвало бурные обсуждения в телеграм-канале хакатона среди участников. Многим не понравились накладываемые ограничения, но, как сказал глава нашей практики Алексей Гирин:
Второй ложкой дёгтя в нашей бочке оказалась неготовность сервера с Jenkins, которая обнаружилась сразу после старта хакатона. Мы думали, что настроили его, но оказалось, что показалось. Спасибо участникам, которые отнеслись к этому с пониманием, и помогали нам «тестировать» сервис следующие 4 часа. Спасибо команде техподдержки, которая потратила часть своего выходного дня, чтобы привести Jenkins в порядок, причесала и пригладила его. А мы себе на ретро одним из первых пунктов записали «создать в следующий раз тестовую джобу и прогнать хотя бы один тест на ней».
Надо сказать, что четвёрка лидеров расположилась очень плотно, а команда, занявшая первое место, обошла соперников за счёт того, что единственная догадалась написать API тесты. Последнее не было явно прописано в задании, но мы делали прозрачные намёки, да и само тестовое приложение располагало к такому виду тестирования — так что можно считать это бонусом за сообразительность.
Итоговый пъедестал выглядит следующим образом:
Что мы точно переделаем:
habr.com
Немного предыстории
В декабре 2019 года у меня появилась идея создать площадку для обмена опытом среди QA питерского офиса EPAM, а также за его пределами. Начальство поддержало инициативу, и уже в январе мы провели первый митап на внешнюю и внутреннюю аудиторию, где обсудили «Contract testing with Spring Cloud Contract» и «Теорию игр в вопросах стаффинга и ротаций». Мероприятие зашло на ура и нам, и слушателям.После второго митапа мы задумались: делиться знаниями и помогать аудитории прокачивать навыки — это здорово, но что, если мы посмотрим, что умеют другие? Как пригласить выступать всех желающих? Любое общение более продуктивно, когда оно двухстороннее. Формат митапов этого сделать не позволяет, и тогда мы вспомнили про хакатоны.
Что? Где? Когда?
К сожалению, всем известная причина заставила нас отложить идею хакатона в долгий ящик на целый год, пока в начале 2021-го не появились вакцины. Уже в феврале мы вытащили на свет божий наброски прошлого года, смахнули с них пыль и начали готовиться к мероприятию.Первым делом надо было определиться с темой хакатона — и это стало едва ли не самым сложным. С чем у всех ассоциируется работа автоматизатора? Накидал фреймворк (или взял один из самых популярных на рынке), подключил Allure, запилил тесты, воткнул это всё на Jenkins — и радуйся жизни. Интересно провернуть такое на хакатоне? Кому-то, наверное, да, но не нам.
Да — потому что, как показывает практика, даже здесь есть некое разнообразие. JUnit или TestNG? Изобретать свой фреймворк или взять Selenide? Какие паттерны применить для написания тестов? BDD или не BDD? Maven против Gradle?
К тому же, как показывает практика и опросы, не все имели возможность построить автоматизацию на проекте с нуля, многим она достаётся в наследство от уволившихся (или даже действующих) коллег или от заказчика. Так что попробовать построить фреймворк с нуля в рамках хакатона — отличная идея.
С другой стороны, опытный человек делал это уже 100500 раз, он составит pom-файл едва ли не по памяти, а то и вовсе держит где-нибудь на git’e «каркас» готового проекта, куда только мелкие изменения внести — и можно тесты писать.
После небольшого мозгового штурма было принято решение не зацикливаться на самих тестах ― конечно, интересно проверить, как человек их пишет, знает ли теорию тестирования, но это больше похоже на задание при приёме на работу, чем на соревнование. Да и просто подтянуть десяток зависимостей в maven или gradle тоже творчеством не назовёшь.
«Голь на выдумки хитра» — эта фраза лучше всего описывает то, к чему мы в итоге пришли. Запретить всё, кроме базовых вещей, и посмотреть, что команда может показать в таких условиях. Итоговое задание было сформулировано следующим образом:
Фреймворк команды должен содержать:
- обёртку для Webdriver и\или Webelement;
- модуль репортинга на базе TestNG или JUnit, написанный командой;
- модуль логирования, написанный командой (нельзя использовать готовые библиотеки, такие как Jog4j и подобные);
- набор тестов на Cucumber/JBehave;
- Runner для Cucumber/JBehave тестов, который позволит запускать их:
i. по тэгам,
ii. в несколько потоков,
iii. запускать тесты в зависимости друг от друга (Тест2 запускается после Теста1),
iv. даст возможность указывать тесты, которые не могут быть запущены в параллель; - любой другой модуль, который команда посчитает необходимым самостоятельно написать в рамках хакатона.
Во-первых, мы надеялись, что к осени локдауны уйдут в прошлое. Во-вторых, хоть летом кодить сутки на пролёт при белых ночах и выглядит заманчивее, но сезон отпусков может не позволить всем желающим принять участие в хакатоне.
Подготовка
Следующим этапом был сбор команды. Необходимо было найти 3-4 судьи, которые могут качественно проверить n-ое количество работ в сжатые сроки (напомню, мы рассчитывали на офлайн, а значит, у нас максимум 1-2 часа на оценку участников). Поскольку у EPAM есть свой учебный центр, и с этим пунктом особых проблем не возникло: мы прошлись по преподавателям и быстро набрали необходимое количество добровольцев, имеющих достаточный опыт в оценке чужих работ и выработавших плюс-минус единый стандарт оценок. Последнее было важным пунктом, нам не хотелось столкнуться с обвинениями в ангажированности и «вкусовщине».Старт рекламной кампании мы запланировали на третью декаду августа и предполагали закончить её буквально за пару дней до хакатона. Принять участие могла команда от 2 до 6 человек, и мы рассчитывали набрать хотя бы 10 команд. Однако, с переносом мероприятия в онлайн, мы увеличили этот лимит до 50 — ведь исчезало ограничение проверять всё здесь и сейчас, чтобы участники могли успеть на поезд, самолёт или просто могли спокойно ехать домой отсыпаться. Каково же было наше удивление, когда уже в первые 7 дней мы привлекли порядка 40 команд! В итоге мы закрыли регистрацию уже на 10-й день, существенно опередив график.
После досрочного закрытия регистрации мы пригласили всех участников в телеграм-канал, для координации и оперативных оповещений. Примерно за сутки до самого мероприятия мы огласили технические требования и ограничения в использовании готовых решений — и тут началось!
Задание вызвало бурные обсуждения в телеграм-канале хакатона среди участников. Многим не понравились накладываемые ограничения, но, как сказал глава нашей практики Алексей Гирин:
Нам не удалось полностью погасить градус недовольства, часть участников на этом этапе отвалилась: кто-то из-за несогласия с регламентом, кто-то после (недо-)оценки своих сил.
Второй ложкой дёгтя в нашей бочке оказалась неготовность сервера с Jenkins, которая обнаружилась сразу после старта хакатона. Мы думали, что настроили его, но оказалось, что показалось. Спасибо участникам, которые отнеслись к этому с пониманием, и помогали нам «тестировать» сервис следующие 4 часа. Спасибо команде техподдержки, которая потратила часть своего выходного дня, чтобы привести Jenkins в порядок, причесала и пригладила его. А мы себе на ретро одним из первых пунктов записали «создать в следующий раз тестовую джобу и прогнать хотя бы один тест на ней».
Результаты
До финала в итоге дошли 10 команд. Система оценок была следующей: 4 члена жюри оценивали код и тесты по 10-бальной системе, всего 7 критериев: архитектура Web и API модулей, code style, систему репортинга, Логгер, раннер для BDD и тест-кейсы в этом самом всеми (не-)любимом BDD. Отдельный специалист занимался Jenkins джобами, здесь мы его полёт фантазии ничем не ограничивали, человек нашёл 9 критериев для оценки. Далее бралась средняя арифметическая оценка по Jenkins, плюсовалась к оценкам за само решение — и получался победитель.Надо сказать, что четвёрка лидеров расположилась очень плотно, а команда, занявшая первое место, обошла соперников за счёт того, что единственная догадалась написать API тесты. Последнее не было явно прописано в задании, но мы делали прозрачные намёки, да и само тестовое приложение располагало к такому виду тестирования — так что можно считать это бонусом за сообразительность.
Итоговый пъедестал выглядит следующим образом:
- 1 место ― QA. GURU Team, капитан ― Станислав Васенков
- 2 место ― Шарписты, капитан — Сергей Шукалович
- 3 место — Emerald, капитан — Иван Алексеевич Иевлев
- 2 друга это сила
- MonkeyHeap
- selfCoop
- SFQA_001
- Solo-bolo
- Котоёж-котоёж
- ПуффенЖDI
- Тестирование и Отвага
Работа над ошибками
Не всё прошло гладко, некоторые вещи получились откровенно плохими. Мы собрали все отзывы, плохие и хорошие, провели внутреннее ретро, записали, сохранили, и в следующий раз постараемся не накосячить. Ну или хотя бы сделать меньше ошибок.Что мы точно переделаем:
- Задание. Оно оказалось слишком сложным, многих это отпугнуло.
- Ограничения по используемым инструментам. Даёшь творческую свободу! (Правда, выбор языков всё равно останется узким, Java и Java-подобные языки, Python, возможно, добавим С++ – нам это всё проверять, а универсалов, хорошо знающих такое количество языков, не так уж и много).
- Техническую подготовку. Jenkins (если он будет) надо тестировать заранее. Мы так боялись, что упадёт сервер с тестовым приложением, что как-то забыли, что есть и другие места, требующие тщательной проверки.
- Сам анонс задания следует делать заранее. Правда, тут палка о двух концах — не хочется, чтобы люди приходили с готовыми решениями, с другой стороны — люди должны понимать, на что они подписываются. Будем искать баланс между информативностью и интригой.
- Количество регистраций. По сути, с конверсией 20% можно никаких ограничений не делать. Вряд ли мы увидим 100500 желающих, а любые вменяемые цифры нам точно по плечу, в крайнем случае возьмём дополнительное время на проверку — всё-таки онлайн развязывает руки в таких вопросах.
Как мы делали первый в СНГ хакатон для автоматизаторов: от идеи до реализации, достижения и ошибки
Всем привет! Я Алексей Платковский, драйвер QA SPb Community в EPAM. И сегодня я расскажу вам про свой опыт организации хакатона для автоматизаторов, от идеи до финала. Не обойдём стороной и ошибки,...
habr.com