#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, где когнитивная нагрузка выше, но есть эмоции. Подкрепление можно научиться выдавать себе самостоятельно, или получать через похвалу.

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

Опубликовал отчет https://mtsepkov.org/SQAdays-2025b: собрал посты-конспекты с конференции #sqadays и дополнил их теми докладами, по которым не успел опубликовать отзыв во время конференции. Среди дополнений -- прекрасные доклады Дмитрия Воробьева и Натальи Руколь, а всего в отчете 14 докладов, среди которых еще отмечу доклады Ивана Степнова, Сергея Атрощенкова и Ольги Артемьевой.

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

Воспользовался праздниками и обработал те заметки с ПИР, по которым не успел опубликовать конспект https://mtsepkov.org/PIR-2025. Новые выступления: Марина Починок, Татьяна Мужицкая, Анатолий Коротков, Ваня Молчанов, Арина Багаева, Катерина Медведева, Михаил Кларин, Галина Лебедова, Аркадий Цукер, Мария Мирова и Оксана Унтилова (путешествие на Аляску), Анна Шатилова, Сергей Градировский и Валерия Терентьева. Они дополнили то, что было раньше: Гарретт Джонстон, Андрей Комиссаров, Анна Валл, Марк Розин, Сергей и Виктория Бехтеревы, Сергей Бочаров, Нюта Федермессер, Дмитрий Сендеров, Елена Черникова и Артем Соловейчик. Всего в конспекте 24 выступления, которые я слышал за 4 дня.

Опубликовал отчет с #Highload https://mtsepkov.org/Highload-2025 Я был только один день, в четверг, поэтому докладов немного. Основное, что я вынес -- совершился переход от конкретных проектов на основе ИИ к включению приложений с ИИ в ИТ-ландшафт, и связанный с этим переход от DevOps к ML-ops. Отмечу, что тема была продолжена на #ArchDays, на которой я был в пятницу, ждите отчет. Там был доклад Газпром Нефть, где они поделились архитектурными схемами, используемыми для построения такого ландшафта, и еще ряд интересных докладов. А пока -- читайте про Highload. Ну а в понедельник-вторник я на #Teamlead

#ArchDays продолжило тему встройки приложений с ИИ в ИТ-ландшафт. Александр Войновский и Олег Зоткин из Газпром Нефть показали свои архитектурные схемы для такого ландшафта, Руслан Серкин рассказывал о том, какие технические долги ИИ помогает разгребать, а какие -- приносит, а Павел Кан рассказывал про построение систем на основе маленьких специализированных моделей. Но были и чисто архитектурные доклады, среди которых надо отметить рассказ Сергея Баранова про экономические аспекты архитектурных решений со вполне годными моделями и, главное, кейсами оценки конкретных решений. Читайте отчет https://mtsepkov.org/ArchDays-2025

Слайды моего доклада -- на моем сайте https://mtsepkov.org/ArchEA-AD Кейсы для мастер-класса мы будем выбирать из предложений участников, нужен кейс, который не требует многих подробностей: его можно рассказать с нуля и накидать бизнес-процесс за 5-10 минут. Разбирать будем один кейс, но у меня можно получить консультацию по вашим кейсам в перерывах или на афтерпати.

Интернет принес прекрасную статью про матан https://habr.com/ru/articles/964282/ - там разные модели объяснений. Прочитал - вспомнил эти констркуции. У нас, кстати, использовали оба языка, по Коши и по Гейне, и тренировали переходить между ними. А в математическом кружке при Университете (старшая школа) мы развлекались, доказывая всякие свойства вполне упорядоченных множеств и всюду плотных множеств, выводили теоремы про действительные числа из определения такого числа как последовательности десятичной записи с эквивалентностью (0) и (9), и много другого. До сих пор жалею, что задачи я кому-то отдал и оно пропали...

Перед выходными публикую свои впечатления от докладов на #Teamlead https://mtsepkov.org/TeamLead-2025-Msk -- читайте! У меня, правда, получилось быть только на небольшом количестве докладов, потому что на конференции было очень много знакомых и хотелось пообщаться. Тем более, что у меня в этот раз была интересная тема разговора про впечатления от поездки в Китай. Об этой поездке я на конференции давал интервью, оно было в общей трансляции, и потому в конспект включил тезисы: интервью короткое и все обсудить не успели. А еще в конспекте про совершенно неожиданное для меня выступление Александра Зизы про эмоциональный интеллект, Анны Обуховой про счастье, Алексея Рахманова про использование ИИ для решения задач техлида, Марии Седяевой о производстве мультфильмов по scrum, а также о выступлениях Рустама Агамалиева, Анатолия Дробкова, Мити Кожевникова и Андрея Волкова. Всем хороших выходных!

