Отчет о конференции QADnepr Mini Conference

В эту субботу 29 октября в Днепропетровске прошла первая конференция QADnepr Mini Conference от сообщества QA Dnepr. Темой была выбрана автоматизация тестирования. Сама конференция задумывалась как небольшое мероприятие на целый день с выступлениями в один поток. Докладчики собрались из разных городов Украины: Киев, Харьков и Днепропетровск. Темы докладов также подобрались совершенно разнообразные – от нагрузочного тестирования до тестирования мобильных приложений.

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

Организаторы выбрали очень классное место проведения – конференц-зал в новеньком офисе компании “Киевстар”. Здание находится недалеко от центра и открыто совсем недавно. Конференц-зал идеально подходит для проведения подобных мероприятий на 150-200 человек. Удобная сцена для докладчика, мягкие сиденья для участников, правильная форма зала, которая дает отличный обзор для всех присутствующих – все это делало посещение докладов очень комфортным. Как докладчик я еще могу добавить в копилку плюсов отличный звук и проектор, который не слепил глаза.

Утром я приехал пораньше чтобы выпить кофе и поболтать с коллегами. Просторный холл к тому времени уже был заполнен тестировщиками, общением и хрумканьем печенюшек. Приятно порадовало присутствие фруктов на всех кофе-паузах. Организаторы позаботились об участниках, закупив яблоки и бананы. С кофе вышла небольшая накладочка – хотелось бы “проснуться” от натурального кофе, а не напитка “3 в 1”. Но это уже если сильно придираться. Я повстречал много знакомых из разных городов, среди которых было достаточно много участников моих тренингов. Было очень приятно всех видеть. Такой интерес к конференции говорит о недостатке такого рода мероприятий и о верном выборе организаторов. Ведь иначе люди бы не ехали за сотни километров.

В холле стояли стенды компаний-спонсоров конференции. Они раздавали анкетки, по которым в конце дня должны были разыгрывать призы. Мое внимание привлекла игровая приставка Xbox с установленным к ней Kinect. Любой желающий мог свободно попробовать себя в различных играх. Я давно хочу приобрести себе такую домой и поэтому с радостью принял участие в виртуальном боксерском поединке. Было очень классно. Необычные ощущения. Мне удалось даже одержать победу техническим нокаутом. Рекомендую всем!

Конференция началась вовремя с вступительного слова организаторов. Это их первое подобное мероприятие и они очень волновались. Во время открытия я обнаружил вторую и последнюю проблему – отсутствие Wifi. Я планировал вести трансляцию в Twitter, по крайней мере чтобы дать повод для подколов Леше Солнцеву. Но не судьба.

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

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

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

Перез обедом мой коллега по компании Zoral Labs Иван Лысенко поделился советами по поводу анализа результатов нагрузочного тестирования. На мой взгляд доклад был очень классный, ведь организовывать тестирование – это лишь половина дела. Ошибка при анализе его результатов может свести на нет все усилия. Иван на примере показал способы обработки статистической информации и связывания ее с проблемами в приложении. Здорово, что данная тема была затронута, ведь ее освещают не так часто как стоило бы.

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

Мне пришлось выступать после обеда. Это самое сложное время. Не все успевают вернуться, многих после обеда клонит в сон и не все готовы воспринимать информацию. А еще и тема моего доклада была достаточно провокационной – “Жизнь без тестировщиков: миф или реальность?”. И это на конференции тестировщиков-автоматизаторов! 😉

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

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

Пересказывать свой доклад в деталях не буду. Вот презентация (звук добавлю как только организаторы им поделятся):

Следом за мной выступал Александр Качур с докладом про автоматизацию мобильных приложений под Android и MeeGo. Я очень далек от мобильной разработки, поэтому мало что вынес для себя полезного из доклада. Очень жаль, что не заработали видеоролики с демонстрацией написания и запуска тестов. Без них доклад смотрелся немного неполным. Но это была, к сожалению, неожиданная техническая проблема, которую так и не удалось победить. Зато для себя я сделал заметку с идеей очень классного выступления.

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

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

