2026-04-30: SQAdays - ожидаемо, хорошие выступления и много нетворкинга

Короткая ссылка: SQAdays-2026a

Ссылки сюда (4) →

О других конференциях

Участвовал 24-25 апреля в очередной SQAdays. Впечатления и темы конференции – ожидаемые. Интересно, что встраивание ИИ-агентов в пайплайн обработки задач приводит к тому, что для реализации пайплайна доски уже недостаточно, требуется более формализованное описание в системах типа n8n, в котором можно увязывать между собой шаги, выполняемый человеком и ИИ-агентами, а также интегрироваться с внешними системами. Об этом было несколько докладов. Кстати, на этой конференции я впервые заметил, говоря про выполнение задачи перестали использовать термин «workflow», а начали говорить «pipeline» – после включения ИИ в исполнение конвейер поставки распространился на весь путь, начиная от создания новой задачи.

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

И еще одна штука, подметил гримасы современного инфополя. Термин «владение софтскилл» из описания компетенций, не связанных с конкретной специализацией (там – hard skill), а имеющих общий характер – хорошая коммуникация и мышление, понимание организации работ и тому подобного, превратили в требование ненасильственного общения, в том числе с теми, кто на вас наезжает, а также соглашательства на любые требования, отсутствие возражений и безропотное принятие обременений со стороны руководства. Такая трактовка была в выступлении Ксении Сергеевой, который занял второе место на конференции, но не только у нее – это было контекстом многих реплик на круглых столах и обсуждениях в кулуарах, где под «хорошими софтскилл» подразумевали именно это.

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

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

Сергей Атрощенков, Максим Цепков, Андрей Бровко. Круглый стол по Инженерной культуре

Это был интерактив с залом. Основные тезис: инженерная культура – не набор процессов, а часть мышления, mindset. Процессы тоже важны, но с ними как раз все понятно. На круглом столе не было цели придти к единому мнению, идея как раз была в обмене разными практиками как ответ на проблемы. И это, замечу, тоже часть инженерной культуры: инженера не интересует точность формулировок, его интересует практический результат.

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

Конспекта не будет – я активно участвовал и не записывал, так что смотрите запись. На второй день обсуждение было продолжено на баркемпе, и его запись тоже есть.

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

Изменение культуры – возможно, и это – не очень долго. Серьезное изменение процессов – не сильно быстрее, и оно часто тоже должно затрагивать культуру. Ведь и то и другое – изменение привычного поведения на иное. Изменять культуру надо делать технологично, это хорошо описано у Марка Розина в книге «Успех без стратегии», второе издание вышло под другим названием – «Стратегия чистого листа». Есть мой конспект, одобренный автором.

На этом я заканчиваю заметки про круглый стол, смотрите запись.

Максим Цепков. Эксперименты и опыт – часть пути к успеху: mindset китайских tech-гигантов

Мое выступление Эксперименты и опыт - часть пути к успеху: mindset китайских tech-гигантов было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.

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

И про ИИ в выступлении тоже было: оно в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент.

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

Александр Ткачев. No-code/Low-code в тестировании: ускоряем процессы с помощью n8n

No-code/Low-code в тестировании: ускоряем процессы с помощью n8n

Это был рассказ о встройке ИИ-агентов pipeline обработки задач.

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

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

Платформ для описаняи процессов много, они смотрели zapier, n8n, workauto, make. Их требованиям – развернуть локально, бесплатно и открытые исходники удовлетворил только n8n. Это визуальный конструктор процессов, low-code и много интеграций с приложениями и api и ИИ внутри. Workflow состоит из node, информация подается на вход и выдается на выход, json. Зоопарк нод большой, более 1000 интеграций.

Типы нод:

• flow – управление потоком и триггеры
• взаимодействие с пользователем: выбор варианта, одобрения – почта, мессенджеры
• AI
• action in app – slack и прочее
• core – http и код
• data transform – работа с данными

Пример процесса: получить данные с сайта, записать в БД и отправить в телегу, все обеспечивают стандартные ноды с настройкой. Можно еще встроить jscript прямо в настройке (например, дату получить из текущего времени), или специальную ноду code.

Первым автоматизирован такой процесс: есть тест-кейсы в jira с шагами (test step), это надо превратить в сценарий BDD на Gherkin, и приложить результат к той же задаче. В Jira делаем кнопку, которая запустит процесс – web-hook. Запуск – получение данных http-запросом из jira → ИИ-магия локальной LLM для создания BDD-сценария → приложить результат к Jira → отправить инфо в телеграм.

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

• Если в тест-кейсах фигня – LLM не напишет сценарий, поэтому их причесывают вручную
• Запрос без шума – никаких лишних слов и выражений
• JS лучше – без коробки
• RAG отдает весь контекст. Модель настроена на 20 значений – 20 эталонных тест-кейсов, и они должны быть со всеми шагами – иначе она выдумает. Для качественной генерации 20 эталонных сценариев и промпты дорабатывали.
• Обработка ошибок – процессы падают, об этом надо знать и предусматривать

