#festpir Сергей Бочаров. Сила слов: как понять своих. Очень неожиданный доклад. Сергей -- это Сенеж, «Россия -- страна возможностей». Он рассказывал методику, которую они строят для того, чтобы определить стиль работы человека. Люди -- разные и позиции тоже. Никакие KPI не будут побуждать человека работать в полную силу, если позиция -- не его. А цикл планирования в государстве -- год, и времени поправить ошибку нет, поэтому хорошо бы определить пригодность заранее.

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

Классификация таланта -- по мотивам Юнга. Но собственная интерпретация, на соционика и не Майерс-Бриггс. Что вполне объяснима: цель типологии отличается, и классификация тоже другая.

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

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

У человека два главных таланта. Те, у кого комбинация Власть и Логического мышления может управлять большими системами. А если Власть и Вовлечение людей -- может вовлекать в большие дела. Комбинация Гармонии и Эмпатии -- забота о комфорте человека и гармонизация отношений. И так далее.

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

Три российских стиля лидерства:
* Властвовать, исторически оно первое, когда давали волость в управление. Сейчас они органы исполнительной власти везде заменяют на управление.
* Руководить -- это вести за руку, а ты за ним идешь, как учитель в школе.
* Управлять -- Людьми управляет Бог и он наставляет. А кораблем управляет капитан, повернул штурвал -- и корабль поплыл, матросы при этом сами делают что нужно.

Руководитель и коллектив, с этим связаны справедливость, счастье, благодарность, совесть.
* Россия -- арбитр справедливости мира
* Счастье -- интимно, министр счастья -- не заходит
* Благодарность -- божественное влияние блага на человека
* Совесть -- голос Бога в человеке, по Достоевскому.

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

P.S. Выступление было вчера, но я не успел сделать конспект, публикую сейчас. И еще несколько конспектов будут вдогонку.

#festpir Обнаружил, что не опубликовал, исправляюсь. Сергей и Виктория Бехтеревы. ТВОЯкратия: твой Язык, твои Правила, твоя Игра. Сергей и Виктория рассказывали про ТВОЯкратию -- подход к созданию системы самоуправления, адаптированной для конкретной компании. В основе -- спиральная динамика, понимаемая как набор игр, в которые играют люди. Сергей и Виктория прорабатывают это несколько лет, я рассказывал, и у них есть книга.

На сайте selfm.ru -- база кейсов самоуправления, они все открыты, и можно скачать книгу с примерами и кейсами. Кейсов много, и можно увидеть разнообразие. И это работает. Что меняется при переходе к самоуправлению?

1) От персонала, подчиненных и человеческого ресурса -- к членам единой команды, единомышленникам и даже командам гениев. При этом у таких команд -- свой язык. И цель, задачу можно формулировать по-разному, и от этого зависит с каким вдохновением пойдем. У этих компаний нет ощущения, что «хорошо там, где нас нет».
2) От хрени, которая дает чувство вины -- к целостности. Есть схема: вертикаль Ян про действия, договорились -- делаем, и горизонталь Инь про правила. И любое напряжение снимается одним из двух способов: договориться и сделать или договориться и изменить правила. А хрень возникает, когда не договариваются, а накапливают напряженность.

Каждый уровень по-своему накапливает напряженность.

* Фиолетовый -- затаить обиду, и ждать, когда руководитель придет и спросит, что ты хмурый, или распустить сплетни.
* Красный -- наорать, поскандалить, проявить гнев
* Синий -- игра в вину и стыд: а вот, маркетологи Apple запустили, а вы...
* Оранжевый -- сравнить и оценить
* Зеленый -- проклясть, обвинить в ереси
* На желтом хрени нет, она не копится -- мы оговариваемся и делаем.

Люди играют в хрень неосознанно, они не понимают, что можно иначе. А великая алхимическая формула, фундаментальный навык: не копить напряженность, а озвучить: в чем моя напряженность/вижу возможность и я предлагаю сделать это.

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

