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

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

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

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

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

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

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

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

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

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

Доклады

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

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


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

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