Короткая ссылка: SQAdays-15-mtsepkov

18-19.04.2014 в Москве прошла 15-я конференция SQAdays. Отрадно отметить, что конференция развивается. На ней стало больше технических докладов. А еще повысилось качество: докладчики понимают, что рассказываемые кейсы и методы работы — одни из возможных в отрасли, и пробуют их позиционировать. И это следствие работы программного комитета, который не только отбирает доклады, но и работает с докладчиками над кристаллизацией, выявлением смыслов. При этом конференция не уходит в мероприятие для продвинутых тестировщиков, она оправдывает свой девиз «SQAdays — точка роста твоей карьеры». Что особенно важно в условиях отсутствия систематического образования. Есть тренинги, но они — по конкретным вопросам, и чтобы на них пойти, надо уже представлять свои потребности.

А конференция представляет спектр отрасли. Причем не только на теоретическом уровне общих рассуждений — этих материалов как раз много в инете (хотя качество очень относительно) — но и в виде рассказа о конкретных кейсах и практиках в разных проектах.

О спектре отрасли и трендах

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

Ничего удивительного, что в этих условиях и организация процесса разработки и, как следствие, организация тестирования очень различается в разных компаниях. Есть традиционная разработка, организация которой восходит к организации научно-проектных работ, оставшейся с эры больших компьютеров. Есть классическое функциональное деление по отделам. Есть feature-team — команды, которые полностью реализуют фичи или отвечают за компоненты продукта и которые могут быть кросс-функциональными или со специализацией внутри. И, надо отметить, что это не просто способы работ, за каждым из них лежат определенные ценностные конструкции. А кроме чистых видов — есть еще различные комбинации всего этого, эффективные с точки зрения организации проектов, но эклектичные с точки зрения совмещения ценностных конструкций. И в этих условиях не только новичку, но и опытному сотруднику, работающим в одной компании, очень полезно представлять весь спектр возможностей и вариантов, которые предоставляет отрасль, чтобы осознанно позиционировать себя в этом мире.

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

Заметим, что теоретически такого разнообразия быть не должно: в конкурентном рынке появляющиеся новые способы работы должны, в случае успеха, вытеснять старые, а при неуспехе — отбрасываться. Однако, ИТ-рынок развивается настолько быстро, что это просто не успевает происходить. Новые формы организации апробируются в новых сегментах, где идет конкуренция идей, конкуренция продуктивности, а не эффективности (по Адизесу), в то время как в сложившихся сегментах сохраняются ранее апробированные формы, несмотря на их недостатки, — они работают, а замена может обуславливаться только конкурентной борьбой, а не просто стремлением к совершенству. Кстати, это не означает, что в этих сегментах — застой, потому что конкуренция между компаниями и там идет, просто преимущественно в рамках сложившихся форм. Потому что их изменение требует изменения компании на ценностном уровне, а такие изменения всегда несут риск существования самой компании.

Кроме того, сама отрасль разнородна по своим потребностям, а для разных проектов эффективны разные формы. Ряд inhouse и enterprise проектов до сих работают в режиме, характерном для создания опытных образцов, а не промышленного производства: когда тестирование и внесение изменений идет на промышленном сервере. В твиттер-ленте конференции самым популярным стал твит про недоуменный вопрос одного из разработчиков инхауза одного топового банка «а зачем тестовая база, когда можно проверить изменения прямо на проме?».

Достаточно много организаций по-прежнему могут себе позволить годовые релизы, а это обеспечивается хорошим планированием при функциональном делении организации. Хотя Microsoft уже не может себе этого позволить, а переход к квартальным релизам потребовал от него кардинальной перестройки внутренних технологий разработки, перехода к Agile. Кроме того, рынок специалистов при использовании традиционных подходов тоже оказывается ограниченным, и для Microsoft это тоже могло оказаться важным фактором — им приходится конкурировать со стартапами за топовый персонал. Собственно, основное отличие современных форм разработки — это высокая адаптивность и способность к частым релизам в режиме выпуска изделий промышленного качества. И как только эти требования возникают, отказ от традиционных форм — неизбежен. Что создает общее давление развития на все сегменты отрасли, — есть.