3) От работу работать -- к реализации своего предназначения. Работа -- пространство, где собственник и сотрудники реализуют свою мечту. И мечта -- эволюционирует, был слайд с примерами. Например, о «Обеспечивать и контролировать безопасность» к «Создавать безопасную среду для клиентов и сотрудников».
4) От безразличия -- к вовлеченности. Задача: включить максимум сотрудников в развитие контуров. Поддержка и внимание -- друг от друга, не от руководства.
5) От конкуренции -- к творчеству и скорости инноваций. Органы тела не конкурируют между собой и не обижаются. На всех уровнях -- сотрудники, подразделения, другие компании. Обычные компании боятся, что конкурент съест долю рынка. А интегральные считают, что рынок бесконечен, бездна инноваций для создания уникальных голубых океанов -- и на всех хватит. ВкусВилл всех учил -- Перекресток и Пятерочка тоже поменялись, но ВкусВилл не потерял.
6) От слепого копирования -- к уникальности -- ТВОЯкратия
7) От контроля -- к доверию. Мы же берем взрослых людей -- зачем их контролировать. Это не про всех, есть те, кого надо контролировать.
8) От разделяй и властвуй -- к прозрачности. Доверие невозможно без прозрачности, все открыто. Контроль и поддержка.
9) От управленческой борьбы -- к самоуправлению

Дальше время подходило к концу, и презентацию Сергей листал быстро. Я записал немного. Были критерии сотрудника, готового к систему самоуправления: видит зоны безответственности и закрывает их, берет и делает; делает проекты развития; реагирует на нарушение и соблюдение правил; дает возможность быть лидером каждому -- всего 11 критериев.

Не обязательно все сотрудники удовлетворяют всем критериям, но достаточно много их закрывают. И тут два вопроса: кто так делает и кто имеет потенциал? Оказывается, в обычной компании обычно так поступают 2% сотрудников, но потенциал имеют все и его можно взрастить. Как кристаллизовать потенциал? Собрать лидеров 40-50 человек и договориться по 7 вопросам, они есть в презентации.

И еще в выступлении была тема самоуправления в Китае, ее вынесу отдельно. Они ездили и смотрели, как там устроено. и поедут еще. Китай научился совмещать командно-административную системы в стране с рыночными компаниями и самоуправлением. Особенность в том, что они -- интеграторы, они всему учатся, не осуждают и берут самое лучшее. У нас принято выкидывать старое, а у них -- нет. У них сегментация: здесь -- регулярный менеджмент, а тут -- холакратия. И такой же подход они закладывали в ТВОЯкратию.

P.S. Это все выступления, по которым я успел сделать пост в ходе конференции. Дальше я буду собирать отчет и дописывать, потом опубликую.

Пять лет назад, в октябре 2020 я был на первой экскурсии-стажировке в Oil Energy, компания только начинала их проводить. А сейчас организаторы позвали меня на 40 экскурсию, чтобы я посмотрел на произошедшие за это время изменения. Я поехал и делюсь впечатлениями https://mtsepkov.org/OilEnergy-25. Я не буду подробно излагать историю трансформации Oil Energy к самоуправлению, об этом смотрите мой старый отчет, а в фокусе этого -- изменения за пять лет и немного о текущем состоянии. Если кратко -- то самоуправление компании стало более зрелым, многие функции взяли на себя команды.

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

В начале сентября я был на ПИР, вы уже видели посты по отдельным докладам, но я успевал опубликовать далеко не все. Сейчас дополнил и собрал отчет https://mtsepkov.org/PIR-2025

Темой ПИР в этом году было словотворение, слова и смыслы. Но основной темой для меня была растяжка между двумя вариантами будущего: Гарретт Джонсон рассказывал про переход к шестому технологическому укладу, который принесет изобилие и человекоцентричность, а Елена Черникова и Анна Славнова рассказали ту модель будущего, которую сформировал Стэнфорд: люди будут жить 100-120-150 лет, но в постоянном беспокойстве и страхе, тревоге за свое будущее. На эту растяжку еще наложились впечатления от выступления Артема Соловейчика, который говорил про внутреннюю свободу, с одной стороны, а, с другой стороны, выступления Дмитрия Сендерова, основной посыл выступления которого примерно такой: все продукты одинаковы, а выбираем мы их по той лжи, которую нам впаривает маркетинг.