Это был последний доклад. После него начался розыгрыш призов. Он принес несколько неожиданностей. Во-первых, Андрей Дзыня умудрился выиграть Amazon Kindle, который он очень хотел. Во-вторых, я прислушался к советам Кэпа Очевидность и заработал много баллов в викторине о компании-спонсоре Apriorit, за что был награжден веб-камерой. Вот такие приятные сюрпризы. Потом все докладчики вышли на сцену вместе с организаторами для прощальных аплодисментов. На этой позитивной нотке закончилась первая конференция сообщества QA Dnepr. Но, по словам организаторов, далеко не последняя. Такие мероприятия очень сильно развивают рынок IT. Поэтому хочу пожелать ребятам успехов в их нелегком труде.

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

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

Обсуждение (10)

Да, книгу видел. Я буду на XP Days Ukraine, постараюсь пробиться 🙂

Ну книжку и ее сайт ты наверное уже видел: http://continuousdelivery.com. Обсудить не знаю где. Я буду доклад делать на XP Days Urkaine по этой теме.

ну у нас деплои руками идут и после того, как разработчик проверил на стейджинге работу. За 7 месяцев такого режима пока было только 2-3 проблемы, но и те не критичные.

Кстати, по поводу CD – может подскажешь какие нибудь сайты/книги где можно почитать об опыте других?, т.к. у нас еще не все так гладко как хотелось бы, особенно с ветками в свн и обновлениями базы данных

Помогать нужно 100%. А по поводу Continuous Deployment – я поддерживаю на все 100, но предпочитаю все таки до продакшена доводить после получения “добро” от заказчиков. Но, если бед не случается, то будет и так работать. Просто с продакшеном шутки плохи. И давать туда всем деплоить очень рискованно. В современных инструментах даже сделан отдельный шаг ручного апрува. 🙂

Баги да, заказчики не смотрят на их исправление. Стейджинг у нас есть (вместе с dev и qa окружениями) и это последний оплот перед продакшеном, но у нас continuous deployment и каждый разрабочик сам деплоит свою работу в продакшен и в таком режиме (да еще и с 6-ю часами разницы) у заказчика нет шансов проверить все, хотя основные фичи они и стараются смотреть

В общем спасибо за ответ, будем пробовать улучшать ситуацию. У нас 2 тестера и они бедные уже не выдерживают нагрузок, надо им помогать 🙂

Вопрос интересный. Я не считаю, что фиксы багов должны принимать заказчики. Вы должны на своей стороне сделать максимум чтобы баг был правильно исправлен и больше не повторился. А вот с фичей настоятельно рекомендую проводить все их через специальную среду staging, где заказчик убедится в их работоспособности и даст добро на деплой в production. Иначе может быть очень больно потом. И им не нужно тестировать в деталях. Чаще всего они просто пробуют основные пути. Если не получится, то уделите больше внимания подготовке приемочных критериев и тестов на их основе. И посмотрите будет ли это срабатывать в вашем случае. Если нет – разберитесь почему и почините эту фазу. И так по циклу.

После твоей презентации у меня появился один вопрос, который я к сожалению так и не смог задать – к тебе невозможно было пробиться 🙂

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

А что делать, если у нас релизов в день по 10 – 15 штук? Со стороны заказчика есть 4 человека, которые принимают решения по развитию проекта и которые смотрят на результаты нашей работы, но проверять столько работы каждый день они не смогут. Конечно, эти релизы не все несут новые фичи, большинство из них багофиксы, но даже 10 фич в неделю довольно сложно протестировать. Как бы ты посоветовал в таком случае работать без тестировщиков?

Хороший, последовательный отчет. Я сейчас свой пишу. Спасибо тебе еще раз, что помог в моем докладе!

Leave a Reply

Your email address will not be published. Required fields are marked *