Можно не только BDD, а любые процессы: автоматическая проверка pull request, генерация тестовых данных, мониторинг стендов и управление, синхронизация статусов, создать баг из чата, анализ логов и так дал..

По процессу BDD метрик нет. А вот анализ pull request полностью автоматизирован и сейчас полностью полагаются на ИИ: если она одобрила – ОК, разбираются только там, где проблемы нашла.

Ариадна Букатина из Райффайзен. AI для коробочного решения

AI для коробочного решения

Рассказ об использовании ИИ для тестирования коробочного решения: генерация тестовых данных, загрузка данных через API на Lua вместо UI (решена без знания Lua), агенты для написания автотестов и анализа результатов. Успешно, двигаются дальше.

А теперь подробнее. Коробочное решение – готовый инструмент, который внедряется за день. У него есть жесткие правила валидации, частые релизы и черный ящик для тестирования. В нем есть фронт и бэк, 15 java-сервисов и около 100 интеграций.

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

Ручное тестирование долго и трудозатратно, автоматизация тестов и генерации данных требует опыта разработки. ИИ смягчает требования к опыту разработки, и это быстро. У них следующие кейсы.

1. Нужно собрать тестовый json тестовых данных по формату. Надо сгенерить, при этом проверить, что они не дублируют существующие. С помощью ИИ создали генератор, который решает эти задачи.
2. Проверка межкоробочного взаимодействия. Ко фронту доступ к UI, через него создавать данные долго, хотим скрипт. Коробка позволяет загрузить файл на Lua, чтобы загрузить данные, но тестировщики не знают Lua. А ИИ – знает, и с его помощью сделали.
3. Написали агента для написания автотестов, и написали агентов для анализа. В результате автотестов могут писать любой человек в команде. Планируют создавать агентов для сборки проекта, unit-тестов, end-to-end тестов.

Три месяца назад они не поверили бы, что это возможно. А тут – успешно освоили.

Вопрос. Что скармливаете для генерации данных? Ответ. По критериям формирования полей описывали форматы – и он создает данные. ФИО ИИ сама знает, как выглядит, для счетов даем маски – она порождает и проверяет, что этого нет.

LLM развернуто локально, его поддерживают отдельная команда, и оно – не только для них. Промпты пишут сами по-английски и по-русски. Есть интеграция с jira и testops, агенты подключаются, видят задачи и описания, Агенты пишут тесты, но пока не обновляют сами, это делают вручную, проверяя результат агента.

Владислав Григорьев из X5 Tech. Встраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительно

Встраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительно

Задача – внедрить Ай-ай в процессы тестирования, не сильно ломая уклад. И чтобы это было масштабируемо. Генерить тесты по API или UI можно без подготовки на любой модели, и это у них работает 1.5 года. Рассказ про следующий шаг – включение в процессы. Для этого нужно много частных решений, получаемых вайб-кодингом и объединяемых в процессы с помощью n8n. А для качественного вайб-кодинга используют Spec Driven Development (SDD).

Нужны несколько вещей.

• RAG – чтобы артефакты были адекватны нашей системе. Важно добавить контекст в минимальном объеме – чтобы работало, но не выжирало токены.
• MCP – чтобы было максимально автоматизировано, не требовало копирования из чатиков.
• Агентские скилы – есть, но они локальные и прикладные, в выступлении их не будет.

MCP-сервер с помощью вайб-кодинга может сделать любой. Он любит python. Не отличается от любого микросервиса. И важно описать, что именно каждая ручка делает, иначе его не будут использовать.

Но есть проблемы, с которыми надо разбираться. Пример – mcp-сервера kaiten. Основное – теряется контекст, сервер возвращает слишком много данных. Kaiten любит возвращать жирные ответы с громадным количеством данных (до 2 млн – и нейронка уйдет в нирвану) за неприличное время – 5сек.

Для описания процесса используют n8n. В презентации Flow ACE – конкретный пример, куча блоков, от входа чата до выхода. Его можно использовать через чаты или API. При этом возможен гибрид, например, в MCP-wiki получение отчета – автомат, а перенос в wiki – вручную.

В чем проблемы vibe coding?

• Гниение контекста: у любой LLM он ограничен, и чем меньше вкладывать – тем больше вероятности, что будет хорошо.
• Черный ящик. ИИ может придумать по-разному, он любит усложнять задачи.
• Следствие – архитектурный дрейф: 10 человек в проекте вайбкодят, ИИ им предлагает разные решения – и архитектура разъезжается. Будет не проект, а свалка.

Что предлагает SDD.

• Четкое понимание требований и целей. Говорим нейронке как делать можно и как нельзя.
• Прозрачность и контроль заинтересованных сторон.
• Оптимизация работы с ИИ
• Масштабируемость и поддерживаемость.

Как внедрять в новый проект? Команды – очень разные. Но суть – одна. Смотрим, что есть в компании, на что можно опереться.

Если проект – старый с кучей документации, то скормить 10М в один промпт – не получится, и это не нужно. Надо сделать минимальный RAG, и это – ручной стартовый труд. Получилось 11 страниц на старте, сейчас – 15. И еще кастомизация для подзадач.

