Software Quality Days 2014

Короткая ссылка: SQdays-2014-Vienna

Ссылки сюда (4) →

В январе я съездил в Вену на Software Quality Days 2014. Конференция немецкая, но в программе было много английских докладов, иногда параллельно на нескольких треках, а темы были заявлены интересные. И в целом я доволен тем, что съездил, хотя все-таки незнание немецкого сказывалось сильно - ты не можешь принимать полноценное участие в общении: хотя английский все участники знают, разговор идет на немецком и послушать и включиться, как я делаю у нас - не получается.

Я получил впечатление об общем уровне и организации конференции, сравнил ее с отечественными. Наши в целом не хуже. Услышал несколько интересных докладов.

• обзорный доклад Hermann Sikora, открывающий конференцию
• доклад Tom Gilb про недостатки моделирования, хотя он был про проблемы и не рассказывал о решении
• и неожиданный доклад Stefan Holtel про использование LEGO для визуальных метафор

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

А еще - узнал про идею Resource Orienter Computing, в которой архитектуру приложения предлагается строить аналогично архитектуре интернета - на основе совокупности множества сервисов, для доступа к объектам которых используются адреса, аналогичные URL. Под эту архитектуру фирма 1060research предлагает свою платформу NetKernel, на которой много что реализовано. За счет этого там хорошо решаются вопросы масштабирования. Тут интересно, что в рассказе о заложенных в архитектуру принципах я опознал много конструкций, которые слышал в рассказе Microsoft об архитектуре Windows8 - я писал об этом в отчете о DevCon-2013. Так что, вполне возможно, это один из источников идей для архитектуры. И это - интересно.

Сравнение с нашими конференциями

Теперь о впечатлении в целом, сравнивая с нашими конференциями. По сравнению с SECR уровень ключевых докладчиков пониже, все-таки на SECR приезжают гуру мирового уровня, таких как Ивар Якобсон или Джеф Сазерленд. А вот уровень основной массы докладов повыше. Именно уровень изложения - спикеры понимают не просто место своей работы, но и позиционируют ее относительно других работ и вообще текущего положения в отрасли, а на наших конференциях часть докладчиков (не все) на это не обращают особого внимания. Примерно тоже можно сказать, сравнивая с другими нашими ведущими конференциями с приглашенными иностранными спикерами - SoftwarePeople, AgileDays.

Думаю, основа этого различия лежит в развитии отрасли как таковой - там не было разрыва, который у нас ИТ пережила в 90-е, когда прервалась преемственность, а новую отрасль создавали во многом практики. Но при этом конференция Software Quality Days - не научная, как MODELSWARD, на которой я был в прошлом году (мой отчет), а практическая, и доклады посвящены практическим проблемам, и есть доклады со спорными размышлениями о новых идеях, которые на научных конференциях не проходят.

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

Особенно интересно сравнить Software Quality Days с нашей профильной конференций SQA Days, у которой даже название очень похоже - Software Quality Assurance Days. Немцы шире смотрят на свою поляну. Все-таки у нас темой преимущественно является тестирование, а там оно - одно из, наряду с поставкой новых версий, требованиями и организацией эксплуатации. У нас это тоже присутствует, но меньше. Общий уровень докладов - вполне сопоставим, просто у немцев получше с теоретической составляющей, а у нас - с практической. А еще у нас много докладов, сделанных растущими специалистами и для новых растущих, а там доклады делают более состоявшиеся специалисты. Потому что у нас конференции занимают еще и образовательную нишу, дают направления для роста специалистов, в отличие от Европы, где для этого есть институты.

Участники - вендоры

Еще отличием конференции является довольно большое количество участников-вендоров, производящих ПО для тестирования, работы с требованиями, установки версия и так далее. Список гораздо более длинный, чем я обычно слышал на конференциях. Обычно упоминают монстров, у которых есть комплексные решения - HP, MS, реже IBM - и легкие свободные фреймворки - Selenium, Robot Framework, JUnit и другие. А здесь, кроме монстров, было большое количество компаний, занимающих промежуточное положение - и с комплексными решениями, правда, обычно выросшими из чего-то более специализированного, и с отдельными, такими, как распространение новых версий и патчей в гетерогенной среде. Называть компании я не буду, желающие могут посмотреть список спонсоров на странице конференции, и посмотреть что у них есть.

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

