Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 752 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
|
Последний пост блога 2026-04-30: SQAdays - ожидаемо, хорошие выступления и много нетворкинга Участвовал 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 в тестировании: ускоряем процессы с помощью n8nNo-code/Low-code в тестировании: ускоряем процессы с помощью n8n Это был рассказ о встройке ИИ-агентов pipeline обработки задач. Не только выполнения тестирования, это обеспечивают автотесты, но и для других активностей тестировщика: анализ прогонов, подготовка тестовых данных, доработка автотестов, общение в чатах и так далее. Где-то ИИ может помочь больше, где-то – меньше, но область использования будет расширяться, и нужно обобщенное решение, которое позволит подключать агентов, где необходимо. Чтобы работа агента была релевантна, ему нужен контекст, который получается из разных систем, и свои результаты он тоже уметь доставлять в системы. И для этого процессы были описаны с помощью n8n, что позволило подключить необходимые интеграции и сочетать шаги человека с шагами ИИ. Платформ для описаняи процессов много, они смотрели zapier, n8n, workauto, make. Их требованиям – развернуть локально, бесплатно и открытые исходники удовлетворил только n8n. Это визуальный конструктор процессов, low-code и много интеграций с приложениями и api и ИИ внутри. Workflow состоит из node, информация подается на вход и выдается на выход, json. Зоопарк нод большой, более 1000 интеграций. Типы нод:
Пример процесса: получить данные с сайта, записать в БД и отправить в телегу, все обеспечивают стандартные ноды с настройкой. Можно еще встроить jscript прямо в настройке (например, дату получить из текущего времени), или специальную ноду code. Первым автоматизирован такой процесс: есть тест-кейсы в jira с шагами (test step), это надо превратить в сценарий BDD на Gherkin, и приложить результат к той же задаче. В Jira делаем кнопку, которая запустит процесс – web-hook. Запуск – получение данных http-запросом из jira → ИИ-магия локальной LLM для создания BDD-сценария → приложить результат к Jira → отправить инфо в телеграм. Для генерации сценария BDD – Qwen: промпт на английском, векторизация, извлечение эталона, обогащение запроса, блокировка творчества – только заданные шаги и приложение результата.
Можно не только BDD, а любые процессы: автоматическая проверка pull request, генерация тестовых данных, мониторинг стендов и управление, синхронизация статусов, создать баг из чата, анализ логов и так дал.. По процессу BDD метрик нет. А вот анализ pull request полностью автоматизирован и сейчас полностью полагаются на ИИ: если она одобрила – ОК, разбираются только там, где проблемы нашла. Ариадна Букатина из Райффайзен. AI для коробочного решенияAI для коробочного решения Рассказ об использовании ИИ для тестирования коробочного решения: генерация тестовых данных, загрузка данных через API на Lua вместо UI (решена без знания Lua), агенты для написания автотестов и анализа результатов. Успешно, двигаются дальше. А теперь подробнее. Коробочное решение – готовый инструмент, который внедряется за день. У него есть жесткие правила валидации, частые релизы и черный ящик для тестирования. В нем есть фронт и бэк, 15 java-сервисов и около 100 интеграций. Задачи – постоянный регресс релизов: проверка межкоробочного взаимодействия и сервисов, работа с тестовыми данными там, где не автоматизировано, проверка соответствия данных в справочниках между фронтом и бэком – могут быть отличия по настройкам, написание быстрых автотестов и проверка покрытия. Ручное тестирование долго и трудозатратно, автоматизация тестов и генерации данных требует опыта разработки. ИИ смягчает требования к опыту разработки, и это быстро. У них следующие кейсы.
Три месяца назад они не поверили бы, что это возможно. А тут – успешно освоили. Вопрос. Что скармливаете для генерации данных? Ответ. По критериям формирования полей описывали форматы – и он создает данные. ФИО ИИ сама знает, как выглядит, для счетов даем маски – она порождает и проверяет, что этого нет. LLM развернуто локально, его поддерживают отдельная команда, и оно – не только для них. Промпты пишут сами по-английски и по-русски. Есть интеграция с jira и testops, агенты подключаются, видят задачи и описания, Агенты пишут тесты, но пока не обновляют сами, это делают вручную, проверяя результат агента. Владислав Григорьев из X5 Tech. Встраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительноВстраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительно Задача – внедрить Ай-ай в процессы тестирования, не сильно ломая уклад. И чтобы это было масштабируемо. Генерить тесты по API или UI можно без подготовки на любой модели, и это у них работает 1.5 года. Рассказ про следующий шаг – включение в процессы. Для этого нужно много частных решений, получаемых вайб-кодингом и объединяемых в процессы с помощью n8n. А для качественного вайб-кодинга используют Spec Driven Development (SDD). Нужны несколько вещей.
MCP-сервер с помощью вайб-кодинга может сделать любой. Он любит python. Не отличается от любого микросервиса. И важно описать, что именно каждая ручка делает, иначе его не будут использовать. Но есть проблемы, с которыми надо разбираться. Пример – mcp-сервера kaiten. Основное – теряется контекст, сервер возвращает слишком много данных. Kaiten любит возвращать жирные ответы с громадным количеством данных (до 2 млн – и нейронка уйдет в нирвану) за неприличное время – 5сек. Для описания процесса используют n8n. В презентации Flow ACE – конкретный пример, куча блоков, от входа чата до выхода. Его можно использовать через чаты или API. При этом возможен гибрид, например, в MCP-wiki получение отчета – автомат, а перенос в wiki – вручную. В чем проблемы vibe coding?
Что предлагает 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-х как составная часть концепта «управляемого развития». Китай тут оградился, там страха перед технологиями нет – поэтому он быстро идет вперед. Там отношение «ИИ пока учится, поэтому совершает ошибки – давайте учить вместе, чтобы было быстрее». Теперь кейсы из выступления, некоторые – с моими комментариями. Один из кейсов – фейковый, Владимир с самого начала предупредил, что так будет, предложил подумать над этим, а в конце – раскрыл интригу.
Денис Кияница и Илья Голос из Т-Банк. 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-процесс. Дало много профита. В частности – ловят баги по зависанию процессов. На чем спотыкаются.
Эдуард Ермолов из X5 Tech. Чистая архитектура и метапрограммирование в рамках ATЧистая архитектура и метапрограммирование в рамках AT Выступление – про применение принципов чистой архитектуры к архитектуре тестов. В целом понятный рассказ. Но вот почему для тестов чистая архитектура – благо, то есть какие проблемы ее применение убирает, показано не было. Известно, что выделение слоев или абстракций усложняет код. И сначала кто-то декларирует, что обращаться напрямую к атрибутам в бизнес-логике – плохо, надо каждый атрибут обернуть методами get и set, а затем делают синтаксический сахар, чтобы оборачивание было автоматическим и автору кода не приходилось об этом думать, и все хорошо, пока это не приводит к сложным багами и накладным расходам. Или декларируется, что core не должен вызывать бизнес-уровень, поэтому на него невозможно вынести содержательную обработку ошибок и сделать обобщенные методы, которые умеют, когда надо, делать retry и тому подобное, поэтому для обработки ошибок делают шаблоны, используемые на прикладном уровне. И так далее. В общем, когда архитектурные ограничения переносишь в другую область, то хорошо бы все это показывать, а не просто говорить о том, как бы нам соблюсти постулированные принципы. Это было мое отступление, а теперь вернемся к самому выступлению. Что такое – архитектура тестов? Это ответ на вопросы: где лежат тесты; где инфраструктура для запуска; как тест обращается к api, напрямую или через прослойку; что меняется, когда меняется end point, как быстро въехать в проект. Цель архитектуры – сократить количество тестов и уменьшить количество изменяемых файлов, чтобы изменение модели затрагивало 1 файл, а не 40 тестов. Принципы
Дальше было приземление на тесты с примерами, это сложно пересказывать, смотрите в вступлении. А затем – основная идея выступления: метапрограммирование – разработка обобщенного кода с помощью декораторов. В результате мы пишем общая логика – в одном месте, а методы генерируем автоматически. Код читается как спецификация. Новый компонент – без изменений во фреймворке. Чистая архитектура задает задачи, а метарограммирование их решает. Как это делать – были примеры, текст надо смотреть в презентации, а здесь я поясню подход. Например, 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 не используют – отчеты простые. Переиспользование сценариев – не так сложно, но не бесплатно. В презентации были конкретные диаграммы как примеры. Режимы работы системы.
С осени работает на одном из комплексов. Что достигли?
Удалось совместить несколько вещей, которые изначально хотели – автоматическое выстраивание нового окружения, переиспользование тестов, облегчили жизнь по подготовке инфраструктуры. И получилось запускать длительные тесты с приближением к реальной эксплуатации, вплоть до нескольких месяцев. Систему делали 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, чтобы договаривались по связям. Что делали?
Система стала управляемой. Для него – 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 топиков, из которых складывается работа лида или хеда, с комментариями и примерами. Позиция лида – правильный старт. И тут есть типичные ошибки, не все очевидные.
Со всем этим надо разбираться системно. Он выделяет следующие области.
Стратегия и цели: куда мы идем – цель, как идем (способ, почему получится); как поймем, что дошли (ускоримся с помощью ИИ на 30%) TMMI Maturity model – 5 уровней. Но над не просто взять модель, а выделить блоки: Команда, процессы, метрики, коммуникации. Дальше рисуем в миро. Режим целей.
Пример цели: у нас регресс 2 недели, а нам нужно дойти до ежедневного релиза. Понятно, что это не сразу, но надо держать направление и понимать текущий шаг и его вклад в продвижение. Мотивация достижения целей
ИИ не заменит человека, а избавит от рутины, и в этом его фишка. Режим целей – подход
Команда. Орг.дизайн:
Он рисует как иерархию, и в разрезе команд. И может жить годами – актуализируем. Команда – что есть.
Принципы работы
Коммуникация. Связи
Коммуникация. Звучать регулярно
Коммуникация. Быстрые победы.
Быстрые победы – действия.
Нельзя
В заключении.
Базовые книги
|
Блоги друзей |