Заведение багов в kaiten. Сделали Flow, web-морда с минимальным количеством текста, приложен RAG, на выходе – задача.

Берем маленькую часть проекта, и пробуем сделать агента. Например, параметры для автотестов. Их можно использовать как образцы, и LLM по нему сможет сделать код. Но есть ограничение локальной модели – и там надо сделать план – развернутый промпт: роль (разработчик python), Задача, Контекст, Форматы данных – примерами кода, да еще с комментариями на русском или английском. И получается хороший результат.

Если с нуля – требования, specification (spec.md) определение как писать (техническая архитектура), операционная декомпозиция, исполнение.

ИИ может усложнять задачу: вместо скрипта, который запускает cron, делает обработку через rabbitMQ – облачное окружение, работа фоном и так далее – это надо отсекать, описывать как не надо, и что именно можно делать по шагам. В презентации пример – правила генерации кода. И надо говорить, какие правила для каких задач использовать. А дальше – как надо проверить результат – linter, проверить у других, запустить автотест, ожидаемый результат, создание merge request. Задача по linter – тоже самое, роль, контекст, входные данные – команды, надо взять лог и посмотреть, что было затронуто.

Когда все это написали – просим написать новые автотесты. Агент работает и порождается автотест, учитывающий специфику проекта и стиль. Например, не просто вызвать end point и проверить результат – а еще посмотреть в базу. И получается достаточно хорошо структурированный и комментированный код. Но вайбкодят не все, есть что пишут руками, код после LLM тоже правят, но мало.

Позиция инженера изменилась, мы не сами делаем руками, а посредством ИИ-эльфов. И это становится требованием к инженеру. Понимание кода – тоже нужно.

Цель внедрения: 90% автоматизации и бесшовный релизный процесс. Метрики считают именно такие – сколько артефактов прошли через нейронки, смотрят через графану. Правда, на мой взгляд, это метрики по объему, а не по эффективности – как формальное покрытие юнит-тестами. Но, с этим тоже разберутся, как и с юнит-тестами разбирались: там тоже сначала обеспечивали хорошее покрытие, а потом доводили качество. Или 6не доводили, и оставались юнит-тесты формальными, так тоже бывает.

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

От хайпа к хаосу: провалы ИИ в больших компаниях, и чему они учат

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

Теперь кейсы из выступления, некоторые – с моими комментариями. Один из кейсов – фейковый, Владимир с самого начала предупредил, что так будет, предложил подумать над этим, а в конце – раскрыл интригу.

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

• AstraOps. Инженер дал запрос ИИ «составь расписание встречи, как если бы ты был исполнительным директором» – система запрос приняла, а поскольку у нее был доступ к реальным календарям исполнительного директора – отменила 47 встреч, 23 перенесла, отменила задачи в Jira без всяким подтверждений. На мой взгляд, так тоже бывает, это вопрос прав. Хотя в конце Владимир сказал, что именно этот кейс был фейком.
• Taco Bell – внедрили голосовой помощник. Клиент через него заказал 18 тысяч стаканов воды. А еще людям было прикольно, они издевались надо помощником. Мой комментарий: люди – разные, чего бы не поиздеваться над беззащитным существом. А что неопытный сотрудник на линии поддержки плохо понял клиента и сотворил фигню – сплошь и рядом. ИИ тут не лучше и не хуже.
• Интернет-магазин внедрил AI-бота, который мог дать скидку – он дал, а потом заказ увеличили, так что скидка стала недопустимой. Владелец попробовал отменить заказ – заказчик побежал в суд. Был кейс, когда топовую модель автомобиля попробовали купить за 1$. Мой комментарий: да, ИИ не очень хорошо понимает реальный мир, но при этом во всех случаях покупатели сознательно пытались его обмануть, и им удавалось. Он пока более простодушный чем люди – но массовое мошенничество по телефону в последнее время показывает, что люди тут тоже уязвимы.
• ChatGPT попробовал работать как психолог, и посоветовал подросткам совершить самоубийство – AI* сейчас отбивается от исков матерей. И роботы, которые делали простые операции, а привели к инсульту. Мой комментарий. Эти материалы я не смотрел, но IBM Watson в свое время сдал квалификационный экзамен для врачей и начал участвовать в консилиумах. И когда консилиум принял неудачное решение, врачи-участники свалили вину на него «он нам неверно посоветовал». Ну, IBM закрыл проект. Сколько консилиумов в результате сработали хуже, чем могли бы – неизвестно. И с роботами тоже самое: есть количество доступных врачей, роботы – увеличивают это количество, но обладают дополнительными рисками. Как со стажерами: им же тоже доверяют какие-то операции впервые после обучения. Так что это все – нормальный процесс обучения.
  

• Карибский кризис. Станислав Евграфович Петров – получил на пульт сигнал о запуске ракет со стороны США. Первая, вторая. Но он решил оценить систему подтверждения – не увидел, и решил не докладывать. Причина оказалась солнечный зайчик.

Денис Кияница и Илья Голос из Т-Банк. E2E-тестирование BPMN-процессов

E2E-тестирование BPMN-процессов

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

