Объектно-ориентированные RESTfull - привязываем к объектам. И дальше SCRUD.

Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное

Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.

Amanita. Мониторинг брака - видеокамера - json - обработка данных - и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ - большая разница, зависит от того, нужна ли будет обработка.

Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика - не SQL, а Java. Декомпозиция бизнес-идеи - выделяем субъекты и объекты - строим граф - строим json-схему - строим базу данных.

Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.

#AnalystDays Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент). BPMN хорошо описывает процессы, особенно если дополнять его описанием орг.структуры и объектов данных, для которых есть отдельные нотации. Но есть отдельные этапы процессов, исполнение которых плохо описываются с помощью BPMN, потому что не представляют собой структурированный процесс. Диаграммы получаются запутанными и не проясняют содержание. И для отражения таких функций можно использовать две другие нотации.

Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя - и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN - decision model and notation. В простейшем варианте такое решение - просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений - и они, во-первых, должны быть в системе а, во-вторых - представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.

Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение - на усмотрение ответственного. И в финале тоже есть опциональная часть - обращение в суд. Для этого хорошо подходит нотация CMMN - Case management model notation. В ней акцент - не на процессе, а на информации по конкретному случаю. Цель процесса - ясна, а путь - вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка "Проведение проверки". (2) Входные критерии - с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап - не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, даальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом - финальный обязательный этап - акт проверки, и снова дискреционный - работа с судом, а дальше выходные критерии.

В презентации были примеры диаграмм, их опубликуют быстро - можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.

#AnalystDays Ярослав Кучеров из Газпромбанка. Матрица сценариев - инструмент бизнес-анализа. Матрица сценариев - способ представить варианты реализации. Мы выбираем бинарные параметры, которые конфигурируют поведение приложения, и дальше для каждого варианта приложения с их помощью определяем конфигурацию. Например, если надо сделать систему лояльности, то параметрами будет реализация конкретных фич: начислить баллы, списать баллы, посмотреть свои баллы, предложить клиенту списать баллы. И дальше для каждого канала взаимодействия с клиентом: авторизованный заказ на сайте, быстрый заказ без авторизации, мобильное приложение, официант в ресторане, колл-центр - определяем, какие сценарии в них должны быть реализованы. Получаем матрицу, согласуем с заказчиком и именно это делаем. Матрица дает наглядное представление, и в презентации было несколько вариантов и примеров из реальных проектов, помимо модельного.

Быстро собрал отчет https://mtsepkov.org/AnalystDays-2023b по конференции AnalystDays, дополнив посты, которые публиковал в ходе конференции, заметками с еще нескольких докладов. За два для я было много хороших докладов: Анатолий Левенчук про Интеллект-стек, лучший доклад про ТРИЗ из тех, что я слышал, глубокий доклад про ООП с хорошим определением архитектуры, узнал про нотации DMN и CMMN, дополняющие BPMN для не-процессных бизнес-функций и много других. Я сам рассказывал про рациональное и системное мышление и, по отзывам, получилось хорошо. И, как всегда, качественное общение. До новых встреч на других конференциях!

Выступил вчера на Podlodka Teamlead Crew Работа со стратегией в реалиях современного мира https://mtsepkov.org/StratPodlodka - теоретический экскурс про 10 школ стартегирования по стратегическому сафари Минцберга и принципы гибкой архитектуры, которые позволяют быстро делать проекты из собственного опыта с кейсами. После выступления почти час отвечал на вопросы, тема оказалась актуальной и востребованной

Как обычно, в начале сентября был на #festpir - большой конференции тренеров и коучей. Как всегда - феерия выступлений и общения. Для меня эта конференция - чувствительный индикатор времени и место встречи с интересными людьми. Как обычно, публиковал впечатления о наиболее запомнившихся выступлениях в телеграм-канале, но многое осталось только в заметках из-за насыщенной программы. Поэтому публикация отчета затянулась, но, наконец, сегодня я публикую заметки, дополненные впечатлениями о других выступлениях https://mtsepkov.org/PIR-2023 Я надеялся успеть до отчета посмотреть записи выступлений, которые были online, но то пока в будущем, надеюсь, что получится и тогда я дополню отчет. А сам я тоже выступал на ПИР с докладом "Я и мои аватары в спектакле жизни" про модель личности, видео уже опубликовано, а продолжение будет в конце ноября на Teamlead.

