Программа

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

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

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

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

В докладе расскажу, как мы применили Infrastructure as Code для развёртывания тестовой инфраструктуры и превратили этот процесс в воспроизводимый и управляемый конвейер. Покажу, как связка Terraform + Ansible + Proxmox помогла нам автоматизировать создание виртуальных машин, настройку окружений и подготовку стендов для задач тестирования и разработки.

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

Использование ИИ кардинально ускорило разработку: работая с ИИ-агентами, сеньор может выполнить годовой проект команды за пару месяцев. Создание кода перестало быть узким местом — ограничение сместилось на постановку задач, а это означает изменение процессов и роли ИТ. Управлять разработкой, когда проверка гипотезы вместо трех месяцев занимает пару дней, надо иначе. Инженеры же пока пытаются адаптировать старые концепты вроде разработки по требованиям и CASE-средств, создавая SDD и Disrupt-PDCL.

Реальная практика идет по другому пути. Подробные спецификации буксуют из-за объема и сложности проверки. Вместо идей и ТЗ бизнес приносит готовые прототипы, созданные с помощью вайбкодинга без спецификации. Но бизнес готов формулировать acceptance criteria, и тестировщики могут стать ключевым звеном разработки.

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

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

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

Участники осваивают методологию reverse engineering (пассивный анализ DDL, VCS, логов и миграций; активный анализ через SQL-эксперименты, трассировку и API-инструменты), а затем в группах разбирают четыре разных legacy-сценария (e-commerce, аэропорт, банк, склад) с намеренно заложенными аномалиями — скрытыми статусами, рассинхронизацией вычисляемых полей и "слепыми" триггерами.

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

В нашей команде был вечный конфликт: разработчики забывают проставлять data-testid, тестировщики не могут написать стабильные тесты (а самим писать testid нам не давали), а время уходит на поиски «где этот ID?». Разработчики считают это рутиной. Мы сделали GenTestID — CLI-инструмент, который автоматически проставляет data-testid во все Vue/React компоненты одной командой. Несколько секунд — и всё готово. Никаких споров, никакой рутины, никаких забытых ID.

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

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

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

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

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

Обсудим и границы AI: проверка и ответственность за результат остаются за экспертом.

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

Причем дело не в качестве моделей. При хорошем контексте ИИ вполне способен на хорошие проверки. Дело в том, что мы не можем проверить и верифицировать, что именно он сделал.

Походу нашего доклада расскажем:
• Как мы наладили процесс тестирования, разбив его на несколько этапов.
• Как нам в этом помогли хранение кейсов в Git и подход «Tests-as-Code».
• Почему TMS продолжает играть ключевую роль в обеспечении качества.

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

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

Они были виртуалки, поды и контейнеры! Поды, контейнеры и виртуалки! Они заполонили всю планету! Наступал судный день! Но мудрецы помнили, что у всего есть свои плюсы и минусы, а за удобство приходится платить. Поэтому в докладе будем разбираться, как так случилось, что мы пришли к необходимости построить свой bare-metal стенд для тестирования, в чём мы выиграли, в чём проиграли и как объяснили затраченные ресурсы руководству.

AI уже умеет генерировать код, переносить автотесты между языками, поднимать прототипы, искать причины проблем и превращать тест-кейсы в заготовки автотестов. На первый взгляд это выглядит как ускорение разработки, но на практике меняется сам процесс QA automation и роль инженера.

В докладе я поделюсь опытом применения AI в тестовой автоматизации: миграцией E2E-тестов с Java на .NET, быстрым прототипированием библиотек, генерацией тестов по сценариям, поиском root cause и развитием внутреннего репозитория AI-практик для тестирования и требований.

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

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

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

Для тестирования это критически важный вопрос, так как предупреждать об инцидентах и предотвращать их — одна из основных задач тестировщиков. Эту культуру молчания создает не команда, а лидер: своей реакцией на неудобные вопросы, плохие новости и споры.