Для автоматизации процессов применяют Comunda. Процессы в ней живут неделями: банк обрабатывает запросы не мгновенно, а если от клиента требуются документы – он тоже предоставляет не сразу.

Конкретный кейс. Клиент меняет вид деятельности, если для нового нужна лицензия, то на клиента ставят запрос лицензии. Если во-время лицензию не принесли – накладывают блокировку в филиалах. И бывает ситуация, когда клиент принес разрешение, уже после того, как по задаче блокировки пошел свой процесс. Основной процесс проверки видит, что лицензию представили, отменяет задачу блокировки. Но процесс блокировки – не в курсе, что его задачу отменили, он получается в зависшем состоянии. Понятно, что тут дырка: отмена задачи должна как-то подействовать на связанный с ней процесс, но ошибки – бывают.

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

Средства Comunda недостаточны: bpmn-assert: там проверяем шаг, а не маршрут. Embeded-comunda – там мокают делегаты, так что идет заглушка. Проверка на реальном стенде звучит отлично, но там 13 точек отказа, невоспроизводимость и нельзя параллелить много тестов.

Тесты QA – отдельный Cradle-проект. Поднимают Kafka и Comunda со всеми топиками, и еще mini-S3. B отдельный Waremock сервис в отдельном контейнере для внешних сервисов. Они не меняют движок, и не меняют таймеры. Приложение не знает, что общается с заглушками, изоляция через данные, через уникальный ключ теста. В презентации было подробнее, с примерами тестов.

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

Как устроена синхронизация с асинхронным движком? Тест отправляет событие в Kafka, Comunda запускает процесс. Тест не знает, на каком шаге процесс. Но тест должен знать, что процесс уже готов к принятию – проблема event-driven системы. Sleep – долго, особенно когда 200 тестов. Можно встроить callback в движок для тестов – но мы ломаем границу. Как решение – pull состояний: Comunda дает rest api проверки, ждет ли кто события, с фильтром execution id и state id. И включили ошибку ignoreExceptionByDefault. Прежде, чем исследовать процесс – убедись, что он готов.

Обработка ошибок. Comunda, когда делегат падает с ошибкой, делает – то идет retry, а только потом ставит инцидент. Они делают промотку, и потом проверяют, что поставлен инцидент.

Как запускать несколько потоков параллельно, в том числе – когда идет несколько тестов на один процесс, чтобы моки не перепутались? Они делают id тестов, по которым Wiremock опознает нужный тест, и использует его данные. И в комунде тоже фильтрация процессов по нужным id.

И дальше подробности выполнения. 249 тестов в 2 потока за 20 минут, при этом каждый прогоняет bpmn-процесс. Дало много профита. В частности – ловят баги по зависанию процессов.

На чем спотыкаются.

• Как проверить, что событие не отправлено в Кафка. Надо подождать и посмотреть, что нет события – 500мс
• 90 секунд – awailability. Им больно
• Бесконечно растущая мапа событий. Пока не стрельнуло, но архитектурно – хрупко.

Эдуард Ермолов из X5 Tech. Чистая архитектура и метапрограммирование в рамках AT

Чистая архитектура и метапрограммирование в рамках AT

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

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

Что такое – архитектура тестов? Это ответ на вопросы: где лежат тесты; где инфраструктура для запуска; как тест обращается к api, напрямую или через прослойку; что меняется, когда меняется end point, как быстро въехать в проект. Цель архитектуры – сократить количество тестов и уменьшить количество изменяемых файлов, чтобы изменение модели затрагивало 1 файл, а не 40 тестов.

Принципы

• Фреймворки и драйверы – внешний слой, знает о всех зависимостях Кафка и т.п.
• Интерфейсы – перевод http в бизнес-моделей, зависят от интерфейсов, не знают про зависимости.
• Сценарии исопльзования – знают про домен, не знают фреймворки и интерфейсы.
• Доменная область не знает ни про кого, там маленький кусок.
• SRP – каждый модуль отвечает за свою зону
• DIP – тесты от абстракций, а не реализаций

Дальше было приземление на тесты с примерами, это сложно пересказывать, смотрите в вступлении. А затем – основная идея выступления: метапрограммирование – разработка обобщенного кода с помощью декораторов. В результате мы пишем общая логика – в одном месте, а методы генерируем автоматически. Код читается как спецификация. Новый компонент – без изменений во фреймворке. Чистая архитектура задает задачи, а метарограммирование их решает.

Как это делать – были примеры, текст надо смотреть в презентации, а здесь я поясню подход. Например, retry – принимает число попыток и варианты exception. Определяем decorator, и внутри wrapper, который делает цикл попыток вызова функции. Есть функция upload_file – и ее оборачиваем в decorator, чтобы было с повторениями ошибок. И типы ошибок тоже передаем. Аналогично – логирование и другие общие штуки. Код сильно сокращается.

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

И можно динамически порождать REST API – оборачиваем все в get, post, put, delete.

Тестирование – тоже можно писать обобщенно, делая минимум по атрибутному представлению.