Смотрю записи докладов #festpir, которые не получилось увидеть на конференции. Марк Розин. Новые времена - новые песни - осмысление нового мировоззрения 21 века и его отличий от мировоззрения 20 века. Это сборка комплексной, целостной картины, а не отдельных трендов, чем и интересна. Дополнил отчет по ПИР, читайте конспект и мое осмысление услышанной картины (это в конце отчета, ссылка должна перейти туда).

Сегодня на #sqadays. Первый доклад Марина Тарасова из SimbirSoft: Индивидуальный план развития. Доклад важен мне, потому что сам я буду выступать на связанную тему - о самоопределении и профессиональном росте. Мне доклад очень понравился. Он начался с важного тезиса: компании выгодно вкладываться в специалиста, чтобы он развивался, хотя при этом сотруднику надо будет больше платить, потому что в результате проект компании лучше двигается. Отмечу, что это не для всех компаний справедливо, есть компании, предоставляющие тестировщиков на аутсорсинг в определенной нише рынка, и если сотрудник слишком развивается, то для него не могут найти проект, надо менять компанию.

Главное что дает индивидуальный план развития - визуализацию и прозрачность процесса. Чеканная формулировка: что визуализировано - достижимо, что достигнуто - достойно награды. По опросу аудитории, ИПР - не единственный способ, есть самостоятельное развитие с оценкой через внутреннюю оценку или контроферы и другие варианты.

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

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

Планы развития всегда включают soft skill, а не только hard. Не должно быть много: 1-2 hard + 1 soft. Откуда брать: из задач проекта, существующих проблем и потребностей улучшения, обратная связь от команды, будущие задачи - тренды и бизнес-цели проекта, опыт других, карьерное консультирование. Цели встраивают личное развитие в развитие проекта.

Развитие soft skill можно делать через доп.активности на проекте: демо, ретро, лидство (наставничество, кураторство), ревью и внепроектные активности - митапы, конференции, статьи.

Вопросы-помощники: зачем, хватает ли навыков для выполнения задачи, какие проблемы есть на проекте, какие задачи интересны?

После целей: декомпозиция цели на задачи - как с user story, критерии успеха и сроки и контролируем процесс.

Что делать, когда сроки сдвигаются? Задача не выполнена вообще, когда ничего не делали. Если делали - вопрос сколько сделали. Корректируем план, если не сделано. Вопрос - в чем не выполненная задача полезна для бизнеса? Если надо было запустить автоматизацию, а ты возишься с инфраструктурой - то награда будет маленькой.

Цикл контроля общий: Цель - План и параметры - Мониторинг в точках контроля - Коррекция по результатам мониторинга.

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

Что делать, чтобы сотрудники хотели составить ИПР? Покажите своим примером. Я поехала выступать на конференцию - публикую фотки, потом расскажу про доклад, сотрудников тоже может вдохновить, они захотят выступить. Еще она сама каждый квартал защищает производственные цели перед топами, и их рассказывает сотрудникам - они могут помочь.

Про мотивацию есть книга Светлана Иванова "Мотивация на 100% - где у нее кнопка". Преподнесение информации - идеальна. Я, правда, тут хочу предостеречь: есть другая книга Шпренгер "Мифы мотивации", где автор разбирает все известные схемы мотивации и показывает, что они ведут к деградации в долгую. Книга - старая, но я критикуемые методы видел и в свежих, люди работают в короткую. Так что полезно самим соотнести перед применением.

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

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