Было даже довольно интересный конкурс среди вендоров на "Лучший софт для обеспечения качества", в котором, правда, участвовали не все, а только 6 компаний - Microsoft, IBM, Polarion, Tricentis, Imbus, Ranorex. Каждой было дано 7 минут на презентацию, потом ответ на 3 вопроса жюри по минуте на каждый. А потом - голосование профессионального жюри и голосование всех участников по результатам. По голосованию зала победил Microsoft, и это довольно ожидаемо - у них и софт с низким порогом входа, и презентации они хорошо умеют делать. А профессиональное жюри выбрало Imbus - молодцы. Как и я :) Софт Imbus - наиболее полный из представленных, во всяком случае на уровне презентации, позволяет описывать модель от требований до тест-кейсов, сам порождает наборы тестовых данных по заданным характеристикам и прогоняет тесты. При этом, да он уступает Microsoft по графическому представлению и красивостям, но функционально, по-моему, полнее, и, наверное, более адекватен с точки зрения сопровождения развития продукта.

А еще, наблюдая за вендорами и их презентациями, я понял, для каждого хорошего продукта должен быть свой гартнеровский квадрат - надо только его придумать - это позиционирвоание - а потом уговорить Гартнера сделать такой рейтинг :) MS полтора года назад стало лидером в квадранте ALM, и я не смог тогда найти предыдущую версию квадранта, без MS. Compuware показывает гартнеровский квадрант где он лидер по мониторингу (и второй рядом)...

Подробнее про доклады

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

Открывал конференцию хороший доклад Top Executives, Software and Quality: A Hard Coded Conflict? Hermann Sikora (GRZ IT Group, AUT). Основная мысль - в том, что software занимает ключевые позиции в современном мире, как на уровне отдельных компаний, так и мира в целом. Из вспомогательной инфраструктуры он превратился в основную обеспечивающую. И поэтому его возможности и ограничения необходимо учитывать в "общем" управлении, которое от инфраструктуры обычно дистанциируется. Проблема в том, что софт - устроен довольно сложно, помимо возможностей имеет много ограничений, и чтобы все это учитывать - надо в этом хорошо разбираться. Что присуще далеко не всем топам. Возникают конфликты, между бизнесом и ИТ (или между CEO и CIO). Которые, независимо от результата, приводят к неполному использованию потенциала развития. И к том случае, если ИТ имеет неадекватно-подчиненное положение, и когда ИТ получает незаслуженно много привилегий относительно основного бизнеса. Тут была моделька с матрицей 3х3 формальная (организационная) позиция против внутреннего влияния, адекватной диагональю и разбором конфликтов.

Естественно, в докладе было про современные вызовы ИТ, но там ничего нового: privacy, security, transparancy for private life in internet era. Особая сложность в том, что по всем этим вопросам нет и не может быть общего мнения, хотя требуются общие решения - because of culture politics and other differences - but internet is global worldwide.

What is drastically wrong with most software engineering modeling languages and approaches, and 10 necessary principles for a really good modeling language. Tom Gilb (Result Planning Limited, Kolbotn, NOR). Мэтр, 1940 года рождения, работал в IBM, с 1960 - независимый консультант. И сейчас вместе с сыном продвигает свою модель, детали можно посмотреть у него на сайте http://www.gilb.com/.

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

У него есть идеи собственный подход, который отвечает всем этим требованиям. Там есть язык Planguage и ряд других составляющих ведения проекта. Но этого он в выступлении не рассказывал - это есть у него на сайте и в материалах. На русском можно немного посмотреть здесь. А в реализации он предлагает использовать ROC architecture model, о которой я писал в начала отчета.

Measuring And Implementing Sustainable Business Practices For Competitive Advantage. Ralph Jocham (Effective agile. GmbH, Munsingen, CHE). О том, что Scrum не делает организацию гибкой, Agile, автоматически. Возникает Water-Scrum-Fall, в которой Scrum служит формой для жесткой конструкции. И дальше - идеи про гибкость, которая дает реальные преимущества, со слайдами о том, что agile more successfull then waterfall.