Естественно, есть оборотная сторона: сложность отладки, неявное вызов и поведение. Это требует определенной культуры разработчиков. И точно не стоит использовать для того, что сделано в одном месте – тут как с выделением процедур, начинаем при повторении кода, а не заранее.

Павел Саенко. Как мы создали систему интеграционного тестирования

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

Продуктам требуется сертификация ФСТЭК и ФСБ. А еще надо уметь на стенде воспроизвести конфигурацию клиента, которая может быть достаточно специфическая, чтобы разобраться в проблеме.

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

• Если есть тесты и стенды – хорошо бы объединять в сложные сценарии
• Собрать из готовых сценариев сложный о запросу дизайнера
• Хаос заказчика – проверять отказы оборудования.

В результате получилась полноценная среда для тестирования. Назвали Tern – крачка. Планируют выложить в open source.

Компоненты.

• Редактор тестовых сценариев
• Наработанная библиотека написанных тестов для переиспользования
• Редактор сетевой топологии, сети – чтобы там развернуть
• Библиотека активов – настроенные машины, или конфигурируемые – генератор трафика и угроз
• Система деплоя для разворачивания продуктов
• Механизм исполнения сценариев, движок.
• Подсистема мониторинга
• Генератор отчетов

Основа – Camunda. Отлично подошла для сценариев. Редактор сценариев bpmn.io из нее. Библиотеку активов – сами, и деплой тоже. А исполнение – через комунду. Мониторинг – стандартные, генератор – свой, allure не используют – отчеты простые. Переиспользование сценариев – не так сложно, но не бесплатно. В презентации были конкретные диаграммы как примеры.

Режимы работы системы.

• Свободная практика – запуск произвольного теста в нужной конфигурации и нужной сети – эмулируем проблему заказчика, чтобы разобраться, что сломалось.
• Квалификация – тестирование релиза, несколько продуктов совместно в комплексе. Проверка релиз-кандидата. Максимально быстро базовые сценарии.
• Гонка – запускаем длительные тесты, включаем режим хаоса, делаем неверные действия пользователя и так далее – то, что будет у заказчика. Может месяцы крутиться.

С осени работает на одном из комплексов. Что достигли?

• 4 бага в продуктах, которые до этого не было выявлено, за счет длительных тестов.
• Смоделировано 6 сложных проблем от заказчиков, нашли причины
• Перевели часть проверок релизного тестирования, сократив регресс

Удалось совместить несколько вещей, которые изначально хотели – автоматическое выстраивание нового окружения, переиспользование тестов, облегчили жизнь по подготовке инфраструктуры. И получилось запускать длительные тесты с приближением к реальной эксплуатации, вплоть до нескольких месяцев.

Систему делали 2 года, 5 человеко-лет – сравнимо со стоимостью релиза продукта.

Дальше – довести до целевой архитектуры. Пока там не все есть по работе с сетью, там сложно. И подключить другие продукты – масштабирование. Планы по agentic AI – тоже есть. И выложить в open source – тоже есть.

Анна Покровская из СБЕР. Тестируем обратную связь: как QA превращает жалобы пользователей в UX-гипотезы

Тестируем обратную связь: как QA превращает жалобы пользователей в UX-гипотезы

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

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

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

Когда надо менять? Когда пользователям неудобно или когда пользователи не делают то, что вы от них ожидаете.

Зачем QA выдвигать гипотезы? Меньше интуитивных решений, больше влияния на продукт – реальный инженер пользовательского опыта.

Как можно узнать про пользовательский путь?

• Обратная связь – то, что пишут и думают пользователи о том, что вы делаете.
• Опросы. Но они коварны, пользователи любят искажать в хорошую сторону, им лень обосновывать.
• Оценка. «Насколько вы довольны?» Это суперпримитивно, все ставят оценку как в школе.
• Геймификация – Яндекс очень любит. «Что особенно понравилось» – и варианты, что именно (забота, вежливость, комфортное вождение, …). И это увеличивает обратную связь.
• Реакции: лайк/дизлайк/эмоции/абстрактные реакции. Что значит смайлик клоуна – могут быть очень разные штуки, и оно зависит от настроения.

На что влияет обратная связь? На качество продукта, помогает приоритизировать задач, что важно. Что доработать, убрать, изменить… Коммуникация, которая помогает изменяться по живому опыту.

Саму обратную связь надо протестировать. Все нормально, Ужас, Плюс – неясно к чему относится. Она очень субъективна и эмоциональна.

Обратная связь – симптом болезни. Болит горло – что за этим? Так же как «не смогла оформить заявку».

Тестировщик – тестирует не код, а весь продукт. Есть тестировщики, которые смотрят детально, смотрят на продукт глазами пользователей – не по инструкции, а по интуитивному пользовательскому пути и найти не очевидное.

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

Вам написали «Новый дизайн улучшит пользовательский опыт». Надо понять: что должно улучшиться и как именно изменится опыт.