#sqadays Виталий Старостин из ПСБ. В чём измеряются инженеры по тестированию. Хороший доклад о том, как мониторинг сам по себе улучшает ситуацию, потому что проблемы становятся явными. У них количество людей сильно возросло, и они решили ввести метрики, чтобы понимать, кто и что делает, работы нет или ее не видно, опасения, что метрики покажут не адекватную картину, понятное отношение сотрудников, которые не хотят чтобы их мерили, потому что и так работают хорошо. И они решили двигаться, не смотря на опасения. В презентации был чек-лист идеальной метрики и полный набор метрик, который они используют. И подробно раздирались метрики для ручного регресса, который является дорогим процессом - 27 тестировщиков + капитан + команда разработки 3.5 дня на первую итерацию. Тест кейсы распределялись по тестировщикам автоматически равномерно по оценке трудоемкости, дальше тестировщики их выполняли, если кто-то не успевал - товарищи ему помогали, а выполнение тест-кейсов фиксировалось. Метрики позволили увидеть, кто именно из тестировщиков столкнулся с наибольшими проблемами и дальше поговорить, чтобы эти проблемы увидеть и решить. Из интересного: выяснилось, что алгоритм распределения тест-кейсов реально распределяет их неравномерно, выявились тест-кейсы с неверной оценкой, увидели, что процесс актуализации тест-кейса не работает, а он - дорогой. В целом был получен результат, время первой итерации сократилось в 1.5 раза, с 28 до 19 часов, и дальше это было стабильно. Они продолжают работать по выявленным проблемам. А потом будет следующий такт.

#sqadays Таисия Толстунова и Елена Коренева из VK Tech. Преодоление трудностей кросс-продуктового тестирования: подходы, лайфхаки и инструменты. Рассказ про VK workspace - коммуникационная платформа для бизнеса: teams, почта, календарь, мессенджеры, диск и так далее. Пользователи воспринимают продукт как целое, хотя могут пользоваться отдельными частями. И там появляются кросс-продуктовые фичи, которые интегрированы более чем в одном продукте и должны быть представлены единообразно. Разработкой занимается несколько команд или несколько участников из этих команд. И при этом всегда возможны не стыковки из-за несогласованных действий команд. Проблема понятная, и решения, в общем, тоже понятные - нужна координация и согласованность процессов, и это надо выстроить.

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

А дальше следующий уровень, различие ценностей, процессов и ожиданий.
* Одной команде важно качество продукта, а другой - сроки
* Надо выработать правила общения, договориться об определенных вещах и соблюдать договоренности.
* Определить ситуации, когда собираются звонки.
* Разные команды работают в разных процессах: Scrum, Kanban, собственный процесс, может быть несколько досок, а не одна. Они анализировали различия, для выравнивания одна команда взяла часть процессов у соседей и адаптировали.
* Организовать agile-практики для кросспродуктовой команды по фиче: ретро, груминг. И надо синхронизировать ожидания, так как в разных командах эти мероприятия делают по-разному.
* Одной команде важно тестировать до предпрода, а другой - только на нем из-за особенностей конфигурации - надо найти решение, по факту сделали отдельные стенды.

Казалось бы, все понятно, но далеко не всегда это делают и это - боль. Это было видно по реакции зала.

Презентация моего доклада - на моем сайте https://mtsepkov.org/SelfDetSQA23

#sqadays Иван Железков и Алексей Кожин из ПСБ. В стране невыученных уроков, или как создавалась школа тестирования ПСБ. Тотальный дефицит привел к тому, чтобы создать школу обучения новичков внутри. Потому что программы обучения на рынке очень слабо коррелируют с потребностями. Когда вы обучаете для себя - можно получить тех, кто нужен. И был короткий рассказ, как они это сделали.
1. Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.
2. Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов
3. Опишите роль - кто должен получиться.
4. Разработайте контент.
5. Запустите обучение.

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

Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.
1. Первичная оценка и передача знаний
2. Создание рабочего артефакта
3. peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга
4. Оценка экспертами результата

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

По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.

Результаты:
* частичное решение проблемы подбора через обучения молодых - джун+, подтверждено
* снижение текучки - эксперты смогли проявить себя по-другому
* сокращение затрат на обучение за счет привлечения внутренних экспертов