А еще происходят сдвижки рынка, когда в сегмент, ранее занятый более традиционными компаниями, по тем или иным причинам приходят игроки с новых сегментов рынка и присущей им новой, динамичной организацией компании. Сейчас такой процесс идет в гос. секторе. На SQAdays было несколько докладов о тестировании софта, заказываемого или разрабатываемого для государственных организаций. Оно выносится на аутсорсинг, и с ним приходит представление о современной технологии работы: с системой ведения дел, прозрачно для заказчика, быстро. И дальше подрядчики окажутся перед необходимостью соответствовать требованиям такого независимого тестирования. Другая сдвижка в этой же области, о которой, правда, я услышал несколько раньше, на SECON в Пензе, — переход от заказной разработки к Open Source-решениям. Решение для системы одного окна, разработанное и внедренное в Пензенской области, выложено в Open Source для свободного использования. А разработчики рассчитывают на востребованность доработок на внедрении, которое закажут им просто потому, что это выгоднее, чем растить свою команду. И рассчитывают, что решение будет востребовано потому, что оно существенно дешевле в сопровождении, чем большинство существующих закрытых вендорских решений. Фактически, оно вообще может выполняться собственными силами — исходный код доступен. Посмотрим, насколько оправдаются их надежды в этом случае, но, в любом случае, это существенный сдвиг в парадигме работы с государством.

Доклады

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