Есть раздел Faq и он был грустным – просто очень длинный список каких-то типовых запросов. Это не работает – пользователям трудно найти вопрос. Проверили, что если разбить на блоке по тематикам – будет лучше, классно. И будет не 100500 вопросов большим списком, а 5-10. Что должно улучшиться? Пользователям станет проще искать ответы. И дальше надо определить метрики – как поймем, что им стало легче. Метрика – будет меньше вопросов к продукту, меньше комментариев «мы не понимаем». Но оказалось, что пользователям вместо классификации нужен поиск.

Дальше была россыпь примеров косяков UI, некоторые из которых – следствие того, что не учли региональные и языковые особенности. Классный пример, когда в диалоге обратной связи крестик «закрыть окно» поставили на 5-ю звездочку, ты хотел отказываться от оценки, а реально оценивал на 5.

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

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

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

Что надо проверять, когда меняется функционал? Влияние на основной сценарий: сломает она его, или улучшит? А что с альтернативными сценариями? А если сломается – насколько сильные потери? И проверка граничных сценариев. Проверить старых пользователей – что они подумают про новый релиз. Проверить наоборот, новых пользователей. Проверить разные языки интерфейса. Длинные тексты – на мегашироком мониторе, или на маленьком, экраны разных размеров. Это все правильно, но каждая проверка стоит затрат, и надо искать компромисс. Было бы интересно, если бы СБЕР поделился чек-листом: что именно они проверяют в своих приложениях, а если бы еще рассказал логику формирования (например, почему именно такие размеры экрана проверяют) – вообще круто.

Инструменты Feature toggle – можно тестировать в проде, раздавать фичи на разные группы, в том числе измерять различие в CJM. Пользовательская аналитика – клики активности пользователей, в том числе по дням недели. И можно строить фактический пользовательский путь. И проводить канареечное тестирование – смотреть использование фич.

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

Вопрос. Мы собираем, доносим до продактов, а они не смотрят. Ответ – надо показывать профит – время пользователей, бюджеты, повышение лояльности. Не просто «пользователи жалуются», а что изменится у пользователей.

Вопрос. А с противоречиями: 55% говорит «поиск классный», а 45% «поиск ужасный». Ответ. Надо понимать, что пишут. Больше смотреть на негатив – выявлять реальные неудобства пользователей. Многие просто смирились, не все пишут. Я бы ответ дополнил: возможно, пользователи приходят на поиск с сильно разными задачами, и для решения одних он удобен, а для других – нет. Например, при поиске мебели одним надо заполнить большую комнату, а другим – точечно купить один шкаф, который поместиться в заданный простенок. И надо разбираться со сценариями, важно, дорабатывая для одних, не сломать удобный поиск другим.

Вопрос. Как собирать обратную связь от операторов? Ответ. Есть наблюдение, как работает пользователь (Анна назвала это гемба, но гемба, все-таки, это самому поработать за пользователя).

Вопрос. Как убедить бизнес, что новая идея будет вредна? Я знаю, как работают пользователи, и я знаю, что пользователям не понравится? Ответ. Кратко – никак. Надо понимать идею бизнеса. Бизнесу может хотеть поменять продукт специально, чтобы изменить пользовательский путь. Я бы сам так резко не отвечал, потому что у бизнеса могут быть неверные представления о пользователях. Но надо действительно для начала понять его идею на уровне изменения CJM, а не создания фичи, а дальше можно проблематизировать, что вот этим не понравится настолько, что они уйдут, и быть готовым защищать это.

Дмитрий Пуртов. QA-отдел, который слышат: как выстроить архитектуру взаимодействия QA со всеми

QA-отдел, который слышат: как выстроить архитектуру взаимодействия QA со всеми

Рассказ о том, как QA перестать быть островом, который просто проверяет фичи, а начать активно взаимодействовать с бизнесом, чтобы к нему прислушивались.

Они разрабатывают HotelTech платформу – автоматизация гостиничного бизнеса. Бронь отеля, управление отелем, цены конкурентов, гибкое управление ценами, работа с отзывами и так далее.

Многим знакомо, когда QA видит проблему и предлагает решение, и его не слышат. Вопрос: это разовая или регулярная ситуация. Если разово – нормально, все бывает. А если из квартала в квартал – то проблема.

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

Сначала – разберитесь внутри, если у вас бардак – вас не будут слушать. У них 52 продукта, 28 тестировщиков на 150 разработчиков, команды живут по-разному, и вечно перегруженный руководитель. Была сильная команда и историческая память – на этом жило. Но потом пошел бурный рост, пришло много новых, люди поменяли позиции – и система начала сбоить. А он как руководитель пришел на частные вопросы и ручное управление.

Решение – отдать тактические решения лидам. В компании была неформальная система наставничества, и они ее институализировали не только для обучения, но и для решения вопросов, поделив области между лидами.

Область – это группа проектов, определенная контекстом: гости, платежи и так далее – воспроизвели у себя деление бизнеса. В каждом контексте – свои требования. Head – стратегия, лиды – тактика, qa в командах – операционка. И если не работает смежный сервис – начали идти к лидам, а не к head, чтобы договаривались по связям.

Что делали?