В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.

#sqadays Анастасия Золотых из 2GIS. Тестирование на лету: новый подход к визуальному тестированию. Продукт Otello: web, мобилки, множество платформ, виджеты для встройки. Среднее время разработки и доставки фичи 5 дней, смесь ручного и автоматизированного тестирования, в автотестах - случайные разрешения для устройств и случайные данные с генерацией на лету. Их команда тестирует фронт, бэк и интеграция - через моки. Команда решала задачу расширить автотесты, добавив проверку по скриншотам, так как проверка на всех платформах и разрешениях - трудоемкая. Классический подход основан на том, что ты держишь эталонные скриншоты и сравниваешь с ними результаты, которые получил при прогоне теста. В их случае возникают сложности: эталонные скриншоты надо обновлять вручную, и не очевидно, что это даст меньше работы, чем ручное тестирование, к тому же на скриншоте - фиксированное разрешение и данные, нельзя использовать случайную генерацию.

Поэтому они реализовали комбинированную конструкцию: сделали повторяемую генерацию данных с использованием random seed, что позволяет прогнать один и тот же тест на проде и на тестовом стенде, и снять скриншоты, которые должны совпасть там, где функционал не менялся. Снятие скриншотов встроили в систему функциональных тестов, а вот их сравнение запускается отдельно, и не совпадение на останавливает конвейер поставки, а разбирается вручную. Со снятием скриншотов есть отдельные проблемы, когда есть анимация и дочитка блоков, их не разбирали, а дали ссылку на другой доклад. Сравнение идет по хэшу, так как основная масса совпадает и это - быстро, а если хэш не совпал - используют pixelmatch, и результат показывают три картинки: тестовую, эталонную и расхождения. Понятно, что есть фичи с редизайном интерфейса, когда скриншоты с прода и теста точно не совпадают, они помечены отдельно, с учетом номеров версий, и это оставлено на ручное тестирование - пока функционал не докатят до прода.

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

#sqadays Алексей Пименов. Я предлагаю - они отказываются! Как обычно превосходный доклад о психологических аспектах сопротивления изменениям и работе с ними. Социальные аспекты сопротивления доклад не затрагивал, в вопросах они проявились, Леша отвечал и сказал, что об этом у нее есть отдельный доклад.

Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.

Питер Сенге писал: "люди любят изменения, люди не любят меняться самим. И если понять как мыслят люди - можно увидеть природу сопротивления. Для этого Алексей опирается на модель Канемана Думай медленно, решай быстро, Канеман выделил в мозгу две системы: быстрых решений и реакций, которую навал Система-1 и медленных размышлений, которую навал Система-2.

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

Система-2 - логическое мышление, обучается через теорию и чужой опыт, по сравнению с ситемой-1 - быстро, на хорошем тренинге можно получить информацию, эквивалентную 2-3 года личного опыта и начать ее опрокидывать в практику за счет упражнений, но реагирует эта система медленно - размышление требует времени, и крайне энергозатратна.

Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.

Если говорить в позитиве, то и модель Маклина - вполне рабочая модель, если рассматривать ее как выделение логических уровней, подобно к тому, как мы выделяем логические уровни приложения (фронт-бэк-БД), при этом каждый уровень не просто обрабатывает запросы другого, а имеет собственные активные процессы, обращающиеся к другим. Схемы работы мозга, которые получаются на их основы, вполне совместимы с современными моделями работы мозга. Если интересует - я готов обсуждать подробнее. И модель Канемана тоже рабочая, она - функциональная, описываемые ей эффекты есть, а уж как она локализована в мозгу - вопрос отдельный, не следует путать функциональное и модельное деление системы, они отличаются. Когда нейрофизиологи предложат иную локализацию систем Канемана и уточнят их - будем ей пользоваться.