Dealing with Technical Debt in Agile Development Projects. Harry Sneed (ANECON GmbH, Wien, AUT) Доклад был в академическом стиле, со слайдоментами. Вообще технический долг - плата за быструю поставку. За костыли, с которыми быстрее. Он связывает его с Agile, но я бы так не рассматривал. И приводит две причины: Incompleteness and Sloppiness с длинным списком примеров и категорий.

И как выход предлагает некоторый контракт с командой по уровню качества и скорости... По-моему, формально оно не сработает.

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

The Top Reasons Why Applications are slow or fail. Wolfgang Gottesheim (Compuware GmbH). Сообщение доклада непонятно. Просто набор причин, по которым может быть медленно, при этом большинство, по мысли автора, не должно быть - ибо известные грабли. Может быть, смысл доклада - просто дать список? Но примеры - чудесны! Пример сайта, где дофига JS - 1.7М против 800К картинок и копеек основного контента. А основной объем JS - документирующие комментарии! Или утечек памяти в самописном фреймворке логгирования. Но местами быстро уходят в технику, настройки JVM и БД.

Challenges and Solutions in Global Requirements Engineering. Klaus Schmid (University of Hildeshiem, Hildesheim, DEU). Хотя в докладе был подзаголовок literature survey, обзора как такового я не услышал, были размышления на тему про разные аспекты глобализации и кросскультурных взаимодействий: и внутри команды разработки, и между разработчиками и заказчиками при аутсорсе в другую страну, и просто между пользователями одного софта в разных странах мира, где один бизнес устроен по-разному. Например, автозаправка - в одних странах самообслуживание, на других - мальчики бегают. И софт должен нормально работать в обоих случаях, обеспечивая отпуск и оплату бензина. И это культура, а не только язык, у UK и New Zeland язык один, а культура сильно разная, потому как разная история и размеры страны.

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

What is model-based testing all about - the quest for simplicity. Dragan Pazin (ComTrade d.o.o, Ljubljana, SVN). Доклад про разные уровни эмуляции внешних систем: mock - emulation - production emulation - production в процессе тестирования. На нескольких практических кейсах, с техническими подробностями.

Improving Quality using Personas and the Product Canvas style of a Product Backlog. Matti Hjelm (SmartBear Software AB, Stockholm, SWE). Для начала был доклад о том, что графики исполнения проекта дают не дают понимания о продвижении к цели, особенно для тех, кто вне контекста проекта. Поэтому предложена доска с некоторой стандартной разметкой, которая не только дает представление о ходе, но и помогает этот контекст быстро поднять.

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

Agile testing – tips & tricks. David Janota (CN Resources International (CZ), AUT). Вещи частично правильные, частично экстремисткие, но все - очевидные. В целом доклад - про этап перестройки от ситуации, когда тестеры сидели отдельно и были отгорожены от остальных организационной стеной, и на этом этапе экстремизм уместен, чтобы преодолеть инерцию старого.

Pragmatic agile model driven development using smart use cases. Sander Hoogendoorn (Capgemini, Utrecht, NLD). Начиналось с того, что подход usecase отличается от userstory и лучше подходит для моделирования. Потому что можно сделать модель в простых диаграммах - диаграмма классов, диаграмма usecase. И далее модель, во-первых, используется для оценивания, а, во-вторых - в генерации на их основе приложения, включая интерфейсы для типовых usecase. Схемки рисуются в Enterprise Architect или Visual Studio, говорит, что по его опыту EA предпочтительнее, особенно в части описания генерации кода. Для оценки и представления как dashboard используется Speedbird9.com.

С моей точки зрения, идея - понятная, хотя не слишком интересная в том объеме, в котором изложена. Потому что то, что было показано - это совсем простые действия с объектами, по-мсути, CRUD-приложения. А диаграммы usecase использовались просто для описания прав. А такие приложения легко делаются любым способом, и довольно хорошо автоматизированы. Во всех компаниях, где такой работы много - она поставлена на поток и уже давно. А интересно делать сложные приложения - эта тема не раскрыта. Хотя один шаг тут напрашивается просто сам собой - добавляем объектам состояния, используем для них диаграмму переходов - и будет существенное увеличение мощности модели. Но все равно она останется тривиальной.