С этой темы я начинаю отчет, а потом будут конспекты докладов.
* Гарретт Джонстон. Человекоцентричность — ключ бизнеса в шестом технологическом укладе
* Панель про эволюцию русского языка.
* Андрей Комиссаров. ИИ как создатель новых нарративов.
* Анна Валл. И не говори!..
* Марк Розин вместе с командой представили «схему компании на одном слайде»
* Сергей и Виктория Бехтеревы. ТВОЯкратия
* Сергей Бочаров. Сила слов: как понять своих. Сергей из Сенежа, и в выступлении была разработанная ими типология для определения соответствия человека позиции в управлении
* Нюта Федермессер рассказывала о тех проблемах связанных с возвращением тех, кто сейчас участвует в СВО, к мирной жизни. Обычное мнение состоит в том, что надо помочь им адаптироваться. Реально дело состоит совершенно иначе: всем нам надо будет адаптироваться к тому, что заметную часть социума будут составлять люди, прошедшие СВО, и это изменит все общество.
* Дмитрий Сендеров. Слово и нейромаркетинг
* Елена Черникова и Анна Славнова. Longevity mindset
* Артем Соловейчик. Дизрапт и внутренняя свобода

Ждут своей очереди выступления: Валерии Терентьевой, представлявшей модель ценностных кодов, Сергея Градировского, Аркадия Цукера, Татьяны Мужицкой, Вани Молчанова, Арины Багаевой и еще несколько. Продолжение следует! А в группе ПИР многие делятся своими конспектами.

Марк Розин, отвечая на мой вопрос о его новой модели X-центричности компании новой статьей на своем канале, назвал меня «один из самых уважаемых теоретиков менеджмента». Очень приятно услышать такую оценку, учитывая многогранную и долгую деятельность самого Марка и его знакомство с ведущими консультантами и теоретиками менеджмента у нас и за рубежом. По ссылке https://www.tg-me.com/markrozinpritchy/113 можно прочесть преамбулу и кейс, показывающий как модель действует при изменениях и чем отличается от других моделей.

На школе Петра Щедровицкого «О праве войны и мира: «государство» и «государственность» на волнах промышленных революций» в Черногории была упомянута книга Лефевра «Алгебра совести», в которой построена теория взаимодействия между носителями разных этических моделей, как на уровне индивидуумов, так и на уровне государств и аналогичных общественных институтов. Я сразу прочитал вводные главы, в которых автором кратко рассказана структура книги и ее содержание, и понял, что попал: эту книгу надо внимательно разбирать, потому что в ней автор рассматривает много важных и сложных аспектов, которые в большинстве моделей вообще не рассматриваются.

Первый вариант разбора вы видите в этом посте https://mtsepkov.org/ConscienceAlgebra. Конспект получился не слишком подробный, а вторую половину я прочитал пунктиром, по диагонали. Но я публикую его сейчас, потому что переключаюсь на другие активности, и когда я смогу вернуться -- непонятно.

Что именно ценного я вижу в модели?

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

Основная ценность для меня -- методологическая: как можно учитывать все это большое количество аспектов. Я надеюсь в дальнейшем попробовать применить этот метод для Спиральной динамики и других моих рабочих моделей soft skill. А пока -- можно читать что получилось.

Недельный тур «Бирюзовый Китай», организованный Сергеем и Викторией Бехтеревыми («Бизнес со смыслом»), в замысле был посвящен знакомству с практиками самоуправления в китайских компаниях. Но по факту это было знакомство с разными высокотехнологичными, инновационными китайскими компаниями, с их культурой и практиками управления. Мы были в Baidu, Xiaomi, SenseTime, HD Education Group и BYD, всю поездку с нами была Леона -- основатель компании CirclePlus, которая ведет консалтинг по развитию предпринимательства и инноваций через механизмы самоуправления. Поездка дала много впечатлений об организации управления и культуре китайских компаний, и я делюсь https://mtsepkov.org/ChinaLeader