И отдельное замечание про энергозатратность. Нейрон - это клетка, и как клетка он обладает постоянным потреблением АТФ, описываемое циклом Кребса, вариации в пределах 5%, тепловые карты возбуждения мозга показывают именно такие вариации. Но вот для взаимодействия с другими нейронами, размышления ему нужен дофамин, ресурс которого ограничен и в лимбической системе есть регулятор, направляющий его в части, управляющие движением, если ситуация предполагает, что организму придется драться или убегать, то есть в стрессе, или в неокортекс для спокойных размышлений. А так мозг не устает. Разработчик "устал" писать код и пошле "отдыхать" в Warcraft - мыслительных ресурсов эта игра требует не меньше, а иногда - больше. Просто система подкрепления перестала воспринимать написание кода как полезную деятельность и выдавать дофамин под нее.

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

Возвращаюсь к конспекту. Есть борьба двух систем за ресурсы. Вы системой-1 ведете автомобиль, а системой-2 обсуждаете ремонт в квартире, вдруг на дорогу выбегает собака, контраварийная езда требует всех ресурсов, и Система-2 отключилась. И наоборот, он этот тест часто проводит: ходит с человеком кругами по залу и человек складывает двухзначные цифры, ок, потом предлагает умножать, простой пример - не проблема, а сложный - человек может пойти в отказ, но если начинает считать - останавливается, потому что система-2 забрала все ресурсы, на прогулку не осталось. При этом в подавляющем числе случаев побеждает система-1.

Как это работает с изменениями? Вы приходите в команду, готовите логичные аргументы, рассчитываете на систему-2 - а они влетают в систему-1 и получаете фабрику гнилых отмазок. Почему? Любые новые роли атакуют идентичность человека. "Некогда объяснять, ты scrum-мастер" - а он PM, он знает кто оно такой, перспективы и так далее - много вопросов. Новая ответственность атакует чувство собственного достоинства и так далее. Люди чувствуют, что получат гораздо меньше, чем потеряют. Есть люди, которые за любой кипеж кроме голодовки - их 15-20% они всегда за. А остальные - видят проблемы и угрозы и консервативны.

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

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

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

Дальше - ответы на вопросы.

Вопрос. Если команда против и выходит в саботаж, что делать?
Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.

Что почитать? Есть хороший бизнес-роман Рей Иммельман "Босс бесподобный или бесполезный". Будете искать - есть еще книги с похожими названиями: "Хороший босс, плохой босс" и "Хороший плохой босс", они про другое, не путайте.

Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".

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

Вопрос. Есть системные администраторы на площадках "я не буду делать - не знаю", хотя на собеседованиях показывали. А другие - сидят в кабинеты и не выходят в поле. Что делать? Ответ: дело в авторитете руководителя, как его поднимать, если технических скилов недостаточно. Лайфхак: собрать группу, и сказать "такая задача - ваши предложения". У него есть игра: 3 стикера, довольная, нейтральная, недовольная. Выигрышная стратегия: хорошие расхватали, потом даешь недовольную, не доволен - какие предложения, и так далее - требуешь договариваться. Чтобы не выходить впозицию "я начальник - ты дурак", а это - не перспективно.

Вопрос. При внедрении изменений сталкиваешься с манипуляторами, которые тоже давят на систему-1, эмоции. Как быть? Ответ: подумай, нужен ли такой вредитель в команде? А в моменте спроси при всех: "Какого результата ты хочешь добиться такими возражениями?" - это может рассыпать чистый деструктив, вывести в область конструктивных предложений.