На докладе разберем, почему контроль в QA создает иллюзию управляемости и на самом деле снижает личную ответственность и увеличивает скрытые риски. Обсудим, почему разбор без поиска виноватых не спасет, если до инцидента в команде было страшно говорить правду. А главное — разберем, как понять, что культура молчания уже сложилась в вашей команде, и обсудим 7 конкретных шагов, которые помогут это изменить.

Продуктовая аналитика — это данные, на которых бизнес принимает решения: запускает A/B-тесты, оценивает конверсию, выделяет бюджеты. Но если события улетают с ошибкой — все эти решения становятся ложными.

В докладе команда QA X5 расскажет, как мы выстроили риск-ориентированный процесс контроля продуктовой аналитики в тестировании: разделили приоритеты событий и параметров, автоматизировали подготовку ожидаемых данных и детерминированное сравнение с отчётом AppMetrica, а также спроектировали целевую схему с быстрым получением событий из ADB и системной консоли iOS. Отдельно разберём безопасную роль ИИ — генерацию черновиков контрактов и автотестов, поиск пробелов покрытия и диагностику падений.

ИИ научился превращать ТЗ, созвоны и документацию в готовый бэклог с эпиками, критериями приёмки и оценками. Постановка задач ускорилась в разы, задачи стали однотипными и на вид более полными.

Проблема в том, что "на вид полная" и "корректная" - не одно и то же. На примере реального проекта покажу, где ИИ-постановка помогает QA, а где подсовывает додуманные требования, теряет бизнес-ограничения и прячет неясности за уверенной формулировкой.

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

На мастер-классе соберём простого QA-агента: подключим модель, цикл обработки, скилл и MCP к тестовой TMS. Запустим, посмотрим, что он делает, и вместе найдём ошибки в его работе. Попробуем исправить их через правку скилла. В конце разберём, как проверять агента перед запуском в рабочую среду.

Расскажу, как мобильная команда продукта «Умная камера» использовала AI Skill для определения тест-кейсов, затронутых изменениями в коде, ещё до передачи задачи в QA. Мы столкнулись с тем, что разработчики регулярно передавали задачи с дефектами в базовых пользовательских сценариях: поиск подходящих тест-кейсов в Allure TestOps занимал много времени и требовал дополнительного взаимодействия с QA. Разработанный нами AI Skill анализирует diff в merge request, определяет потенциально затронутую функциональность и формирует для разработчика список связанных тест-кейсов с прямыми ссылками, необходимыми артефактами и отметкой о наличии автоматизации. Это позволяет разработчику самостоятельно проверить неавтоматизированные сценарии и исправить найденные дефекты в рамках того же merge request, благодаря чему нам удалось сократить количество acceptance-багов, уменьшить число возвратов задач в разработку и сделать проверку изменений до QA системной частью процесса.

Пересмотрели сам подход к выпуску продукта. За счет выстраивания процессов, внедрения QA-гейтов, автоматизации и интеграции AI-агентов нам удалось сократить релизный цикл с 2–3 недель до 2 часов и уменьшить количество участников процесса с пяти до одного.

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

В докладе расскажу:
• как находить реальные узкие места релизного процесса;
• какие QA-гейты помогают выпускать быстрее, а какие создают бюрократию;
• как встроить контроль качества непосредственно в CI/CD;
• где AI-агенты действительно помогают в релизном процессе и какие задачи можно доверить им уже сегодня;
• какие метрики позволяют принимать решение о выпуске без бесконечных созвонов и согласований.

Итогом стала система, где релиз сократился с 2–3 недель до 2 часов, а вместо координации целой команды достаточно действий одного инженера.

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

Blockchain-продукты — это не только наслаждение новой технологией, но и полноценные системы с самыми необычными и диковинными проблемами: консистентностью событий, асинхронностью, состояниями гонки (race conditions) и необратимыми операциями. В докладе разберём, почему привычные QA-подходы перестают работать в blockchain-системах, как меняется стратегия тестирования смарт-контрактов (smart contracts) и инфраструктуры, и какие практики помогают сделать такие продукты тестируемыми и поддерживаемыми.