А если кратко, то в Китае создана эффективный гибрид государственной координации и свободного предпринимательства компаний, что позволяет уверенно говорить о нем, как о технологическом лидере новой промышленной революции. Китай умеет не только копировать, но и создавать технологии. А после обучения в западных университетах 80% сейчас возвращаются в Китай, потому что там -- хорошая инфраструктура и возможности. Отмечу, что за неделю до этой поездки я был на ежегодной школе Петра Щедровицкого, темой этого года было государство и государственность на волнах промышленных революций. И это наложило свой фокус при восприятии увиденное соотносилось с big picture развития мира и достраивало ее.

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

#sqadays Александр Александров, Антон Киселев. ИИ или не ИИ - вот в чем вопрос. Отношение к ИИ у Александрова -- очень человеческое, как у гуру к новичку: ты сначала подрасти, тогда я начну воспринимать себя всерьез. Может быть. И в репликах прямо звучат придирки: не всегда выделяет важное, не всегда точно формулирует. Как будто существуют люди, которые всегда все делают идеально.

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

Различие ИИ и множества предыдущих программ, которые Александров многократно упоминал -- в принципиальном подходе. ИИ, включая LLM -- учатся. Так, как учится человек.

Но вообще отношение или-или -- принципиально неверное. ИИ нацелен на помощь и сотрудничество, а об обмане его надо специально просить. Самое правильное отношение к нему -- ленивый студент-вундеркинд. Вундеркинд -- потому что он знает все предметные области. Любой сложности. А ленивый -- потому что отвечает часто «на отвяжись», первое попавшееся, фантазируя. Но всегда готов проверить собственный ответ, и его исправить.

Так что работайте в паре, как с помощником. А сэкономленное время тратьте на другие активности. И есть данные, что эффективность повышается кратно. Об этом в зале говорили.

Не только в разработке, но и в такой интеллектуальной работе, как разработка следующей версии системного подхода, применимого для личности и сообществ. Анатолий Левенчук начал этим заниматься с июня, Начиналась у него эта работа в июне, вот его пост https://ailev.livejournal.com/1768211.html, в этом посте https://ailev.livejournal.com/1772291.html он разбирает бригаду ИИ, с которой работает и метод работы, а вообще можно следить по блогу как оно развивалось, там интересно. В посте https://ailev.livejournal.com/1777877.html -- свежий статус, и там есть ссылка на сам фреймворк на Яндекс-диске, можно использовать. Это ЖЖ и историю можно смотреть по его постам, это работа этого лета. А один из последних постов Анатолия. где он показывает работу с примером реального промпта https://ailev.livejournal.com/1778864.html

И еще один совершенно прекрасный пример начинается здесь https://willie-wonka.livejournal.com/798911.html -- профессиональный филолог попросила ИИ перевоплотиться в Грибоедова и прокомментировать роман Тынянова о Грибоедове. Результат потрясающий, и дальше у нее серия разговоров с Радищевым и многими другими, читайте.

А еще в Китае, где я недавно был, мне в SenseTime рассказывали, что много людей общаются с их ИИ-помощником как с другом/подругой: ему первое приветствие как проснулся, беседа за завтраком, далее -- везде. И там отношение к ИИ принципиально иное: мы должны больше общаться с ИИ, чтобы он быстрее обучился, поумнел и стал лучше помогать нам. Это -- принципиальная культурная разница. На этом -- закончу.

Слайды моего доклада «Что такое – архитектура и как она влияет на тестирование» -- на моем сайте https://mtsepkov.org/ArchEA-SQA

#sqadays Иван Степнов из Test AI. Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA. Резкий контраст с предыдущим круглым столом. Люди настроены конструктивно. Они видят в ИИ потенциал и делают средства на основе ИИ. Создатели автотестов -- узкое место, их всегда не хватает. И они сделали продукт, который решает эту проблему: он берет тест-кейс для UI E2E тестирования, написанный на естественном языке, и ИИ-агент превращает его в автотест. И этим агентом могут пользоваться люди, которые знают продукт, и умеют тестировать вручную.

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

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

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