Сергей Михалев. VIAcode. Подход доктора Хауса в тестировании оптимизации запросов. Хороший доклад об оптимизации SQL как о балансе между скоростью чтения и изменения. С кейсами и подходами поиска этого баланса. И с оригинальной формой подачи, которая видна уже из названия.
Михаил Курышкин. Перфоманс-Лаб. Организация тестирования системы на основе смарт-карт. На этом докладе я понял, что еще один тренд современного тестирования — сильное включение аппаратной части, так что можно говорить о тестировании аппаратно-программных комплексов, а не просто тестировании софта. Кстати, возникает это не только при работе с конечными устройствами — тестирование надежности и производительности высоконагруженных круглосуточных сервисов и организация их мониторинга тоже по сути является тестированием АПК.
Инна Смирнова. Рексофт. Исследование багов: учимся у Шерлока Холмса! Доклад для новичков, и по содержанию он не принципиально отличается от аналогичных: рассказывают очень правильные и актуальные вещи. Но форма подачи — хороша.
Alexey Lyanguzov. Grid Dynamics. Успешный тестировщик. Путь профессионала. Хороший доклад про профессионализм и, главное, ценности в своей работе, то, что можно объединить в одно слово — «самореализация», а можно — раскрыть по пунктам. И, собственно, для осознанной самореализации как раз надо эти пункты представлять. Конечно, у разных людей они могут различаться, но доклад в любом случае хорош как начальная точка работы над собой. Вообще в вопросах к докладу прозвучал голос скептика: «все это хорошо звучит, но мир-то не белый и пушистый, он — серый, так что все это не слишком применимо, как думаете?». Алексей ответил в духе «надо стремиться», а у меня есть более четкий ответ: «Да, мир серый, и Вы не можете быть белыми пушистым. И раз так — давайте поставим свою серость под собственное управление, решим для себя, в каких областях я серый, насколько и почему». Эту позицию не обязательно озвучивать, это вообще зависит от окружения, но вот выработать для себя — полезно.
Даниил Подойницын. Ventra Москва. Способы расширения зоны влияния вашей системы автотестов. Доклад о том, как с помощью костылей расширять область автоматических тестов. Костыли — так докладчик их назвал. А на самом деле, большинство представленного — никакие не костыли, а легкие и уместные решения. Просто не модные и не считаемые «достойными», высокотехнологичными. Правда, ну нет же технологии в том, чтобы организовать обмен через текстовый файл, который парсишь подручными утилитами. А дальше происходит парадоксальная вещь: это решение не рассматривают вообще, либо заменяя дорогим, либо оставляя в этом месте ручное тестирование. Спрашивается — зачем? Но вообще легкие решения упоминались во многих докладах, при этом там есть свои особенности, при которых авторы прорывались при создании, как и Данила, так что эти доклады не просто дают сообщение, что так можно, а передают опыт.
Роман Иовлев. I-Free Санкт-Петербург. VIQA — Тестирование UI с помощью виртуального интеллекта. Рассказ про обертку над Selenium на C#, которую они написали из-за особенностей тестируемого сайта, когда функциональные элементы (типа кнопок) имеют в HTML нестандартную визуальную реализацию. Хороший рассказ про проект, с раскрытием внутренней логики решений и архитектуры. И да, они понимают, почему это сделали и чем их не устраивали готовые обертки.
Игорь Бондаренко. Intetics Co. Минск. Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества. Довольно интересный рассказ о том, как мутирует Agile-процесс (начинали со Scrum) в ходе адаптации под особенности проекта. Мутирует он в сторону большего усложнения, а не упрощения, с включением практик из более традиционных процессов, но сохраняя дух целесообразности. При этом автор понимает, что и почему происходит, процесс идет сознательно — и в докладе это показано.
Антон Семенченко. ISSoft / CoherentSolutions Минск. Как эффективно организовать Автоматизацию, если у вас недостаточно времени, ресурсов и денег. Рассказ о том, что находится за пределами стандартно рассматриваемого процесса разработки и работы с требованиями, которыми занимаются Delivery Team и Value Team. А находится там работа с сотрудниками, повышение их квалификации: курсы и тренинги. При этом, оказывается, что при умелой организации можно в качестве предмета тренинга давать реальные проектные задачи, которые успешно решаются. Чем превращать внутренние тренинги в коммерчески оправданное мероприятие. Правда, детальная механика такой работы в докладе не раскрыта. Жаль. Потому что это ж наверняка не просто «взял и сделал», было бы просто — все бы так поступали.
Natalya Rukol. Quality Lab. Миссия тест-менеджера. Наташа начала с того, что доклад будет не про решения, а про проблемы, которые для нее открыты. Но выдержать эту рамку не смогла: хотя доклад был полон проблемных моментов, там же было и множество решений, основанных на вовлеченности и энергетике. Хороший доклад, жаль что короткий. И я знаю, что хотел бы услышать: про те хинты и приемчики, которые помогают все это делать помимо личной энергетики. Я знаю, что без энергетики — никуда, и чаще всего не хватает именно ее. Но наверняка за много лет работы наработаны и приемы, которые помогают все это делать. И о них тоже хочется услышать.
Сергей Мартыненко. Стратегии тестирования. 42 способа сделать ваш проект успешнее. Наверное, у каждого в вузе были опытные профессора, которые плохо рассказывали свой предмет. Сергей много знает, рассказывал сложные вещи, но, к сожалению, приоткрывая мозаику, много отвлекаясь в стороны, а не давал цельную картину. Хотя среди мозаики проскальзывают весьма интересные вещи. Все-таки жаль, что скилл докладчика он, по-видимому, считает недостаточно ценным, чтобы вкладываться в его прокачку.
Yury Kupriyanov. WikiVote! Легковесный фреймворк для оценки качества на основе подхода SEMAT. Юра рассказывал про SEMAT и его назначение. Это сложно, потому что SEMAT сам по себе не простая конструкция, и хотя создатели поработали над снижением порога входа, рассказать за полчаса для неподготовленного слушателя — тяжело. Так что — как получилось. В конце из зала был вопрос про соотношение SEMAT и CMMI — потому что многие слова на карточках были слушателю знакомы. Тут есть два ответа. Во-первых, SEMAT включает три составляющие мира: объект — софт, который мы делаем, процессы и людей, команды. А CMMI — он только про процессы, которые представляют лишь треть этого мира, причем обеспечивающую; целью все-таки является именно создание софта, а не процессы. А во-вторых, CMMI жестко диктует, как сделать, а SEMAT свои карточки дает лишь как начальную точку, почти Sample, от которого можно двигаться в любую сторону, в соответствии с особенностями вашей компании и ее проектов. Что, собственно, и составляет ценность SEMAT в нынешнем разнообразном мире ИТ-разработки.
Алексей Баранцев. Software-Testing.Ru. Тестирование на основе моделей: «ужас-ужас» или всё не так страшно? Алексей рассказывал про построение тестов на основе модели перехода между состояниями: вместо линейных сценариев вы описываете узлы переходов по состояниям, а система сама строит граф сценариев тестирования. Модель интересная. Правда, у меня вызвал недоумение тот уровень детальности и постепенности, с которым Алексей представлял модель, но я подумал, что Алексей лучше знает аудиторию из своего опыта проведения обучения. Правда, если уровень таков, то у меня возникает некоторая печаль. Ну, что поделать…
И мой доклад. Вернее, наш: Максим Цепков, Андрей Мясников, Рина Ужевко «Вы и Заказчик: решаем проблемы, а не отрабатываем требования». Он был последним на конференции, и из-за этого я не услышал доклад Майкла Болтона — он шел параллельно. Это был довольно смелый эксперимент: мы втроем попытались показать на кейсах работу с заказчиком из позиции сотрудничества. При том, что опыт у нас троих сильно разный: заказная разработка, продуктовая и игры. Была идея, что попытка положить столь разные кейсы в некоторую общую картину поможет выявить общее и донести идеи до слушателей. Вроде оно получилось, и опыт оказался удачным.

На этом завершаю свой рассказ о конференции. Другие отчеты можно посмотреть через оглавление блога

Репликация: База Знаний «Заказных Информ Систем» → «Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

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

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

— Sergey Martynenko • 23 апреля 2014 в 10:46