• Релиз менеджмент. Был хаос, когда команды катят когда хотят. Лиды посидели, написали процесс, потом в рамках команд – адаптировали, но без противоречий верхнему регламенту.
• Дежурство в команда. Сделали в одной команде, заработало – распространилось через лидов.
• Процессная группа – лиды и опытные тестировщики. Их задача – взять практики из команд, изучить, и раздать всем, возможно, поддержав стандартами.
• Метрики тестирования. В одной команде тестировщик заинтересовался, дальше лиды подхватили и потом ушло в процессную группу – там метрики описали, и потом еще dashboard сделали.

Система стала управляемой. Для него – 80% операционки ушло, обработали инициативы и внедрили. И у них – самый высокий happy job, выше среднего о компании и индустрии.

Порядок у себя навели, теперь – в компанию. Есть OKR, за CTO – техстратегия. Его задача как руководителя QA – встроиться в стратегию инициативами. Три цели на разных уровнях: процессы, инструменты и глобально на тех.отдел. Примеры: взаимозаменяемость внутри области, работа с метриками, quality-гейт. Лиды берут 2 цели общие, а третья – локальная на область, в зависимости от контекста. Где-то закладывать тестирование в планирование, где-то мерить план-факт, где-то автоматизация. Был период, когда активно работали с DevCycleTime. Увидели по метрикам, что качество стало падать. И сделали метрику качества, и надо держать обе.

Что на уровне спринта команды? Спринт – можно сделать ценности, и это можно сделать через OKR. Был негативный опыт – провалили, потому что API отстали и тестирование отстало – поправили рабочий процесс.

Как итог – качество начало входить в общее направление компании, наши инициативы получилось привязать к общим метрикам. Снизилось количество инцидентов, появились quality gate.

Каждый день работают к PM, разработчиками и остальными. Что обычно говорят QA: много багов, страдает качество, нестабильный стенд, все горит. Для ПМ, разработки или SRE это информация, он сочувствует, но не понимает, что делать. Надо заходить через язык и зоны интереса. Рост багов – увеличивает TTM и бьет по пользователям – они страдают. Это ПМ и SRE уже волнует. SRE у них теперь важный партнер.

Тестировщик заходил «не учли тестирование смежных продуктов» – это просто претензия и конфликт. Если это перевести на метрики – у них появилось 3 amigos для обсуждения, и ответственный подпинывания других для больших эпиков. Или разработчик пишет «сделано» без пояснений – надо сформулировать претензию, что будут лишние созвоны, и дать решение – шаблон. Иначе будет обсуждение про претензию, а не про способ решения.

«Много багов, повысим качество» – ни о чем. Если баги подвязать на инциденты, и съеденное время – то тогда появляется понимание. Эффект виден в поседении всей системы. QA зашел в SRE, появляются задачи для тестировщиков и так далее.

Важно не говорить громче, а говорить правильным языком.

Итого, что делаем.

• Порядок у себя
• Формализовать то, что есть
• Держать поток практик снизу вверх и сверху вниз
• Метрики – на понятный снаружи язык, а не число багов
• Войти в управление компанией.

Вопрос. А вот все сделал, а людям и так хорошо? Ответ. Скорее всего, вас не услышали про профит. А еще – надо быть векторе и залететь через целеполагание.

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

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

Вопрос: дожимать ли процессы у себя до идеала, или идти в ширь. Ответ: идеал не достижим, определяешь некоторый baseline, до которого надо дойти, до того как идти вширь.

Вопрос. А в стартапе, когда ты один, и всего 10? Ответ – там главное – включить качество в общие цели. В первое время хватало excel, и раз в месяц. Но главное – приносить не просто метрики и проблемы, а решение, проблемы никому не нужны.

У них – матрица, продуктовые команды, а QA – центр компетенций, который предоставляет тестировщиков. В основном тестировщики постоянные в команде, но на уровне областей стараются ротацию вести.

Вопрос. А как сопротивление изменениям? Ответ – есть, убеждаем в командах, а если нет – заходят сверху. А глобальные изменения обычно делает не только QA, где рабочая группа, не соло-QA.

Ксения Сергеева из Lamoda. Обратная сторона софт-скиллов

Обратная сторона софт-скиллов

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

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

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

Софт-скиллы – не серебряная пуля.

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

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

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

Чек лист: устали от общения и пугаетесь сообщений, мысль “я же могу разговаривать, почему они не могут”, желание жестко ответить, трудно принимать решения – ступор, рассеянное внимание, перестаете получать удовольствие.

Первый звоночек: это мысль “я же могу, почему они не могут”. Надо быть адекватным уровню компании. Если вкладываете больше, чем компания.

Что делать?

• Совет «снизить стресс и больше двигаться» – работать не будут
• Реально – диагностируете уровень зрелости окружения, и разрыв между ним и вами
• Если вас не принимают – они не доросли, выровнять ожидания по уровню зрелости
• Не брать на себя ответственность за окружение
• Соблюдать личные границы
• Научиться говорить «нет»

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

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

Руслан Остропольский. Системный подход в работе лида/хеда QA

Системный подход в работе лида/хеда QA

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