Отмечу, что в начале доклада был обзор исследований использования ИИ и различных средств, и был вывод из Google, что поскольку ИИ существенно меняет конвейер SDLC, и локальные изменения его разбалансируют, то задача комплексная: надо собирать новый конвейер, в котором люди и ИИ работают совместно. А авторы решили конкретную часть этой задачи: расшить узкое место создателей автотестов, которые в дефиците, и обеспечив, чтобы автотесты создавали ручные тестировщики совместно и ИИ.

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

Я с моделью Белбина знаком давно, рассказывал о ней на SQA еще в 2012 году, а в 2020 у меня был доклад на Teamlead с кейсами. Поэтому я прокомментирую отличия. Авторы сократили модель до 7 ролей: Координатор, Генератор, Аналитик, Исполнитель, Исследователь, Эксперт, Душа команды. У Исполнителя (он же Реализатор) есть важное отличие от Эксперта (Специалиста) -- он закрывает серые зоны, если это нужно для проекта, даже если этого не очень умеет. Надо поднять стенд -- поднимет. Надо с кем-то договориться -- попробует. Не будет говорить «это не мое дело». И в этом его основная ценность. Авторы исключили Шейпера -- вторая руководящая роль, человек, который ведет команду к результату на своей энергии. Думаю, это уместно, потому что тестировщики не делают независимых проектов, Шейперы в ИТ нужны на внедрении или в авральных проектах, когда надо личной энергией обеспечить продвижение. А вот исключение Педанта -- любопытно. Педант -- это человек, который помнит про хвосты и качество, и обеспечивает их достижение. Если он в команде -- об этом не надо помнить, а иначе надо решать административно. Но, наверное, если команда работает по таск-трекеру и снабжена чек-листами тестирования, то Педант действительно перестает быть необходимым.

Кстати, отмечу, что Белбин создавал свою модель для команд менеджеров, но для ИТ она применялась очень давно, я в свое время с удивлением опознал ее изложение в книге «Смертельный марш» Йордана, который ссылался на американского последователя Белбина. Кстати, книга -- актуальна до сих пор, как перечнем причин, по которым проваливаются ИТ-проекты, так и рекомендациям -- как в таком проекте работать.

#sqadays Екатерина Глушанина из 2ГИС. Помогите, Flaky! Флаки-тесты -- это тесты, которые иногда падают. По некоторым из них заведены тикеты, и ждут исправления. А задача -- в такой нестабильной ситуации не пропустить появления новых тикетов, чтобы именно они были подсвечены красным.

Для решения этой задачи сделали много workaround, реализованных через плагины в Allure, они выложены в open source -- можно использовать. Самое простое -- reruns, если 2 из 3 прошло -- считаем ок. Но бывает, что падение стабильно, и ждет тикета на исправления. Есть плагин, который игнорирует конкретную причину падения, указываемую в параметрах, делает тест хорошим.

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

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

#sqadays Vadim Nikitenko из Райффайзен. Генерация автотестов с помощью MCP + LLM. Доклад показывает механику создания тестов с помощью LLM. Для этого используется MCP-протокол, обеспечивающий взаимодействие LLM с внешними тулами, возвращающими динамический контекст. Работает так: сначала запрос пользователя обогащается список доступных тулов с описанием. LLM возвращает, что вызвать, выполняется вызов и результат добавляют к следующему запросу LLM как контекст. LLM может запросить несколько вызовов. Таким образом можно получить прогноз погоды. MCP-клиент и MCP-сервер легко написать самим, в докладе были примеры. И есть много готовых, в частности, для целей тестирования есть mcp playwriter, который умеет показывать структуру интерфейса приложения. В нем есть агенты (специально настроенные промпты), которые умеют создавать планы тестирования, создавать код по этому плану, а если тест упал и вы видите, что это ошибка в тесте -- есть хелпер, который может предложить исправления.

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