Secure your Software with Source Code Analysis. Steve Howard (AUT) Рассказ про плугин klocwork для Eclipse и IntelliJ IDEA статического анализа кода, который выполняет анализ на лету, в процессе редактирования, а не на этапе компиляции - и потому позволяет раньше обнаруживать ошибки и так далее. Профит понятный, но слишком абстрактный. Было бы интересно еще содержательный рассказ, что именно появляется, относительно работы без этого плугина - потому что обе среды, особенно IDEA, содержат весьма навороченные редакторы, также осуществляющие анализ кода на лету.

Isolated Testing of Software Components in Distributed Software Systems. Francois Thillen (LYCEE PRIVE EMILE METZ, Junglinster, LUX). Доклад про тестирование распределенной системы управления электрикой. При этом многие процессы проходят насквозь через несколько компонентов. Традиционные пути - эмуляторы (моки) для компонент и изолированное тестирование, либо комплексное тестирование со всеми запущенными компонентами - им не очень подходили, первый - потому что много эмуляторов, а второй - потому что сложно запускать, а еще - сложно локализовывать ошибку. Вместо этого они написали свой специализированный эмулятор сетевого протокола, через который все системы взаимодействуют, и с его использованием делают тесты, тестируя компоненты независимо, но без эмуляторов.

How to Improve Requirements Elicitation by LEGO™ Bricks (Literally)? Stefan Holtel (brightONE GmbH, Munich, DEU). Неожиданный доклад. О том, что для создания визуальных образов и метафор можно использовать модельки из LEGO, которые ты собираешь, а потом - презентуешь и объясняешь. Отчасти это похоже на известные приемы - нарисовать карту или нарисовать человечка, но использование LEGO тут дает достаточно необычную окраску. Во-первых, потому что собираешь руками, и при этом можешь легко переделать. Во-вторых, элементы достаточно примитивные, и это хорошо - можно состредоточиваться на сути, а не на красоте рисования. Ну и непривычно это - то есть лучше расшатывает мозги. Что, собственно, и нужно при придумывании метафор. Кстати, в ходе рассказа автор давал модельки нескольким участникам, правда не собирать, а интерпретировать - чтобы почувствовали метод.

И, говорит, можно так с требованиями работать. Только подробности не рассказывает - ссылки на статьи и выступления. А презентации его на сайте нет, так что искать надо (и быстро у меня не получилось).

Coaching improvements in Requirements Engineering Step-by-Step Mr Deming was right, Plan, Do, Study, Act. Colin Hood (Colin Hood Systems Engineering Ltd, Northampton, GBR) Докладчик - автор нескольких книг по требования, например этой. Но доклад был про другое, про изменения мелкими шагами. При этом стандартный цикл Шухарта-Деминга Plan-Do-Check-Act он преобразовал в Plan-Do-Study-Act, и на шаге Act выполняется улучшение по результатам Study. Преврашщая цикл в спираль развития. А основная мысль - когда люди готовы к изменениям - надо поддержать их обучением. Что, в общем, воспринимается как тривиальная вещь.

Performance Testing: Respect the Difference. Alexander Podelko (Oracle, Stamford, USA) В докладе не было какой-то методологии, просто длинный список пунктов, о которых надо думать когда говоришь о производительности. Включая конкурентную работу. А так - стандартный цикл, тестирования и оптимизации и методы анализа - как непосредственно по тесту, так и через анализ логов сервера, что позволяет детальнее разобраться в задержках.

Works on my machine, your problem now? – Improving Collaboration between Dev, Test and Ops. Wolfgang Gottesheim (Compuware GmbH). Для начала была некоторая проводка по тулам работы с логами и мониторингом - куда смотреть, на что обращать внимание. А потом разговор переключился на совместную работу Dev и Ops. И фокусом на автоматизацию тестирования, в том числе - по производительности. А закончил все на оптимистичной ноте "Проводите выходные с друзьями за пивом вместо пиццы с коллегами на работе" :)

---

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— MaksTsepkov • 18:56, 9 февраля 2014 • нет комментариев