B Руслан в выступлении говорил именно об этом – о порядке выстраивания работы лида QA. Это тоже важно, выстроить системность – так проще, чем жить в хаосе. По факту в выступлении такой иерархический список, mind map топиков, из которых складывается работа лида или хеда, с комментариями и примерами.

Позиция лида – правильный старт. И тут есть типичные ошибки, не все очевидные.

• Твоя экспертность как QA тебя тормозит: вместо управления делаешь работу за всех и всем помогаешь, и на управление не остается времени
• Незавершенные дела – новому лиду часто дают пару проектов доделать, и на тебя обрушивается большое количество задач, структуры которых ты не понимаешь
• Попытка сделать везде все и сразу, потому что «предыдущий тупил»
• Непонимание своей роли, особенно если ты пришел из другой компании: у роли очень большая вариативность, и далеко не всегда объясняют, что именно от тебя ждут
• Проблема принятия командой – это отдельное дело
• Прилетающие темы, с которыми надо быстро разбираться
• Новые обстоятельства: надо было нанять +30, а потом бюджет дали только на 5, но с тем же скоупом

Со всем этим надо разбираться системно. Он выделяет следующие области.

• Стратегия и цели
• Команда
• Коммуникация
• Процессы и инструменты, многие думают, что это – главное, а это – один из кусков
• Метрики
• Культура и принципы – одни строят неосознанно, а у других само не получается и надо делать
• Домен QA в мире – он развивается, за этим надо следить

Стратегия и цели: куда мы идем – цель, как идем (способ, почему получится); как поймем, что дошли (ускоримся с помощью ИИ на 30%)

TMMI Maturity model – 5 уровней. Но над не просто взять модель, а выделить блоки: Команда, процессы, метрики, коммуникации. Дальше рисуем в миро.

Режим целей.

• Измеримость – метрики и дашборды
• Цели – помогают стратегии
• Долгосрочная картинка – хотя бы год
• Зажечь звезду – великая цель, которая зажигает

Пример цели: у нас регресс 2 недели, а нам нужно дойти до ежедневного релиза. Понятно, что это не сразу, но надо держать направление и понимать текущий шаг и его вклад в продвижение.

Мотивация достижения целей

• Давно болит – облегчаем
• Избавляться от рутины
• Новое-интересное
• Возможность заработать – не забывайте о бонусах

ИИ не заменит человека, а избавит от рутины, и в этом его фишка.

Режим целей – подход

• Отделять операционку от целей. Тестировать задачи – не цель
• Автоматизация рутины – время на развитие
• Повышаем зрелость maturity model, учитывая, что команды – разные на входе и по задачам,
• Изучил новое – поделись и научи других

Команда. Орг.дизайн:

• проектирование структуры
• принципы взаимодействия и зоны ответственности
• кто, зачем и почему
• какие функции есть, откуда возьмем

Он рисует как иерархию, и в разрезе команд. И может жить годами – актуализируем.

Команда – что есть.

• Резюме, 360 и ревью – достаем историю
• Зарплаты и изменения – история
• Бюджеты на команду
• Матрицы компетенций, с историей – если они есть
• Проводим 1:1 со всеми – надо понять, с кем работаем.
• Личные отношения – кто готов работать со стратегией и целями.
• Работа с недоверием, сработаться, кого-то поменять.

Принципы работы

• Информируй, не зажимай важное. Есть много историй, когда не рассказывают про причины решений, это неправильно
• Делегировать – ответственный за каждую тему
• Быть доступным. Не ждут встречи 2 недели – а то перестанут ходить
• Нет плохих людей, есть неподходящие задачи. Надо разбираться,
• Баланс доброты. Пробовать и ошибаться – нормально. А если косячит, например, на каждую встречу приходит неподготовленный – фигня

Коммуникация. Связи

• Выровнять ожидания с руководством
• Выстроить отношения со смежниками
• Системные встречи с целями и правилами – что регулярно происходит, и проверять осмысленность, бывает перевод ежедневной встречи в еженедельную не портит

Коммуникация. Звучать регулярно

• Планы и цели
• Результаты
• Над чем работаем
• Опыт индустрии: сходили на конфу – поделитесь
• Выходить в мир

Коммуникация. Быстрые победы.

• Слушать и вникать
• Не ломать историческое
• Не критиковать прошлое (все плохо, сейчас я сделаю хорошо)

Быстрые победы – действия.

• В любой теме можно сделать быстрый результат за 2 недели. Если проект на полгода – найдите видный первый шаг
• Мышление гипотезами. Пробуем, не бетонируем процессы
• Любая идея – ценная, не душить непонятное. Записываем, даем возможность попробовать
• Быть экспертом – некоторые темы копать самому

Нельзя

• Автоматизировать проблемные процессы – проблемы останутся
• Перемены ради перемен, потому что не нравится, или потому что так было в прошлой команде

В заключении.

• Менеджмент – делать результат стратегический и тактический параллельно
• Коммуникация – скрытая сила побед
• Системность – области движения, а не везде все подряд
• Достижение команды – это ваши успехи

Базовые книги

• Умение слушать осознанно
• Первые 90 дней
• Системное мышление для руководителя

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 14:03, 30 апреля 2026 • нет комментариев