#sqadays Светлана Кочнева. "Жалоба как подарок" или системный подход к разбору претензий по качеству тестирования. К тестировщикам вечные претензии о том, что протестировано плохо. Это сильно огорчает. И периодически приходят мысли «что ж за дурацкую профессию я выбрала». В какой-то момент вспомнила свое детство. Когда была с бабушкой, которая работала продавцом в магазине, и ей говорили «хлеб черствый», «мармелада нет». Бабушка не переживала и говорила «напиши в жалобную книгу». Она вспомнила и вдохновилась.

Они завели специальную форму для заведения жалоб. Фишка в том, что ее можно быстро заполнить на основании инцидента -- и это не замена инцидента, а его продолжение. Назвали «эту ошибку могли найти». Идея: разработчик или руководитель проекта или кто-то еще может такую претензию оформить. Старший тестировщик смотрит, смотрит кто тестировал передает на анализ. Тот смотрит, предлагает пути решения. Дальше старший тестировщик смотрит на предложения, потом инициатор смотрит, если устраивают -- возврат.

Но появились проблемы. Тестировщик по задаче «проведи анализ и предложи решения» -- они не могут, два вердикта «виноват, больше не буду» или "не виноват, вы придираетесь".

Придумали список вопросов, и пока он отвечает -- проводит анализ.

* Время обнаружения на проде. Если инциденты пошли сразу после нового релиза -- значит тестирование недостаточно качественное. А если уже после релиза создали много заказов, и потом ошибка -- значит относительно качественное.
* Что могло побудить тестировать? Описано в регрессе, есть требованиях, есть анализ кода или взаимосвязей, или из опыта знают, что объект проблемный, и если тронул -- проверяем тщательно.
* Сложности с трактовкой требований. «Если согласование документа не выполнено в течении 7 дней, то отправлять уведомление...» -- дни календарные или рабочие? Инициатор думал про календарные, а команда -- про рабочие, как в других задачах.
* Категория ошибок: 0 -- не могло быть найдено (невероятный ответ из внешней системы), 1- низкая вероятность (на определенном наборе данных и т.п.), 2 -- можно было найти, популярная ситуация, 3 -- должна быть найдена (это было в регрессе или тест-кейсах, но пропустили).
* Пути решения. Чтобы предложить эффективные пути, нужно найти пути решения проблемы. Они рекомендуют пять почему. Не приходят уведомления -- потому что логика на рабочие дни -- это предположение команды -- в требованиях не указали -- почему взяли в работу. посчитали очевидным -- был упор на скорость работы. Проблема не в тестировании и в согласовании требований.
* Действия по результатам анализа: дописываем регресс; актуализируем тестовое окружение или делаем это чаще (например, эмулятор вместо реальной интеграции); работа с требованиями (доработка шаблона, мастер-классы и семинары, база хороших и плохих требований); использование ИИ (спросить его, пусть ревью сделает); создание базы пропущенных ошибок; доработка системы взаимосвязи между объектами (если меняется длина реквизита -- проверь печатные формы).

И дальше -- заполнение шаблона.

Проблемы.

* Бывает, что инициатор не согласен с результатом анализа. Перепиской не ограничиваемся -- обсуждаем.
* Бывает, претензия в смежных областях -- двое проводят анализ.
* Первый анализ -- с наставником
* Качественный анализ требует времени, его откладывают. Есть соглашение, что 7 дней, по относительно свежим следам.

За 6 месяцев 150 претензий, только 39 (26%) обоснованных. И это нормальное число, можно работать. По обоснованным -- разбор полетов, не поиск виноватого. По не обоснованным -- это все равно не оправданные ожидания -- надо смотреть, это может быть в смежных процессах, которые стоит улучшить.

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

Бороться с жалобами -- сложно, но их можно сделать полезными. И лучше превратить хаос и эмоции в логичный и прозрачный процесс.

#sqadays Ольга Артемьева. Между техникой и людьми: невидимая сторона тестирования. Великолепный доклад о переживаниях тестировщика, которые обусловлены профессией тестировщика и носят системный характер, и о способах их решения. Дальше -- конспект.

1. Мы приносим плохие вести.

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