Коммуникация в QA-командах - это не просто обмен информацией. Это поле, где ежедневно разыгрываются повторяющиеся (и часто довольно драматические) сценарии взаимодействия, которые психолог Эрик Берн называл "играми". Термин совсем не про развлечение - это модели поведения, ведущие к предсказуемо "печальному" результату. Какому? 

Обесцененные баг-репорты, защитная реакция на критику, бесконечные уточнения требований, постоянные конфликты на созвонах. 

Знакомо, правда?

Каждый играет свою роль, но исход часто предопределен — страдают нервы и люди, качество общения и качество продукта.

Что если не бороться с этим, а попробовать перевернуть подход? Использовать игровую форму сознательно? 

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

Почему один баг с одинаковым severity фиксится за час, а другой висит две недели? Мы часто списываем это на особенности команды, человеческий фактор или неудачное стечение обстоятельств. Но за многими такими историями стоит архитектура самого процесса.

На практическом воркшопе вы возьмёте свой реальный QA-процесс — defect flow, triage, регрессию, release readiness или эскалацию инцидента — и буквально препарируете его: разберёте по типам операций, найдёте точки принятия решений и проверите, как в нём распределена ответственность.

Затем устроим процессу краш-тест с помощью AI: посмотрим, какие операции можно безопасно автоматизировать, а где автоматизация лишь замаскирует проблему или усилит существующий риск.

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

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

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

Мы прошли это на себе: превратили набор разрозненных скриптов в систему агентов с чётким разделением ролей. По пути пришлось ответить на девять неудобных вопросов — ровно те, что стоят в темах этого доклада. Что считать багом, а что фичей? Как быть со старыми сервисами без документации? Что происходит при смене модели?

Доклад — это карта нашего опыта, а не учебник: разбор реальных проблем и конкретных решений.

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

Какие подходы есть для реализации обезличивания и какие могут быть подводные камни у разных подходов.

Почему именно тестирование является самой заинтересованной компетенцией в появлении консистентных обезличенных данных на тестовых средах и как это можно "продать" заказчикам и стейкхолдерам.

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

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

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

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

Разработчики написали тесты, все зеленое. Что теперь должен делать QA - повторять те же проверки?

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

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

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

LLM-агенты «слепы» к реальному браузеру, а сырой DOM перегружает контекст и нестабилен. Решение — архитектурный сдвиг к Accessibility Tree (сжатие в 10 раз) и стандартизация управления через МСР Playwright. 

Что в докладе:

Разберем группы инструментов МСР (навигация, взаимодействие, данные, сессии), интеграцию со СберБраузером и баги экранирования в GigaIDE.

Покажем живые кейсы: создание фейк-почты на fex.plus и агента test-fixer, чинящего локаторы по тексту ошибки.

Обсудим боль МСР — расход токенов и недетерминизм LLM в CI/CD, а также предложим решение — гибрид МСР + CLI.

Продемонстрируем мультиагентные сети с оркестратором и Self-Healing на базе нескольких стратегий поиска.

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

Что, если применить к управленческим решениям знакомые QA-подходы: ревью, граничные сценарии и другие? В докладе поговорим о том, почему руководителям сложно получать честный второй взгляд, как это влияет на качество решений и как организации могут создать механизм Management Review — не для согласования решений, а для проверки качества мышления до того, как решение попадет в «production».

Test-Rex — прототип системы генерации автотестов на основе LLM, использующей RAG-поиск по кодовой базе и существующим тестам проекта. Система принимает текстовое описание пользовательского сценария, извлекает релевантный контекст из репозитория, формирует промпт по шаблонам и генерирует исполняемый тестовый код. В докладе рассматриваются архитектура решения, устройство индексатора и критерии оценки качества генерации. Также обсуждаются ограничения подхода и направления дальнейшего развития.

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

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

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

У нас никогда не было столько инструментов для обеспечения качества. Статический анализ, тысячи тестов, quality gates для каждого изменения, ИИ и автоматизация рутины. Казалось бы, качество программных продуктов должно только расти.

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

Так ли это на самом деле, или мы просто стали требовательнее?

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