#sqadays Эмиль Барлыбаев из Doubletapp. На старт... Внимание... Нагружаем! Короткий рассказ про организацию нагрузочного тестирования. Потому что важно не просто дать нагрузку - надо дать разную нагрузку для определения разных характеристик. Для начала надо понять, какие запросы будут давать основную нагрузку, обычно они составляют малое количество функционала, и тестировать надо именно их, а не по площади. Далее даем нагрузку и делим три зоны: слабую, когда потребляемые ресурсы постоянны, а время отклика около нуля и не растет, основную, в которой ресурсы растут линейно и рост времени отклика примерно линеен по нагрузки, и стрессовую, когда мы постепенно приближаемся к максимуму нагрузки. В целом у нас - образная кривая, и эти зоны - ее деление. В примере пределом было 100 rps, слабая дона 0-40, рабочая 40-80 и стрессовая от 80. Дальше сравниваем вычисленную нагрузку с ожидаемой. Если ожидаемая ниже - то можно сокращать ресурсы. Если больше - нужно масштабирование, горизонтальное (больше нод) или вертикальная (мощность ноды). И делаем три вида тестов: под рабочей нагрузкой проверяем стабильность работы, стрессовое для проверки работоспособности под большой нагрузкой и долгое (8+ часов) тестирование под низкой нагрузкой, чтобы увидеть, что ресурсы сервиса не текут. Еще нужно тестирование всплеска, обычно есть события, когда ожидается всплеск нагрузки, вплоть до перегрузки, и надо проверить, что когда оно проходит, сервис возвращается к рабочим параметрам. Помимо этого нужно тестирование объема, что накопление данных не повышает время отклика. И в конце доклада - оформление отчета и рекомендации lzk начинающего, но это - стандартно.

#sqadays - публикую что не успел вчера Анфиса Лаврова. Проектирование процесса тестирования по проблемам. Любопытный доклад об успешном сокращении регресса от 6 недель до 2, а далее до одной, с уменьшением числа занятых тестировщиков с 5 до 3, то есть трудоемкость уменьшилась в 10 раз. Что важно - были разобраны неверные шаги, которые предприняли сначала. А также показано применение различных методов - организации процессов, анализ причин на простых примерах. Так что в целом - успех. А сами неверные шаги служат хорошей иллюстрацией того, как применение стереотипных ответов может оказаться неверным в конкретной ситуации.

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

Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.

Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Кога Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.

Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.

Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увелчилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.

После этого решила, что нужен анализ. Есть два метода: дерево текущей реальности и 5 почему. Дерево попробовали - сложно, а 5 почему у них сработал. На слайдах и в рассказе было объяснение, что именно они увидели: они прогоняют все 5000 тестов для всех 3 баз платформ, в то время, как часть из тестов проверяют фронт, UI, который для всех платформ одинаков, а часть - проверяют еще и бизнес-логику, которая может различаться, так как для каждой платформы бэк имеет свою реализацию. Очевидно, что тесты, которые исключительно проверяют фронт достаточно прогнать один раз. И они разметеили тесты, скоратив время прогона.

Крмое того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.

Что интересно, мотивация сотрудников в результате тоже выросла. Долгий регресс с механическим повторением кейсов их сильно демотивировал. Так что заодно была решена вторая проблема.

#sqadays Андрей Бровко из Авито. Оценка рисков в разрезе модели качества продукта. Интересный доклад с приземлением общей теории управления рисками к тестированию продукта. На хорошем уровне, со ссылками на стандарты, это было в презентации, но я записал не все. Но, к сожалению, в докладе не было приземления этой теории на практику в разных вариантах, и каких-то не очевидных примеров применения, тонкостей. Хотя некоторое количество примеров - было. Но такое представление все равно полезно - чтобы ничего не забыть, и чтобы показать соответствие стандартам, это может быть важно для проекта.

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

Уровень риска: вероятность * влияние, оцениваем по трем градациям низкий-средний-высокий по каждой оси. Для программы надо описать требуемый профиль риска, стандартного нет, и это понятно: для медицинских программ одни требования, для информационных сайтов - другие, для систем, от которых зависит исполнение бизнес-процесса - третьи и так далее.

Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.

Виды риска:
* риск проекта: персонал, поставщики, организация, лицензии, техника
* Риск продукта - опыт пользователя: функциональность, ошибки и та далее.

Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.

Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.

Делаем чек-лист. На слайде был скриншот из системы работы с рисками, Слева - виды тестирования, справа - список рисков, их вероятность ивлияние.

Список рисков целесообразно вести не для каждого проекта, а общий, а для проекта из него делать выборку и описывать параметры. У них есть корпоративный список рисков и процесс ведения: изменения инициируют тестировщики, плюс ведется регулярный пересмотр актуальности и оценки рисков.