Как проявлется в работе? «Мы обязаны успеть всроки», «Почему так много багов». И даже когда понимающая команда, багам не радуются. Тестировщики не радуются багам, особенно перед релизом.

Мы начинаем совмневаться в знаниям. Может, я излишне драматизирую. Был кейс, когда надо сказать менеджеру о задержке релиза. И менеджер говорит «а почему ты говоришь, ты что, в этом разбираешься?» Надо выдерживать свои и чужие эмоции, не выгорать.

Что делать?

* Аргументировать позицию на знаниях и опыте. Не просто «две недели». а «требует полного регресса, он занимает две недели, можно сократить, но риски»
* Искать поддержку. На сех действует групповая динамика.
* Брать паузу. Это дает время успокоиться и подготовиться, перевести эмоциональное в рациональное.

2. Невидимая работа в голове.

Превосходное и посредственное тестирование отличается тем, как вы это спроектировали. Это -- в голове, не видимо. Часто кажется, что тестирование -- среднее между магией и удачей, но это не так. «Просто потыкай», «посмотри аккуратно». В свое время пришла на вакансию «девочка с красным дипломом» -- чтобы была скурпулезна и усидчива, и не больше. А реально кроме внимательности и усидчивости нужно мышление. Его не видят. И это -- блоки. «Оля, ты умная, что делаешь в ручном тестировании?» И невидимая работа сложно планируется, поэтому многие тестировщики хронически перегружены, да еще говорят, что самое узкое звено. И не дают признания -- ведь работа простая.

Что делать?

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

3. Ответственность без власти.

Тестировщик как бы отвечает за качество, но он не имеет право исправить код. Он может лишь содействовать. Слова «за качества отвечает команда» -- красивые, но за баги на продакшене прилетает тестировщику, ответственности от тестировщика ждут «чтобы багов не было». А гарантировать, что багов не будет -- невозможно. А еще тестировщику отдают все не-техническое: написать release notes, подготовить материалы для продукта, проставить селекторы ко всем элементам -- для вас будет развитие.

В результате тестировщик -- мини-менеджер, но без власти менеджера. С непонятным кругом ответственности. А еще мы тревожимся пытаемся постоянно перепроверить.

Что делать?

* Согласовывать ожидания с командой. Баги -- будут
* Делегировать задачи назад в команду, release notes напишет любой
* Определить зону контроля
* Системный подход к работе с рисками: не только предотвращение, но и снижение вреда, что будем делать, если риск реализуется

4. Какую работу я приношу?

Часто говорят, что «когда разработчики делают работу хорошо, тестировщики не нужны». Но это не так, сложные баги -- все равно находят.

Когда с релизом все хорошо -- молодцы разработчики. Про то, как находили баги и исправляли -- не вспоминают. Еще стоимость: «разработчики не будут писать тесты, это дорого, пусть тестировщики тестируют».

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

Что делать?

* Записывать достижения -- мы забываем
* Провести мысленный эксперимент «а что если без тестирования», или даже уйти в отпуск.
* Право на уважение

Все это -- системный вызовы профессии.

Что сделать завтра?

* Достижение результата снова и снова. Запишите результаты за последние три месяца, и дальше ведите такой список. Можно посмотреть таск-трекер, мессенджер и другие артефакты. Или вспомните.
* Запишите в формате STAR(R): situation, task, action (что сделал), result, reflection (не обязательно). Например, приходит «будем сокращать TTM», вы сократили, багов больше, не улучшилось. Вы сделали чек-лист для отправки на тестирования, разработчики проходят -- сокращаются возвраты. Я тут замечу, что это похоже на протокол авторизации результата, о котором рассказывает Анна Обухова, и там есть две важные части: как достигнутый результат связан с крупными целями, и как я могу рассказать это другим -- это фиксирует историю в долговременной памяти как часть личной истории. Возможно, это входит в result и reflection, но тут важные акценты. И у авторизации результата есть негативный вариант, чтобы отпустить неудачу.
* Нарисуйте круги влияния. Контролирую то, что делаю сам, например, как заполняю баг-репорты. А если решение о допустимости выпуска принимаете не вы, то вы влияете, но не решаете. Внешние обстоятельства -- не них не влияешь.
* Запланируете способ, как сделаете работу видимой -- на доске, в виде артефактов и так далее. Сделайте презентацию для коллег: что входит в тестирование, почему занимает столько времени, что даст автоматизация.