Публикую отчет https://mtsepkov.org/AnalystDays-2025b с конференции AnalystDays для меня оказалась очень содержательным завершением темы ИИ на осенних конференциях: SQAdays, Highload, ArchDays и Teamlead. Основных векторов развития два: (1) приложения с ИИ научились технологично встраивать в ИТ-ландшафт наряду с обычными приложениями, переходя от DevOps к ML-ops и (2) LLM успешно работает как индивидуальный помощник или специализированный функциональный агент, и теперь пора переходить к проектированию команд и компаний в целом с участием ИИ-агентов. На Teamlead я смог сформулировать: широко вещаемая цель замены людей или команд разработки на ИИ-агентов -- ложная, ведь никто не ставит целью собрать мощную команду из джунов, а ИИ по многим характеристикам пока именно джун. А вот задача эффективного включения в команды и компании ИИ-джунов с уникальной компетенцией быстрого доступа к любым знаниям мира, которая присуща LLM, в отличие обычного джуна -- вполне разумная и содержательная. И именно этот вектор получил развитие на AnalystDays в визионерском выступлении Димы Безуглого, который рассказывал о таком направлении развитии и о возможном месте аналитика в новом мире. А еще у Димы было гротескное представление мира ИТ, где менеджеры, не видевшие клиента и не знающие как работает система, ставят задачи разработчикам, не знающим ничего о компании.

Помимо выступления Димы, про ИИ я слушал Reydan Yasar, Анну Гурову, Дарью Рассказову и Елизавету Французяк. Кроме того, я хочу обратить внимание на выступления Анны Обуховой, которая впервые показала схему дофаминового пути мозга с уровнями энергии, Сергея Баранова, продолжавшее тему стоимости архитектурных решений, начатую на ArchDays, Светланы Дорониной с интересными кейсами для аналитика. А вообще все выступления, которые я слушал, были интересными, ПК конференции собрали хорошую программу. И мастер-классов тоже было много.

В прошлую пятницу 28.11 участвовал во Фронтире с Сергеем Бехтеревым, посвященном поездке в Китай, делился впечатлениями вместе с Сергеем и Марком и Натальей Кукушкиными. Был очень интересный разговор: хотя мы все были в поездке, и общее впечатление -- совпадает, было много деталей, которые дают важные акценты. Мы запомнили разное, а обсуждение вместе дало синергию. Запись ожидается, она будет опубликована на канале (на него ведет ссылка), а пока я решил поделиться своими тезисами. Думал ограничиться постом, но получилось много букв, поэтому читайте на моем сайте https://mtsepkov.org/FrontierChinaLeader, А мой отчет https://mtsepkov.org/ChinaLeader

Я верю в знаки судьбы. Поэтому когда сегодня утром я полез читать блог Анатолия Левенчука и увидел, что сегодня будет семинар по FPF-фреймворку, то собрался и поехал. Почему это -- знак судьбы? Потому что я смотрю блог Анатолия раз в пару месяцев, и то, что посмотрел столь во-время -- совпадение, счастливый случай, который позволил мне узнать новое. По свежим следам я написал отзыв, как у меня часто бывает, вместо пары абзацев получилось 5.5к знаков, поэтому читайте у меня на сайте https://mtsepkov.org/FPF-2025-12

А здесь коротко замечу, что First Principle Framework -- разработка Анатолия, с помощью которой он добивается от LLM системного мышления, а не попсовых рассуждений. Она выложена в открытый доступ на github и подключается к LLM подгрузкой файла (но LLM должна быть достаточно сильной). Так что вы можете сами пробовать использовать. Правда, для этого желательно самим разбираться в системном подходе, иначе у вас не получится задавать адекватные вопросы, а каков вопрос -- таков ответ. Я думаю. среди моих читателей много тех, кто проходил обучение на курсах Анатолия. а если нет, то руководства доступны бесплатно после регистрации на платформе https://aisystant.system-school.ru