Два дня SQAdays-16 в Санкт-Петербурге, 14-15.11.2014. На эту конференцию я больше езжу, чтобы встретиться со знакомыми людьми. Хотя большинство участников - новые (реальное большинство, вроде 70-80%), оставшиеся - это то ядро, которое ездит на конференцию регулярно. Так что едешь, чтобы пообщаться, узнать что нового. У конференции - замечательная энергетика, интересны не только встречи со старыми знакомыми, но и общение с новыми.
Кстати, организаторы для общения устроили после первого дня замечательный afterparty. Приличную часть которого играла скрипка, и классику и попурри из шлягеров, выступал мим, и этим можно было наслаждаться. А еще - можно было разговаривать не повышая голос. Что, к сожалению прекратилось как только начала выступать рок-группа. Впрочем, их можно было слушать издали, из холла гостиницы, откуда они звучали гораздо мелодичнее и красивее, чем рядом. Да, я видел, что многие снимали выступление скрипачки на фото и видео. Если Вы выложили это в публичный доступ, просьба поделиться ссылками.
UPD: видео на FB от Olga Kiseleva, доступное для друзей.
О докладах. Уровень подачи докладов - очень хорош. Несмотря на то, что очень многие докладчики выступали впервые. И в этом большая заслуга программного комитета, который беспощадно тренировал докладчиков в прогонах и репетициях. Некоторые докладчики неофициально даже говорили, что не тренировал, а насиловал :) Так что форма - хорошая.
А вот с содержание - оно разное. И я тут попробую выделить категории того, что мне не нравится и могло бы быть улучшено.
Но в любом случае, все отмеченное касается части докладов, а никак не всех. Были хорошие взвешенные доклады, и технические, сделанные на высоком уровне, с раскрытием внутренней кухни сложных технических решений. И хорошие доклады по смежным, интересным для тестировщиков областям: менеджменту и мотивации, аналитике, клиентским отношениям. Часть из них сочетало общие теории, такие как стили менеджмента Адизеса или виды и шкалы эмоций Эмоционального интеллекта с практическим применением этого в ИТ для достижения конкретных целей.
Для участников конференции многие доклады несли ценные и новые идеи. Я общался с несколькими участниками, которые говорили, что почерпнули новые идеи почти изо всех слышанных докладов, во всяком случае, больше, чем из половины. И даже сетовали на то, что к вечеру восприятие уже становилось переполненным, они чувствовали, что в докладах есть ценные идеи, но воспринять не могли. Но, с другой стороны, по докладам будет видео и запомнившиеся, но не понятые вещи они смогут посмотреть.
Хотя весенняя конференция мне по уровню докладов понравилась больше. Впрочем, это естественный процесс, уровень невозможно повышать бесконечно. Программный комитет многое делает, чтобы конференция оправдывала свой девиз "SQAdays - точка роста твоей карьеры". А что нет принципиально новых докладов - так и в отрасли в целом принципиально новых подходов не возникает, идет развитие существующих. Но новые идеи - они появятся, за время моего участия в SQAdays (с 2011 года) я в этом убеждался неоднократно.
Дальше будут заметки о нескольких докладах, включая мой, которые я хотел бы отметить особо. Не о всех, на которых я был, потому что общаясь с участниками разного уровня понял, что не могу оценить доклад для разных слушателей и потому рассказ не будет ориентиром - слушать доклад или нет. И, более того, на многих докладах я не был, как в силу параллельно идущих треков, так и потому, что общение в кулуарах часто было интереснее: доклады потом можно просмотреть, а упущенное общение - не вернешь.
Но, прежде чем перейти к докладам расскажу про еще одну находку - поезд Москва-Питер, который идет, как и Сапсан, 4 часа, а стоит вдвое дешевле. Невский экспресс, в Питер 16:40-20:55, назад 15:11-19:20, билет около 1600-1700 в один конец. Устроен как купе, но с 6 сидячими местами, в купе есть розетки на 220, в пути кормят. Еще б WiFi сделали... При этом вагоны тащит обычный электровоз. Надеюсь, эта технология будет распространяться и скоростных поездов будет все больше. На заметку тем, кто часто ездит из Москвы в Питер и обратно.
Тестировщики - благодарные слушатели, они восприимчивы ко всему новому. В этот раз я не планировал выступать, но примерно за неделю меня попросили заменить докладчика и в результате я рассказывал доклад по Спиральной динамике. Эту тему я начал рассказывать на AgileDays, а летом на встрече тестировщиков в Москве попробовал изложить не как рассказ о теории, а как практическое знание, полезное тестировщику, который задумывается о менеджменте и взаимоотношениях с заказчиком. И, в общем, это не так просто - рассказать довольно сложную теорию неподготовленной аудитории. Вроде у меня получилось - мне на конференции говорило довольно много людей, что рассказ увлек настолько, что они решили прочитать книгу и глубже изучить вопрос. И по оценкам он был неплох, хотя и не вошел в тройку призеров. Я это не потому, что хвастаюсь (хотя хочется), а надеюсь таким образом побудить тех, кто читает мой отчет посмотреть видео, когда оно появится на сайте конференции или на моем сайте.
Доклады, которые я не могу отнести к определенной категории.
Начиналось все с концепции эмоционального интеллекта и классификацию эмоций. И я думал, что дальше пойдет в использование его при управлении группой. Или, что интереснее, про использование подходов, характерных для тестирования, при работе с эмоциями. А пошло в неожиданную область - как, прислушиваясь и анализируя свои эмоции, возникающие при тестировании, выявлять вполне технические проблемы программы или потенциальные проблемы процессов тестирования. С конкретными примерами по каждой эмоции.
Для справки - шкала эмоций из доклада от слабой к сильной.
На этот доклад я, к сожалению, зашел в самом конце и увидел список книг. После которого понял, что надо будет посмотреть доклад.
Книги - мне известны и достойны. А доклады о практическом применении таких книг обычно очень достойные.
Очень интересный доклад, как на основе PlantUML сделана визуализация покрытия автотестами. Есть модель области автотестов, описанная на PlantUML как диаграмма состояний: экранам соответствуют состояния, стрелки - виды переходов между экранами, а внутри состояния - действия на экране. Дальше модель мержится с логом теста, и раскрашивается: помечаются места, в которые тест заходил, добавляются элементы теста, в модели отсутствующие. Просто, дешево и элегантно.
Доклад про замену тест-кейсов (в формате инструкции для тупого исполнителя) чек-листами (в формате описания на 1-2 предложения в каком месте и что именно проверяется). Они на это пошли и в целом эффективность тестирования повысилась. И за счет того, что не надо разрабатывать и поддерживать большой массив тест кейсов, и за счет того, что вводя относительно произвольные данные тестировщики обеспечивают большее разнообразия тестов.
Понятно, что уместность такой замены зависит от подходов, может идти речь о совместном использовании обоих описаний с надлежащим балансом. И Алексей рассматривал это в контексте приемочного тестирования, но так, как у них применяется, без рассмотрения вариантов. Но, в любом случае, с моей точки зрения, основная ценность доклада - в опыте анти-догматиного процесса, и доклад - хорош.
Доклад был признан лучшим. В нем было рассмотрены принципы организации API, с помощью которого происходит тестирование в Badoo. Поверх этого API работает язык, позволяющий писать сценарии тестирования, в том числе - с переменными, потому что нужно уметь не только, например, создать пользователя, но и дальше с ним что-нибудь сделать. А еще - надо уметь получить для тестов пользователя с заданными свойствами из имеющихся. В общем, в докладе получилось заглянуть за кулисы сложной системы тестирования на уровне принципов, но достаточно конкретно - что позволяет применить те же идеи в своем проекте.
Интересно, что тестовые скрипты у них могут идти как в тестовом контуре, так и в боевом, на специально выделенном пуле pre-production машин.
Доклад о борьбе человеческого разума с драконами, порожденными разумом спящим. Поле борьбы - автоматическое тестирование некоторой сложной системы на Java с помощью плохо подходящего для этого инструмента - Rational Functional Testing, который им навязали. С описанием сложностей, которые возникают из-за плохого соответствия предположений инструмента об организации системы, и реальной организации тестируемой системы. И о том, как с это преодолевали, навертывая фреймворк с кешированием информации о системе вместо прямого обращения и другими наворотами - чтобы добиться приемлемого способа написания тестов и приемлемого быстродействия. В общем, человек победил драконов, но осмысленность данной битвы вызывает у меня большие сомнения.
Рассказ про опыт использования FitNesse и сопутствующих ему инструментов (NuGet, Fit, Slim, FitSharp, NetRunner), со сравнением и всякими особенностями, подключению к Cruise Control. И про организацию самих тестов, включая подсказки при написании.
Короткий обзор по видам конфликтов с примерами и выявлением конструктивной составляющей и созидательных, а не разрушительных способов решения. С моей точки зрения, классификация местаи путанная, и яс трудом сопоставлял некоторые из примеров заявленным типам конфликтов. Но, с другой стороны, как стартовая точка - вполне неплохо, а путаница может быть кажущейся, обусловленной краткостью изложения в блице: мы потом со Светланой говорили и некоторые из моих недоумений были развеяны.
Доклад получил вторую премию. Введение - про стили управления Адизеса - PAEI. А потом - связь с тест-менеджментом. Почувствовать стиль, понять где проседает - в конкретных примерах. Работать со своими слабыми сторонами. И через делегирование и через автоматизацию (это она про A).
Такие доклады всегда будут пользоваться популярностью: Адизес не входит в джентльменский стартовый набор и потому его непрерывно осваивают.
От себя хочу отметить то, чего в докладе не было. Адизес кодирует ваш собственный стиль в соответствующей позиции тремя уровнями: прочерк - отсутствие, маленькая буква - понимание, большая буква - применение. Все большие буквы - недостижимы, поэтому для управления всегда должна быть команда. А вот коммуникация между людьми возможна только по тем буквам, где у людей не пусто (нет прочерка). Это надо учитывать общаясь с начальством, подчиненными или коллегами.
Интересный доклад. Большая компания пустила за кулисы и показала, как у них внутри устроено. Пересказывать я не буду.
Доклад о том, как убеждать заказчика в эффективности автоматического тестирования. На его языке, показывая затраты и эффект - с помощью ROI-калькулятора. Они сделали на Excel написали свой, специализированный для тестирования - потому что вы знаете, как он работает, и можете объяснить результаты заказчику или начальнику.
Кроме калькулятора, Антон показывал ряд документов на английском языке:
И не просто показывал, а местами объяснял логику. Например, в калькуляторе сознательно тестирование развивающейся системы закладывается равномерно по годам, а не растет - потому что темпы роста являются холиваром. А аргументом за преимущества являются не только ROI, но и дополнительные выгоды, потенциальный список которых тоже есть и которые могут сыграть даже при отрицательном ROI. Часть из документов и калькулятор Антон обещал выложить в открытый доступ - они будут где-нибудь, а в финальной презентации доклада на сайте - будут ссылки.
А еще в докладе было про технические сложности, которые стоит рассмотреть прежде чем агитировать за автоматизацию тестов.
И конкретные советы. Например, что делать, если ошиблись в оценках и количестве тест-кейсов и прочее - в зависимости от доверительности отношений с заказчиком. Или про их схему работы персонала: они стараются, чтобы человек работал на двух-трех проектах с разными технологиями, потому что от одного - устаешь.
Доклад не столько про метрики, сколько про визуализацию. Используется BubleGraph в Excel. На конкретном примере их систем, с графиками по компонентам и их интерпретацией. Мне понравилось, и способ визуализации как таковой я взял на заметку.
ГИП - главный инженер проекта. Такой мегаответственный и многофункциональный куратор, работающий на нескольких проектах. Дарья рассказывала, как много от него нужно. И взять с рынка его нельзя, надо выращивать внутри. Идея мне понятная, но такой выбор должен иметь основания, по сравнению с альтернативами и рамки использования. Жаль, что об этом сказано не было.