Конференция TestingStage’17 двухдневная, разделенная на 3 потока. В первом представлены доклады, в третьем - мастер классы, а во втором микс (часть докладов и часть мастер-классов).
Впечатление неоднозначное, выводы будут в конце. Однозначно лишь одно - ехать стоило.
Итак, по-порядку.
Первый день.
Открыл конференцию доклад Рекса Блека об Agile V-model, что, как бы, является противоречием. Доклад рассказывал о подходах, которые позволяют сочетать теорию тестирования, основанную на V-модели, с гибкими практиками разработки.
Далее потоки разделились и пришлось выбирать интересные темы. Меня интересовали в основном темы из 1 потока, поэтому я слушал доклады именно здесь.
Следующим был доклад о менеджменте больших команд, каких-то озарений он не принес. Кратко все укладывалось в классическое “разделяй и властвуй”. Единственная мысль, которая меня зацепила, неведомая мне доселе роль QA координатора. Также услышал еще одно подтверждение давно болтавшейся без четкого оформления идеи - автотесты должны запускать мануальные тестировщики.
Дальше был интересный, на мой взгляд, доклад о применении подходов и техник ISTQB для улучшения тестового процесса. Конечно, не последнюю роль в интересе к теме сыграл лектор (Антон Мужайло), который очень интересно рассказывал о том, как применить на практике сухую теорию из источников для подготовки к сертификации. Выбор метрик (метрики - измеряемы, качество само по себе - не метрика), опять “разделяй и властвуй” при оценке рисков, business workflow map, карта продукта и т.д. Много интересных, вроде бы простых и очевидных вещей оформлялось в конкретные слова и действия для внедрения в QA процесс. А главное все было подытожено идеей, что мы должны заниматься не столько поиском багов (тестировать), сколько обеспечением качества (QA процесс), то есть работать над тем, чтоб те самые баги предотвращать.
Следующим был доклад “REAL CASE: HOW TO REDUCE TIME NEEDED FOR AUTOMATED TESTS CREATION AND SUPPORT”. Было немного теории и пример в IDE по построению фреймворка для тестирования Rest API при помощи нескольких инструментов, в том числе rest-assured библиотеки. А основной идеей была автогенерация кода (а также сопутствующей документации) при изменении контрактов. Вопрос про то, что будет, если ошибки допущены в самих контрактах так и остался без ответа (как на лекции, так и в приложении TestingStage’17 в чате доклада).
Честно говоря, субъективно мне не понравился сам докладчик (Сергей Пирогов). Это повлияло на мою оценку.
*На следующий день Сергей вел мастер класс, по отзывам, достойный, но я его уже не посещал.
Как я выяснил из общения с людьми, для тех, кто не занимался тестированием API ранее тема была интересна и довольно наглядна.
Как я выяснил из общения с людьми, для тех, кто не занимался тестированием API ранее тема была интересна и довольно наглядна.
Также заинтересовал доклад об упрощении автоматизации тестирования с использованием дизайн паттернов. Докладчик говорил довольно интересно, показывал примеры.
Тема о кроссбраузерном тестировании нас заинтересовала, но оказалось довольно банальной: посчитайте, сколько стоит облачное решение, посчитайте, сколько стоит своё железо/лицензии/админы; запланируйте, сколько продлится ваш проект; посчитайте, что выгоднее и сделайте выбор. Основная идея: облачный сервис дешевле на старте, но это постоянные расходы; свои окружения дороже сначала, но далее дешевле готовых решений. Вопрос в том, дойдет ли ваш проект до точки окупаемости и есть ли силы/квалификация заниматься своими окружениями: покупать лицензии, поднимать окружения, делать настройки, строить свои инфраструктуру.
В конце дня была очень странная лекция с интригующим названием “QA EVOLUTION: Z GENERATION". В реальности все было ни о чем. Кое-кто очень хвалил свою крутую команду и как круто на нее выбивают деньги от заказчика. На вопрос, а что если денег не дают, лектор впадала в ступор. В общем, по сути речь о том, как круто работать менеджером, когда все хорошо. Вопрос лишь в том, каким ты будешь управленцем, когда лодку покачнёт?
На сим первый день закончился.
Второй день.
Второй день начался с официального спича представителей института ISQI. Речь была по большей части рекламной, они презентовали свои достижения: признание сертификатов в мире, рост количества сертифицированных специалистов, новые программы и направления, связанные с разработкой и обеспечением качества ПО. На их стенде также можно было пройти регистрацию и поучаствовать в розыгрыше сертификации ISTQB Advanced level.
В 3 зале в это время начался мастер класс по тестированию требований, и сработал метод “кто первый встал - того и тапки”. Зал оказался полностью забит.
Поэтому мы немного отдохнули в лаундж зоне, посмотрев как народ рушит двухметровые башни, играя в Jenga, поохотились на пауков в очках виртуальной реальности, побывали в шкуре Лары Крофт, пробираясь в лабиринте из лазерных лучей, в конце концов, попили чаю с печеньками, развалившись на пуфиках.
Следующим докладом, который меня зацепил, был доклад о том, как знание системы изнутри может помочь тестированию продуктов (автор Андрей Дзиня). Людей было немного, и доклад очень быстро перетёк в такой неформальный разговор. Слушатели сели на стульях вокруг лектора и задавали насущные вопросы.
На самом деле, эта идея мне сейчас очень импонирует. Раньше я уже задумывался о том, почему же тестирование должно быть неотделимо от разработки. Теперь я понимаю почему и как нужно тестировать “белый ящик”, в чем именно мы чувствуем от этого пользу. Этот доклад еще раз подтвердил мои размышления о том, куда мы должны стремится и чем заниматься, чтобы действительно выводить продукты на качественный уровень.
Возвращаясь к презентации, были подчеркнуты такие моменты, как: уровень квалификации команды (чтоб понять “белый ящик”, надо иметь достаточный уровень компетенции), автоматизация тестирования - это всегда только верификация, круто иметь GoldenPath (новое понятие) - алгоритмы по шагам с решением типичных задач и проблем при работе с проектом.
На следующую лекцию я попал чисто по фану, хотелось посмотреть на живого работника стартапа. Тема “КАК ВЫЖИТЬ ТЕСТИРОВЩИКУ В LEAN STARTUP”. Николай Фалецкий оказался довольно бодрым, заводным лектором и рассказал о своем опыте. То, что было написано на слайдах было не всегда и не совсем понятно (наверно, потому что я не Питонщик). Но вся суть рассказа вылилась в то, что здесь именно надо выживать. Когда ты приходишь работать в стартап - никто не знает что делать. Все постоянно меняется. Работа короткими итерациями, быстрые фидбеки от заказчиков “купил бы - не купил бы”. Работа с версией “купил бы” и дальше. Надо быстро учиться и много работать.
И в итоге из такого котла выходят крепкие специалисты, которые очень быстро осваивают новые горизонты, быстро реагируют на изменения, а коллег считают семьей.
Как сказал Николай позже, в разговоре за сценой, “если бы к нам в команду пришел новый (второй) QA, я бы бросил его в тот же котел, в котором был сам, чтобы он там выжил и стал частью команды. То есть пройти этот путь стоит каждому.”
Далее мы посетили мастер-класс Дениса Звездова о тестировании с применением BDD подхода. Рассказывал и показывал он хорошо, но ничего особо нового для себя я отсюда не вынес.
Заключающим докладом был рассказ о конфликтологии в IT. В программе он подавался как мастер класс, но в результате это был 20 минутный пересказ части книги о конфликтологии. Какое отношение этот доклад имеет к IT? Понятия не имею. Единственное пересечение - это слово “IT” в названии. Не понравилось. Хотя я и учился на курсах переговорщиков, и участвовал в поединках, то есть тема мне близка. Доклад был реально ни о чем, и тем более - без учета специфики.
После было закрытие конференции, разыграли подарки от спонсоров, всех поблагодарили, и мы отправились гулять по Киеву в ожидании дороги домой.
Многие писали в чатах конференции о недостатке еды, невкусных печеньках, неорганизованности залов, туалетов. Но, как по мне, мы сюда не за “покушать” приезжали, и своей цели мы достигли: посмотрели на то, что происходит в индустрии в стране, послушали про чужой опыт и примерили его на себя, узнали новые словечки (названия инструментов и подходов), которые теперь можем, при случае, попробовать.
Общие выводы:
- Хорошее мероприятие, чтобы понять свой уровень.
- Не надо быть “семи пядей во лбу”, чтобы выступать. Вполне можно стать спикером, причем даже возможно быть в топе.
- Общение “за сценой” - наверно самая информативная часть мероприятия. Поэтому видеозаписи докладов - это хорошо, но живое присутствие на таких мероприятиях необходимо.
- Задавая (интересные) вопросы, можно пробудить интерес к себе со стороны коллег, которые придут к тебе пообщаться в кулуарах. Так можно строить нетворкинг и, соответственно, продавать свои идеи и продукты с “низов”(как минимум).
- Каждый делится своим опытом, и не всегда (к сожалению) этот опыт можно перенести на других. Приятно слушать спикеров, которые это признают, и неприятно тех, кто говорит о других подходах “bullshit”.
- Многие не любят BDD, но в основном это от того, что они не умеют его готовить. Здесь было как минимум 2 мастер-класса о том, как это правильно делать.
- Лучше всего тестирование проводить в связке с разработкой.
Вопросы к себе:
- Как применять подходы к оценке качества работая в сервисной модели “Тестирование как сервис”
Советы организаторам:
- Разделить потоки на технические, менеджерские и общие (либо ставить пометки лекциям).
- Делать предпросмотр докладов, чтоб не попадали доклады далекие от IT и QA (например, как последний доклад про конфликтологию).
