С опозданием пишу отзыв о 20 конференции SQAdays, которая была в конце ноября в Минске. И вовсе не потому, что конференция мне не понравилась. Наоборот, было много хороших докладов и интенсивное, конструктивное общение. И мне хотелось написать обстоятельный отзыв, по горячим следам это не получилось, все время были другие дела, но наконец очередь дошла.
Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!
Общее впечатление - конференция за несколько лет повысила уровень докладов. На ней по-прежнему много докладов для новичков в профессии, что не удивительно - именно активные, растущие в профессии сотрудники составляют основную массу участников. Но наряду с этим в программе есть доклады для тех участников, которые в профессии несколько лет и уже имеют приличный уровень. И хорошо, что конференция следует за зрелостью профессии: по мере того как в индустрии становится все больше опытных профессионалов, увеличивается их число среди участников, и становится больше докладов, интересных для них.
Дальше будет немного про конференцию в целом, а потом - обзор докладов. И я сразу хочу сказать, что я не смог приехать на первый, международный день конференции. А во второй день после своего доклада я ушел на barcamp отвечать на вопросы, а остался там на следующие сессии. Так что много докладов я пропустил, и не стоит думать, что я расскажу про все хорошие доклады конференции. А начну я со своего.
Помимо инженерных, на конференции много докладов, касающихся управления и организации людей. Что естественно, поскольку успешные тестировщики становятся организаторами тестирования в той или иной роли: руководя группой, организуя работу начинающих, взаимодействуя с заказчиками и во многих других ролях. IT очень гибко подходит к распределению обязанностей, по факту, никаких стандартных профилях говорить нельзя, и хотя должности называются одинаково - разработчик, тестировщик, аналитик, руководитель проекта, границы ответственности и обязанностей между ними в разных компаниях различно. А уж организация управления проектами, разделение обязанностей между руководителями отдела и проекта, аккаунтами, HR, наставниками различается еще сильнее.
Тем не менее, в большинстве докладов по работе с сотрудниками можно выделить ряд положений, которые достаточно сильно отличают высказываемые позиции как от подходов традиционного менеджмента, так и от Agile-управления проектами. Именно поэтому я говорю о докладах по управлению и организации, не употребляя слова "менеджмент". Наиболее близко эта позиция, наверное, определяется словом "лидерство и коучинг", но при этом достаточно большая часть контекста относится к организации работы, взаимодействия с другими подразделениями, заказчиками, которые обычно находятся за рамками докладов по лидерству. Итак, тезисы.
Пожалуй, это основное. Эти позиции высказывались взвешено, как в великолепном докладе Алексея Петрова, или наоборот, провокационно-максималистски, как у Татьяны Синтиной. Оценка пассивного исполнителя как слабого сотрудника была у обоих. Но суть от этого ведь не меняется. Хотя восприятие доклада сильно разное, доклад Татьяны был сплошь заклеен отрицательными отзывами именно потому, что она четко формулировала необходимость активной позиции от сотрудника, в то время как Алексей говорил о выведении сотрудника в такую позицию. Может, в докладе Татьяны многие подсознательно узнали себя и это оказалось не слишком приятным? А может дело в том, что Татьяна делала упор на то, что ты сам должен занять активную позицию, а Алексей - на том, что руководитель должен к этому подталкивать. И оценки показывают, что люди любят, когда их подталкивают, и не любят развиваться самостоятельно.
А еще в ряде докладов была мысль о том, что каждая команда и каждый проект - индивидуальны и им нужен свой метод управления. И это - тоже черта времени.
Как я уже отметил, организация IT-проектов очень разнообразна. Поэтому не удивительно, что у многих профессионалов есть проблемы, по которым они не могут получить ответы в докладах. И на этой конференции организаторы попробовали расширить стандартный способ обсуждения таких проблем в частных разговорах, сделав barcamp - отдельную активность при которой ведущий задает тему и формат, а кейсы и вопросы для обсуждения предоставляют сами участники. Он шел два дня конференции довольно активно, конкурируя с докладами. Особенно интересной была длинная сессия обсуждений болей участников: люди рассказывали свои кейсы, и получали консультации от других участников. Так что я благодарен Алексею Федорову, энергия которого породила этот barcamp.
Я особо выделю доклад Ивана Евтуховича, потому что помимо технической части DevOps он нарисовал интересную картину будущего.
Это был очень хороший доклад в широкой рамке. Не просто про DevOps, а про тренд цифровизации, в результате которого IT становится главной технологией бизнеса:
Цифровые компании повернуты к потребителям своим софтом. А не людьми. Все компании становятся IT-компаниями, галвное для них - совершенствование и развитие софта. А значит они не могут работать на вендорских решениях. Надо работать на своем. А значит надо еще и забирать IT внутрь - иначе ты принадлежишь внешнему подрядчику.
И на этом фоне в 2008 появился DevOps. Ранее они были раздельны:
А надо сотрудничество, совместная ценность.
Автор термина DevOps - Patrick Debois. Agile Infrastructure, распространение Agile на инфраструктуру. По-русски книгу читать невозможно.
И дальше был достаточно подробный обзор инструментов, которые это поддерживают. Поскольку направление развивается быстро, то и инструментальный ландшафт сильно меняется. Не только по удобству, но и по подходам, и достаточно частая ситуация, когда есть несколько поколений инструментов, более старшие - стабильнее и удобнее, зато у новых - новые подходы, которые позволяют сделать невозможные в старых инструментах вещи, а по удобству - они просто еще не успели выйти на уровень. Но нет гарантий, что конкретный новый инструмент - последнее слово в подходах в конкретной области, а не промежуточный вариант, который может оказаться неудачным.
Дальше я примерно обозначу темы, в которых работают инструменты, собираясь в мозаику. Как и в тестировании, нет единого фреймворка, мозаику каждый собирает сам под свои проекты.
Популярные инструменты, конкретные списки
Недостатки DevOps - все-таки коммуникация имеет накладные расход, даже если ты ее наладил.
И идея NoOps - вместо людей выставим API, с которым будет работать команда разработки. ServiceDiscovery - от трехзвенки к микровсервисам, помещающихся в голову каждой команды.
Дальше был провокационный на конференции тезис - ручного тестирования не останется. Но люди не испугались, потому что понятно, что его не остается в pipeline, а вот в разработке - пока останется, как часть разработки. А вот дальше - автомат, и тесты туда включаются.
Но при этом с автоматическим тестированием, которого требует pipeline - не все ясно. Например, как тестировать программы, содержащие machine learning - они же все время обучаются, там нет повторяемых эталонных результатов. И более простой вопрос - проверять по разным разрешениям - поехала верстка до неприемлемости или нет, глаз это неплохо видит, а вот комп?
В целом доклад энергичный, достаточно провокационный и экстремистский. Ответы на вопросы тоже - был вопрос готово ли образование готовить таких тестировщиков. И ответ: "Вы о чем спрашиваете? Нынешнее высшее образование - мертво, школа - тоже."
В своем докладе Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять я как раз рассматривал спектр различных способов разделения ответственности в разных проектах и способов их разделения. При этом я положил это на единые карты, используя V-диаграмму и диаграммы альф и жизненного цикла OMG Essence. Подробности - на странице доклада.
Очень яркий и содержательный доклад про проявления нескольких известных проблем сознания в IT. Проблем было три: Cargo Cult, Not Invented here, Эффект Данинга-Крюгера и утопленные расходы. https://sqadays.com/ru/talk/42782
Cargo Cult. Это весьма известная история - про самолеты во 2 мировой войны, реально прослеживают до конца 20 века. Плюс вроде было распространение между островами - они распространяли инфу, что если есть такое святилище - падают няшечки.
Not Invented here синдром. Изобрести колесо, а не пользоваться готовым. Известен с 1960-х.
Даннинг-Крюгер эффект. 1999. Оценка собственной компетентности человека.
Sunk Costs Fallacy. Утопленные расходы.
Очень качественное изложение хорошей позиции заботливого и правильного руководителя. Такие доклады реально сложно пересказывать, потому что при сокращении они превращаются в набор общеизвестных истин, а все важное - в деталях и акцентах. Поэтому смотрите видео.
Очень жесткий и провокационный доклад об активном позиции развивающегося сотрудника. Началось с метафоры: результаты теста сотрудника на старте карьеры похожи на куст, из которого во все стороны торчат ветви. И задача тимлида - развивать сотрудника в интересах компании развивает нас, обрезая ветки куста :)
Четко, структурно, по составляющим
И можно было бы опознать это как доклад о жестком руководители, но тут позиция изменилась. Тестировать надо не только подчиненных, но и свое руководство, и строить отношения соответственно. А неопытный или безразличный лид - это большой риск для сотрудника. Сотрудник должен понимать план своего развития, и задать себе вопрос о том, как компания отвечает целям его развития на ближайшие несколько лет. И в этой части тоже было много конкретики.
Таким образом, была представлена симметричная картинка людей, которые рассчитывают на активную позицию друг друга. Тут, правда, есть важный аспект: каковы интересы сотрудников и компании, насколько они могут быть различны. Этого в докладе не было, возможно, неявно предполагалось, что есть некоторая общая, всем известная модель развития сотрудника, о которой не надо договариваться. А в современном мире дело обстоит совсем не так, у людей могут быть сильно разные представления о профессиональном росте и карьерной траектории. И их надо выяснять, потому что, вполне возможно, пассивность - кажущаяся, просто человек идет к иным целям, которые ты не ты видишь. Но, может быть, на эту часть просто не хватило времени - это был блиц.
Интересный доклад. Инна налаживала работу распределенной команды, разбираясь заодно с теорией. В теории менеджмента это неправильно, а на практике это очень частый случай, когда руководитель обучается на рабочем месте, без специальной подготовки. В этом одно из различий между теорией и практикой :)
Для Инны теорией по командам была книга Патрика Ленсиони "5 пороков команды". Почему? А потому что эту книгу "почему-то активно советуют" :)
И дальше в докладе Инна шла по пирамиде, описанной Ленсиони, и сопоставляла теорию с практикой.
В распределенной команде пороки усиливаются, а то, что команда тестировщиков - вносит акценты.
Основная ценность доклада - в том, что Инна не следовала Ленсионе, а включила голову и активно смотрела на ситуацию, пробовала варианты. Например, недоверие. Способ борьбы - повысим прозрачность. Но не через отчетность, а через взаимопомощь и доверие. Тезис - правильный, а вот инструменты из книги - совместный спорт, рассказы о себе, как оказалось, не работают - и был поиск других.
А дальше был аналогичный разбор по ряду других теорий.
Синергия команды
Поле самоорганизации, улучшений, способность повлиять на решения
А еще есть магия, она же кристаллизация.
И они пишут стихи - про баги и про клиента. И клиент пишет про них.
У Антона всегда интересные доклады, и этот не был исключением. Доклад был про индивидуальные методы методы тестирования, адекватные проекту - как их подбирать и настраивать.
Но чтобы подбирать индивидуальные методы, необходимо сначала сделать карту, на которую эти методы мы будем наносить. Этой картой является пирамида тестирования, которую разные профессионалы рисуют по-разному. Минимально - 3 слоя, UI - Service - Unit. А дальше увеличивают гранулярность, например 4 слоя, 6 слоев.
В докладе было несколько вариантов разных авторов, вообще в докладе - много ссылок и цитат. И потому презентация на английском, потому что цитаты профессионалов, а они все английские.
Возвращаясь к пирамиде. Что интересно, углы пирамиды, показывающие соотношение слоев, все рисуют одинаково. И пирамида превращается в условность, потому что в реальном проекте важна взаимная мощность слоев, соотношение разных видов тестов. Именно оно должно соответствовать конструкции проекта.
А определяется это с помощью ROI. Многие боятся и считают непонятной экономикой. А реально это ответ на вполне понятные и уместные вопросы. Сколько часов мы тратим сегодня на тестирование? Сколько будем тратить на автоматизацию? Когда придет возврат затраченных часов?
Если не учитывать экономику, то пирамида тестирования часто получается перевернутой - потому что заказчику видны UI-тесты, а не Service и Unit, которые он не понимает. И надо отдельно обосновывать, что тесты в основании пирамиды - дешевле, и при этом позволяют сократить число UI-тестов.
Впрочем, по моему опыту, об этом надо еще отдельно заботится - я видел/слышал о ситуациях, когда тестировщики на UI-уровне игнорировали наличие Unit-тестов от разработчиков, тестируя все по площади, потому что никакой информации о том, что же именно проверяют Unit-тесты, что они гарантируют извлечь из разработчиков не получалось.
Дальше было много самых разных историй про особенности проектов и тестирования в них, включая влияние разных рисков.
Содержательный доклад про нагрузочное тестирование новостного сайта. Сайт был в непрерывной доработке, заказчик все время придумывал новое, и задачей было при этих обновлениях не уронить производительность. Задумались они об этом не с самого начала, а после того как очередное обновление уронило сайт - главная страница 19 сек, статья - 10 сек. На первом этапе выделен критичный функционал - загрузка статьи, подгрузка, выгрузка на печатный сервер, и только он автоматизировали. А потом начали на мониторинге выделять узкие места.
Интересно, что начальство и менеджмент были не слишком согласны на тестирование, не взирая на фейл. У них было дурацкое ощущение "тестировщики капризничают". Первый этап сделали на энтузиазме, и только когда результат был достигнут, они прониклись.
Доклад про уязвимости интернета вещей - их много. Изучили код платформы Samsung и запросто сделали приложение, которое прикидывается монитором батареи, а реально меняет pin-код входной двери, и делает другие вредностные вещи. В общем-то дырки давно известны. И дальше шел призыв к разработчикам тщательнее подходить к безопасности и тестировать приложения. Это, конечно, правильно, но принципиально ситуацию не изменит. Потому что такое тестирование увеличивает стоимость и, как следствие, будет увеличивать цену изделия. А дальше возникает вопрос: если есть браслет для мониторинга шагов с протестированной безопасностью за 1500 и без него за 1000, сколько людей заплатит больше денег? Подозреваю, что очень мало. А значит производители будут на этом экономить. До тех пор, пока требования к безопасности не заложат в стандарт, обязательный для платформ, и их производители не сделают внешнее ограничение безопасности приложений. Но вот такой постановки вопроса в докладе не было - что, в общем-то, естественно - это доклад для другой конференции :) А с технической точки зрения рассказ был вполне профессиональным и интересным.
Хороший и структурный рассказ о том, как устроена автоматизация тестирования.
Как создаются тесты. Сначала - новый функционал - и тест-кейсы, выполняемые вручную. И после этого часть кейсов автоматизируют - это выделяют.
Архитектура автоматизация тест-кейсов - три уровня: бизнес-логика, хелперы, нижний уровень реализации. С примерами - из них ясно уровневое деление.
Тесты бизнес-логики - не меняются с реализацией. А вот реинжиниринг функционала - меняет уровень хелперов.
Было монолитное приложение. А теперь идет перестройка на микросервисную архитектуру. И там - стратегия, разные виды тестов
Автотесты в билде.
Автоматизация - постоянный процесс.
Тестовые данные - есть пул тестовых пользователей с разными характеристиками, выдается произвольный. А для некоторых тестов данные создаются внтури.
Как разработчиков заставить писать unit test? Он 6 месяцев показывал с реальными метриками, показывающими время на исправление багов - которые можно было бы занять написанием автотестов.
Рассказ из Wargaming о том, как у них устроено тестирование и выпуск в продакшн Warship - корабликов.
Нельзя сказать, что рассказ был очень систематичным, но он был интересным - заглянуть в кухню реально большого и сложного продукта.
Метафора молота и наковальни. Наковальня - пользователи. Молотов много - разработка, команда акций, команда поддержки и т.п. У каждой команды - свои планы и пожелания, и все это интегрирует команда релиза.
С пользователями есть проблемы обратной связи. Неинформативная, субъективная, эмоциональная, токсичная, ложная (вбросы) и т.п. Отдел поддержки пользователей - как-то фильтрует.
Уровни тестов
По результатам обрабатывают статистику по багам.
Пример. Была выпущена версия на общий тест. Думали, что проблемой будет стабильность. А оказалось - не соответствие ожиданиям пользователей. Как итог - одну фичу переделали до продакшена, а другую - вообще не выпустили.
Выпуск патча с фиксом у них - до 7 часов. Без отладки и самой починки. То есть баг в релизе - конкретно дорог. И небольшая доработка тоже. Поэтому важно не допустить выпуска с критичными багами, поймать заранее.
Интересно было про региональные особенности. Не только локализация, но и законодательство. Классика у них - Китай.
Интересный доклад про критерии прохождения тестов для нагрузочного тестирования. Оно обычно выдает множество графиков. Можно формально накладывать ограничения, но реально для большинства из них не будет оснований, особенно в период интенсивного развития системы, а при нарушении придется каждый раз заново понимать: это реальное ограничение или произвольное.
Был рассказан следующий подход.
Поэтому сместили фокус с потребления ресурсов на комфорт пользователей.
Далее было много деталей. Например, потребление памяти - не в Мб, а от максимально доступного в % для конфигурации.
А время отклика для пользователя
В докладе было много конкретных примеров метрик.
В светофорной модели мы смотрим не только позицию, но и переходы между зонами и направление изменений. Улучшения, пусть в красной зоне, означают что тест прошел, а вот ухудшения в красной или переход в красную - fail.
В докладе была немного странная подводка про то, что докладчик хочет много странного, всякий редизайн, желание повесить кнопки, и непонятно зачем. Если подумать, особо странного нет, это типичная ситуация, когда на продукте экспериментируют "а вдруг так будет лучше", непрерывно проверяют гипотезы. Просто автор этого не сказала, вот и возникает ощущение заказчика без мозгов, который не знает чего хочет.
А дальше было вполне по делу - какие страницы исследовать, что исследовать, какие элементы. Анализ поведения аудитории. Измеряемые метрики. Занимается всем этим тестировщик - на практике. Хотя есть всякие варианты.
Были конкретные примеры гипотез Заменить SignUp на Free SignUp. Или бронирование отелей - вариант цветовой дифференциации против другой. И еще ряд примеров. Из интересного: для привлечения покупателей часто пишут цену со скидкой и полную рядом. И это очень хорошо работает - пока в ценах не возникает слишком много цифр и они перестают помещаться в комфортное поле - тогда надо менять конструкцию...