#sqadays Сергей Атрощенков. Нейроохота на баги: что происходит в мозге тестировщика? Интересный доклад про работу мозга и когнитивную нагрузку тестировщика. У Сергея диплом психолога, был модуль нейропсихологии, ему было интересно, увидел реальные научные исследования, сейчас магистратура нейропсихолога.

Тестирование -- сложная когнитивная деятельность. Оно посложнее многих других дисциплин в ИТ.

* В нем много анализа -- работа с требованиями, проектирование сценариев, предсказание работы системы.
* Тестирование -- под постоянным давлением
* Много коммуникаций
* Абстрагирование -- в ширь, вглубь, в стороны
* Мозг -- чтобы выживать, а не тестировать софт.

Зачем нейрофизиология? Тестирование -- не чтение кода, не только на уровне логики. Читая код, задействуем левое полушарие, при тестировании -- задействуем правое. Задействуется нейронная сеть, которая работает для логики и математики. Мозг работает так. То есть при тестировании мы решаем задачи.

* Мозг имеет свойство уставать, это нормально. И он устает от тестирования.
* Рабочая память ограничена.
* Вовлечены сознательные и бессознательные процессы.

Есть исследования, которое показало,что люди, у которых выше объем памяти, более успешно справляются с задачами тестирования -- находят больше багов, которые нетривиально найти.

Когнитивный цикл тестирования.

* Планирование -- фронтальная кора
* Теменная доля -- внимание и рабочая память
* Понимание контекста -- височная доля
* Обнаружение аномалий -- передняя островковая доля

Когнитивная нагрузка. Память занята: система, ожидаемый результат, возможные креш-кейсы, часть архитектуры системы, бизнес-поведение системы. Минимум 5-6 элементов. Детальные тесты разгружают память -- но увеличивают ttm, нужен баланс. Если вы решаете задачу, а вас грузит менеджер -- печалька, перегруз.

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

Как прокачивать опыт. Можно поучаствовать в теневом режиме как разработчик или аналитик. Разработчик дает задачу тестировщику и они в паре делают, потом тестировщик полностью делает, только результат. И в продуктом -- бегать по всем встречам, и расширяет познание. Если такого нет -- то хотя бы из другого домена. Это позволит превратить интуицию во что-то осознанное.

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

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

Когнитивные ловушки. Докладов -- множество, и их 200+. Он выбрал три, которые редко упоминают.

* Ловушка подтверждения. Проверяем только happy path -- хотим подтвердить, что работает. Особенно в ограниченном времени.
* Доступность. Полагаемся на баги, которые нашли, и смотрим в эту область. Не обращаем внимания на другое. Например, на тестирование формы, при том, что перепутали логотип.
* Якорение. Фиксируемся на первой проблеме. Нашли баг, не понимаем с чем связано, идем к разработчику, в чем причина -- исследуем, долго, не находим проблемы -- потому что проблема в другом месте.

Что с ними делать? Якорение -- строим равномерное покрытие, структурирование подхода, кросс-ревью тестов. Ловушка подтверждения -- шесть шляп, меняем позицию. Доступность -- чек-листы и все то, что делает тестирование скучным.

Ловушки не приговор. Мозг может обучаться. Проводили МРТ студентов, обучение программированию увеличивает количество серого вещества.

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

Различие мозга между разработчиками и тестировщиками -- есть исследование. В частности -- разработчики менее дисциплинированы, чем тестировщики. Там интересный слайд, надо будет посмотреть.

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

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

Спасибо Сергею! А нейрофизиология -- очень интересно, и психологам пора бы пересобрать свои модели на их основе. Но они не торопятся, так что мне пришлось самому, получилась книга «Инженерная модель личности».