2017-12-03: SQAdays - в тестировании не происходит ничего нового...
Две недели назад 17-18.11 в Петербурге прошел SQAdays-22. И, собственно, я хотел назвать свой отчет о конференции «зрелая конференция зрелой отрасли», но потом заглянул в свой отчет о прошлой конференции — и обнаружил, что он примерно так и называется, в то время как впечатления — сильно разные. И тогда я решил вынести в название цитату из выступления Рины Ужевко на открытии — о том, что «в тестировании не происходит ничего нового». Эта реплика была адресована участником конференции, с призывом подавать доклады и не стесняться своего относительно скромного опыта: все равно ничего принципиально нового не происходит, поэтому ваш рассказ — уместен на конференции.
Мне же это резануло слух и я написал реплику на FB: «Каждый раз, когда это говорят про какую-то область деятельности — область или умирает или это затишье перед взрывным ростом. Так было, например, с языками — в какой-то момент казалось, что все языки уже разработаны, все известно, а потом произошел взрыв новых языков с новыми парадигмами… Думаю, так будет и с тестированием — оно накануне взрыва технологий для тестирования обучающихся систем, например, автоводителей; и автоматизации, в которой автотесты пишут роботы — но этих роботов обучают люди; и в других направлениях. В каких именно выстрелит первым — я не знаю, но многие направления потенциального развития — понятны.» В комментариях Рина и Влад Орликов согласились с этим. Развитие новых векторов пока идет в отдельных точках, и накапливается критическая масса, которая породит бурный поток. Но пока — затишье. И да, возможность для всех поделиться своим опытом.
На конференции обмен опытом шел интенсивно, и не только в залах: в большом фойе были мини-выступления от gett.com, которые приехали на конференцию большой командой сильных специалистов, организовали мини-островок в холле, при этом звали выступать на нем не только своих специалистов, но и других. Выступления были сильными, интересными и краткими. А напротив них в близком формате выступал СКБ-Контур.
А в целом энергетика конференции была не столь сильной. Новички — учились, а опытным было многое известно, они не ждали ничего нового. И баркемпы не особо увлекали народ. Впрочем, когда вбрасывалась сильная тема, то народ оживлялся, это замечательно показал Леша Федоров. Он, кстати, излагал мое выступление на IT Global Meetup (мой отчет), и когда из аудитории начали идти вопросы — призвал меня к ответу на фото справа можно это обсуждение увидеть.
Но, с другой стороны, все этом может быть и случайностью, или просто связано с осенним настроением. Потому что за полгода ничего принципиально измениться не могло, а вот мои ощущения от конференции — разные. В пользу ситуативной разницы говорит еще одно наблюдение.
Круглый стол о тест-менеджменте
На этой конференции, как и на прошлой был круглый стол «ТЕСТ-менеджмент или тест-МЕНЕДЖМЕНТ». И вот на прошлой я обратил внимание на разницу позиции участников на сцене, которые достаточно хорошо различали менеджмент и лидерство, и еще техническое лидерство, в отличии от большинства участников из зала, для которых все это — синонимы. В здесь зал был не столь активен, зато в дискуссии выступающих я явно опознал очень старую тему — из кого получается лучший руководитель, из предметника или менеджера общего профиля. И быстро написал об этом в FB.
Александр Александров на круглом столе. Есть много вопросов в IT, на которые гуру менеджмента стандартно отвечают «it depends». В Советском Союзе эта западная модель менеджмента была реализована в партии: инструкторы райкомов — такие менеджеры. И потому возникает вопрос, насколько эта модель менеджмента, собственно, применима в IT.С моей точки зрения, ответ на этот вопрос известен: не применима. Потому что классический менеджмент умеет организовывать физический труд, а труд в IT — умственный. Современный менеджмент не умеет организовывать умственный труд, это признавал такой классик, как Питер Друкер, говоря о вызовах менеджмента 21 века. А в IT это хорошо сформулировал Том ДеМарко в PeopleWare.
Но вообще это спор 19 века двух школ менеджмента — английской и немецкой. Англичане растили менеджеров из джентльменов, без профессионального образования, и полагали, что джентльмен может управлять чем угодно. И эту модель восприняли американцы, школа MBA — продолжение этого. А в Германии руководители росли из профессионалов, и эту же модель восприняла Россия, и потом Советский Союз…
Леша Федоров, который модерировал обсуждение, кстати, тоже опознал эту тему и подволя итоги круглого стола как раз сказал, что тема — очень старая, спор о двух моделях менеджмента, где победителей не видно. А значит, если уж ее обсуждать, то от специалистов ожидаешь и знакомство с историей, и различие между общей рамкой и отраслевой спецификой. И, думаю, для участников это тоже было бы полезно для расширения кругозора.
А еще я очень четко увидел коннотации со Спиральной динамикой пост: «А в целом круглый стол интересно слушать, понимая модель Спиральной динамике. Очень сильно видны сине-оранжевые процессные позиции, или оранжево-зеленые позиции сильного командообразования. Они дают разные ответы на те же вопросы. И к основной теме дискуссии тоже отношения в этой же логике, сине-оранжевые выступают за акцент на профессиональные компетенции тестера, а оранжево-зеленые — на менеджерские. И по отношению к конфликтам. И по отношению к продажам качества менеджерам, заказчикам и руководству. И при этом ты смотришь на это с желтой позиции teal-организаций, где решение конфликтов и разногласий — рабочая ситуация и выполняется не через приход к согласию, а из позиции личной ответственности. И много других решений тоже проработано.»
Еще заметка И в продолжение двух предыдущих постов. Основной вопрос круглого стола — что лучше, ТЕСТ-менеджер или тест-МЕНЕДЖЕР, то есть что важнее — профессиональные компетенции или менеджерские, тоже имеет ответ с позиции желтого уровня Спиральной динамики, но он — сложный. А именно, будущее — за мультифкункциональными, а не специализированными командами. В которых фокусы профессионального управления, менеджмента, и другие — разнесены между разными людьми. И, более того, реализуются за счет разных организованностей, например, через участие в профессиональных сообществах. Но одновременно с этим, определенная часть soft skill, которые сейчас — прерогатива менеджера — становятся практически обязательной для любого сотрудника, тем гигиеническим уровнем, который люди будут получать в раннем возрасте, осваивая коммуникацию в соцсетях.
Но, повторюсь, на прошлой конференции всех этих мыслей у меня не возникло. Обсуждение было другим, хотя на сцене были те же люди. Потому что был другой состав участников, а может просто обсуждение было по-другому выстроено…
Обзор докладов
Для начала — пара слов про мой доклад, а потом я просто воспроизведу те посты, которые публиковал во время конференции, фиксируя наиболее важное в докладах.
У меня на этот раз был блиц Тестировщик и DevOps: позволяют ли интерфейсы системы эффективно решать инциденты? (SQAdays-22 2017-11). Я делился опытом о том, что должна позволять система для того, чтобы служба сопровождения могла эффективно решать инциденты, то есть не просто фиксировать ошибки, а обеспечивать исполнение бизнес-процесса, несмотря на них. Потому что, собственно, именно в этом и состоит задача IT — поддерживать бизнес. У нас в компании это всегда было фокусом и есть позитивный опыт, которым я и делился. И при этом еще надо найти достаточно дешевые решения, реализация которых будет оправдана, несмотря на фокус на минимальную быструю реализацию функционала. Отмечу, что тема для меня новая, этот опыт я отрефлексировал и рассказывал впервые. Получилось удачно, после доклада — были еще вопросы в кулуарах.
И про остальные доклады, на которых я был.
Пост на FB Галина Вострикова «Как не потерять важное при передаче проекта». Очень правильная и личная постановка задачи из фокуса личной ответственности за свое дело: передать проект нужно не потому, что регламентами положено, а потому что пока не передал — старый проект не отпускает, за него беспокоишься — не разрываешься между старым и новым проектом. И хорошее содержание — как передавать и что именно. Может быть, излишне перфекционисткое — но тут жизнь сама скорректирует. Зато по докладу можно сделать готовый checklist.
Пост на FB Галина Вострикова. Забавная история. Тестовый стенд первого релиза у заказчика стал боевым, и когда решили отгрузить второй релиз по старым настройкам — только ограничения на боевой стенд по правам не позволило это сделать :) И в докладе много таких историй!
Пост на FB Николай Миронцев. Нагрузочное тестирование. Реальная история про тестирование нагрузки на 100к одновременных пользователей, и связанные с этим особенности, например, что современные броузеры открывают 5-20 соединений на одного пользователя, что в зависимости от типа запроса — время отдачи разное, что надо проверять получение с сервера сss, js и картинок, а не только данных — иначе пользователи под нагрузкой будут получать уродливые страницы, а вы этого не заметите. И еще — надо представлять результаты на языке заказчика, в пользователях, а не соединениях и сценариях.
Пост на FB Игорь Голдшмидт (Igor Goldshmidt) из Gett. Истинная сила тестировщика — информация. Круто! Рассказ о том, что правильный тестировщик должен не просто проверять систему — он должен хорошо знать продукт, представлять технологии, чтобы разговаривать командой на одном языке, получать информацию не только из доков, но и из коммуникаций — и вести свою базу информации в вики, а не блокнотах и даже не в googledocs. Agile: никто ничего не записывает, поэтому пишите сами. Если у вас записывают — расскажите, как приучили. А еще интересна подача — коучинг тестировщика, представленного персонажем. Немного сумбурно, но все равно — хорошо.
Пост на FB Игорь Голдшмидт (Igor Goldshmidt) — советы. Прикольная форма, но очень по делу, правильные паттерны поведения. Ушки на макушке: open space, когда программисты переговариваются — надо снять наушники и слушать, там много интересного говорят. Не забывайте допрашивать менеджеров — они знают много интересного. Завязывайте связи с соседними командами, помогайте другим, делитесь с ними информацией.
Я хочу отметить, что этот пост неожиданно вызвал горячие обсуждения на FB. О том, что open space — это зло. О том, что слушать — это отвлекаться, а еще и не слишком корректно, и будут приводить к тому, что от таких слушателей явно будут уходить. О том, что так можно договориться до необходимости курить, потому что ведь там решается много важных вопросов (кстати, некоторые мои знакомые HR говорили, что курят именно поэтому). В общем, любопытно: вроде все согласны с тем, что полезно о проекте знать как можно больше, но почему-то явные советы по выяснению информации вызывают такую реакцию. Кстати, это был один из двух топовых докладов на конференции, вместе с докладом Андрея Мясникова, и советов там было много, так что смотрите видео, когда появится.
Пост на FB Алексей Вихров. Велосипедизация, или всегда ли хороши стандартные решения — о том, что как альтернативу готовому решению из коробки, которое ты конфигурируешь можно достаточно легко из компонентов и библиотек собрать легкое решение под ваш конкретный кейс. На паре конкретных примеров. Это особенно актуально, когда задача несколько нестандартна, и с готовым решением нужны танцы с бубном, например, по интеграции в свою инфраструктуру.
Пост на FB Mitko Mitev. Software Disasters — рассказ о фейлах благодаря отказам софта из-за багов. История с фейлом климатических исследований Марса, потому что в интеграции одна система исспользовала английскую систему мер, а другая — метрическую, при этом единицы не передавались. Радиационная терапия, в которой пациенты получали дозу, в 100 раз превышающую терапевтическую. Отключение электиричества, биржевые коллапсы из-за роботов. AppleMaps, сгинувший в никуда. Pepsi — в промоакции оказалось много больше победителей, чем рассчитывали — невыплаченные призы и криминальные последствия, потому что призовые бутылки перепродавали… Ошибка в системе checkin Amadeus — 125 рейсов блокированы. И многое другое.
В общем-то история фейлов — старая, тянется со времен появления компьютеров в 1960-х. И механизм тоже давно известен, есть статья Ривза (Reeves) 1992 года, где показано, что разработка софта, включая написание кода — НИОКР, а не производство, а результаты НИОКР — не гарантированы. Зато переделка, исправление ошибок — дешевое. А вот исчерпывающее тестирование дорогое. А дальше — легко увидеть последствия. В этих условиях безопасность софта неизбежно будет в проигрыше и те, кто тестирует софт тщательно никогда не смогут выиграть гонку в бизнесе — и исчезнут здесь и сейчас гарантировано, а не может быть и потом. А потому все находятся в ситуации «рискуй или проиграешь».
А докладчик после столь впечатляющего вступления о фейлах перешел к изменениям роли QA в DevOps, но ответов на все проблемы не показал от слова совсем…
Пост на FB Vojtech Barta рассказывает про mindmap. Не про инструмент как таковой, а про уместное использование его тестировщиками, с конкретными примерами mind maps для разных целей. А также о том, для чего mindmap подходят плохо и надо использвоать другие средства. Не хватает критериев, как определить — для чего подходит, а для чего — нет. Но, может, автор это выясняет всегда опытным путем…
Пост на FB Клевый доклад Андрей Мясников: заведите вредные привычки. Отмазки для сотрудников, которые накосячили — ругайте их вы, а перед руководством прикрывайте. Не обязательность — если план требует много переработок, то надо его менять, а не выполнять. Отрицание — умейте отказать в переработке, потому что они имеют тенденцию не кончаться. Используйте МОПС: процесс мотивация-обучение-проверка-самоконтроль чтобы научить сотрудников новому. И ряд других «вредных» привычек. Но не все вредные привычки полезны. Микроменеджмент, болтливость, узость взгляда, эгоцентризм — не заводите. И все это еще с мини-стихами на слайдах :) Конечно, местами тут максимализм и отсутствуют оговорки, но и в жизни эти оговорки часто просто прикрывают вредные паттерны.
Вместе с докладом Игоря был одним из двух топовых на конференции. Премии не получил, как и доклад Игоря — ее давали новым докладчикам, а не мэтрам. Кто не видел — смотрите запись.
Пост на FB Karolina Zmitrowicz В Agile нет отдельной роли QM, она распределена между PO и командой. Зато есть две хорошие точки контроля качества — Definition of Ready (DoR) и Definition of Done) (DoD). Надо их использовать и дополнить Quality Strategy — описанием политики, исполнением которой мы рассчитываем обеспечить необходимое качество.
Пост на FB Aleksandra Kornecka, в начальном представлении, среди прочего — участие в Girls testers, помощь девушкам стать тестировщицами. Это послужило стартовой точкой размышлений. Все это — сильно западная история, и она показывает, что никакого ментального равенства полов у них есть, несмотря на вековое движение феминизма. Потому что равенство — оно же в равенстве возможностей, в том, что при приеме на работу и в целом в профессиональной среде смотрят на профессиональные навыки, а не на пол. А вовсе не в достижении статистического равенства во всех профессиях, потому что профессии — разные, и предъявляют разные требования. В Советском Союзе этот путь был реально пройден в 30-е. И не только в европейской части, в Средней Азии — тоже, и пройден невозвратно. И тогда как раз были движения и группы поддержки женщин, их адаптации к самостоятельной жизни. Получается, что тут западный мир отстает от России, вернее, от Союза лет на 80 :) Что, впрочем, для меня не удивительно — в Испании еще 20 лет назад чтобы поехать в другой город женщине надо было иметь разрешение от мужчины — мужа или отца или старшего брата, и эти разрешения проверяла полиция :)
Пост на FB Алексей Анисимов. Как hh.ru дошли до 500 релизов в квартал без потери в качестве — практический доклад о пути, который hh шел от ручного тестирования и выкатки релизов к полному автомату — сборка, выкатка релиза, автотесты. Ряд инструментов делали сами, другие — обвязывали скриптами, чтобы сделать доступными для всех. Результат — 10+ релизов в день и сильно меньше багов на проме. И главный совет — сначала напишите соглашения — что есть сейчас, что будете делать, то есть наметьте путь. А потом — итерационно двигайтесь по ним. А по инструментам — обязательно смотрите, а при выборе — учитывайте компетенции разработчиков по языкам и технологиям. И обращайтесь к коллективному разуму — сайты и форумы, телеграмм-чаты… В презентации — ссылки.
А этот пост, с одной стороны, вызвал вопрос — зачем так много релизов? А с другой — обсуждения про качество самого HH как сервиса.
Пост на FB Екатерина Боброва «Готовим стажировку». Очень круто! А теоретические материалы у них выложены на youtube в публичный доступ, искать по «Thumbtack Лекции тестирования». Они объявляют стажировку за месяц и предлагают теорию изучить самостоятельно, и перед offline-практикой — сдать тест и собеседование. И это снизило затраты на обучение для них. И нанесло пользу обществу — теория стала бесплатно доступна всем.
Пост на FB Nina Scheglova «Куда приводят мечты? или Искусство развития тестировщика» — профессиональная организация роста сотрудников. Матрица компетенций, по ней — самооценка, оценка коллегой, которого ты выбираешь и тимлидом. Оценку коллеги делают на встрече, а не анонимно и, говорят, это помогает, а не мешает, необъективные оценки не дают, относятся правильно — потому что в любом случае обучение выявит проблемы. И дальше — выбор векторов развития, два в интересах отдела, один — по желанию сотрудника. Сравнение с идеальными профилями, программа развития и в путь, итерациями по 2-3 месяца с оценкой итогов и возможностью сменить направления движения. Матрицы тестировщика, дизайнера и программиста — опубликованы, в презентации ссылки. Матрицу для тимлида пока не сделали, это в планах.
Как обычно великолепный доклад Антона Семенченко «9 кругов Ада: антипаттерны UI-Автоматизации», в котором антипаттерны были связаны с крушами Данте, вызвал серию заметок. пост на FB Anton Semenchenko Переусложнение — болезнь senior. Классика жанра — junior выдает 10 тестов в то время как senoir 3 соразмерных, зато написано круто, душа развернулась!
Пост на FB Anton Semenchenko Если за дело берется «прости Господи Архитектор», то результат будет «оставь надежду, всяк сюда входящий».
Пост на FB И дальше по Данте: Круг второй — похоть, «Кто предал разум жажде вожделений» Это собственное велосипедостроительство, например, свой wrapper selenium. И дальше по всем кругам :)
В заключении хочу подчеркнуть, что я был только на одном треке из трех параллельных (хотя иногда и менял зал во время доклада). И часть докладов неизбежно осталась за пределами внимания. Уже на конференции я услышал хорошие отзывы про доклад Рины Ужевко, и про доклад Сергея Атрощенкова, который шел параллельно с моим. Наверняка есть и другие. Так что не полагайтесь только на этот отзыв.
И просто запомним историю
А еще в дни конференции FB напоминал про историю, и эти посты я тоже хочу запомнить.
пост на FB FB напоминает — пять лет назад Влад Орликов запускал SPMconf — конференцию для PM. Она так и не взлетела, прошло только пара конференций. Но первая — была интересна. Правда, портала SoftwarePeople, на котором я тогда вел блог, тоже не существует уже несколько лет, его закрыли вместе со всеми материалами. Но мой блог перенесен на мой сайт и доступен, этот пост — здесь Блог:Максима Цепкова/2012-11-17: SPMconf-2012 в Минске - день первый А вот конференция #sqadays, с которой Влад начинал - по прежнему живет, и прямо сейчас я слушаю доклады на 22, в Петербурге, а завтра еще и выступать буду. И #analystdays взлетела. И я очень благодарен Владислав Орликов за его организацию конференций, и, думаю, много тысяч участников, прошедших через эти конференции за много лет - тоже. Его конференции наносят большую пользу отрасли.
пост на FB О, FB как раз показал мой пост 4-летней давности о SQAdays во Львове, в комментариях к репосту которого в группе тестировщиков развернулась эпичная дискуссия на несколько сотен (!) коментов о назначении конференции. Это вот здесь Можно почитать, вспомнить и сравнить с нынешними представлениями. А это пост 4 года назад на FB и у меня в блоге
пост на FB Естественным образом FB в эти даты напоминает про прошлые #sqadays, о которых я пишу отчеты. Вчера было про конференцию во Львове 4 года назад, сегодня — про ту, что 3 года назад была в той же Питерской гостинице Прибалтийская, что и та, на которой я присутствую и буду выступать сегодня. И все так же на конференциях присутствует ядро, с которым общаешься из года в год, и много новых участников. Энергетика, наверное, несколько уменьшилась, но зато появилась форма баркемпов, которая стимулирует общение и позволяет этой энергии проявиться. Вчера были интересные обсуждения, и сегодня они продолжаться. И, пользуясь случаем, хочу дать совет новым участникам: если тема доклада вам близка и появились вопросы и мысли — ловите докладчиков в кулуарах и спрашивайте. Они — откликаются и охотно беседуют. И даже если чувствуете, что вопросам и мыслям еще надо созреть — все равно идите на общение. Во-первых, оно поможет кристаллизации мысли, а, во-вторых — легче будет продолжить общение после конференции — вы будете уже знакомы. Хотя написать незнакомому докладчику — тоже нормально, на это люди тож откликаются. Пост 3 года назад на FB и у меня в блоге
А в заключении — фото с конференции, в том числе — то, которое вынесено в пост. И фото второго дня. Ну а этот отчет на FB здесь.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.