Расписание

Токены — это валюта LLM-систем, и инженер, который не управляет их расходом, просто сжигает бюджет впустую. На примере реальной мультиагентной системы автотестирования показываем, как выбор правильной модели под задачу и несколько инженерных техник дают 40–90% экономии без потери качества.

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

Реальный опыт на Java и Spring: OpenCode и Qwen 397B в закрытом контуре, консоль в кадре, ни одной ручной правки в показанном кейсе.

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

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

На воркшопе мы вместе соберем своего QAI-агента — агентную систему, которая помогает тестировать задачи и проводить root-cause анализ.

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

Как тестировать автономные мультиагентные системы, если их качество не детерминировано, а ошибки могут скрываться глубоко внутри цепочки агентов? На боевых примерах разберем проблемы с датасетами, метриками, выбором моделей и анализом логов, а затем покажем, как LangFuse помогает превратить эксперименты с LLM в прозрачный инженерный процесс с версионностью, параллельным тестированием и измеримыми результатами.

На воркшопе разберем основные уязвимости современных ИИ-агентов и на практике попробуем их эксплуатировать. Участники получат доступ к учебному приложению с ИИ-агентом и последовательно выполнят задания по обходу guardrails, prompt injection, атакам на tool calling и мультиагентные системы.

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

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

Агенты в работе QA: от разбора бага до quality gate в пайплайне. Что прячется за каждой настройкой, сколько стоит один ход диалога и почему авторы Playwright советуют не использовать их собственный MCP.

На одинаковых UI-сценариях сравним разные подходы к AI-генерации тестов на примере Playwright CLI, Journeys, Maestro и других инструментов, а также посчитаем стоимость создания, запуска и поддержки тестов. Отдельно разберем подход Assertum, где LLM решает только задачи, требующие понимания контекста, а все формализуемые задачи выполняются детерминированно.

Токены — это валюта LLM-систем, и инженер, который не управляет их расходом, просто сжигает бюджет впустую. На примере реальной мультиагентной системы автотестирования показываем, как выбор правильной модели под задачу и несколько инженерных техник дают 40–90% экономии без потери качества.

Какой должна быть архитектура фреймворка автотестов для бэкенда? Обсудим проверенные решения, масштабируемость и практический опыт.

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

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

Как выглядит качество продукта в production и что QA может сделать для его надежности? Поговорим о SRE-подходе в тестировании: SLI/SLO/SLA, Observability, Error Budget, Toil, отказоустойчивости и работе с инцидентами.

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

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

Реальная история о том, как мы с командой прошли путь от 30-40 минут на один запуск интеграционных тестов до 3-4 минут. Обсудим, как мы к этому пришли, какие ошибки совершали по пути и на чём в итоге остановились.

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

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

Разберу кейс внедрения Data Quality в проекте налоговой отчетности, где синергия PyDeequ и Soda Core помогла стабилизировать расчеты и избежать финансовых рисков. Также продемонстрирую наш DQ-generator, который трансформирует метаданные в готовые правила валидации и существенно сокращает рутинную работу инженеров.

Как автоматизировать анализ падений автотестов после CI/CD-прогонов и не превращать этот процесс в «отдали всё нейросети»? На практическом примере разберем пайплайн, который собирает данные из Test IT, GitLab и истории прогонов, выполняет детерминированную классификацию и передает подготовленный контекст языковой модели для формирования гипотез и рекомендаций.

Поговорим также о том, как тестировать промпты и контролировать качество AI-решения с помощью evaluation-наборов и CI-проверок.

На воркшопе мы вместе соберем своего QAI-агента — агентную систему, которая помогает тестировать задачи и проводить root-cause анализ.

Мейнтейнер pywinauto, рассказываю о кроссплатформенности в десктопных UI-тестах, о внедрении кода (DLL/SO) в UI-процесс, которое отодвинет коммерческое ПО, и разбираю пару сложных кейсов.

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

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

Как сократить рутинные действия в мобильном тестировании и не терять важный контекст при поиске багов? Разберем инструмент для подготовки Android-устройств, установки сборок, работы с тестовыми данными и аккаунтами, сбора логов и информации о девайсе.

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

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

Какой должна быть архитектура фреймворка автотестов для бэкенда? Обсудим проверенные решения, масштабируемость и практический опыт.

Как автоматизировать анализ падений автотестов после CI/CD-прогонов и не превращать этот процесс в «отдали всё нейросети»? На практическом примере разберем пайплайн, который собирает данные из Test IT, GitLab и истории прогонов, выполняет детерминированную классификацию и передает подготовленный контекст языковой модели для формирования гипотез и рекомендаций.

Поговорим также о том, как тестировать промпты и контролировать качество AI-решения с помощью evaluation-наборов и CI-проверок.

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

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

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

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

В рамках доклада рассмотрим, как организовать автоматизированное тестирование, требующее одновременного сетевого взаимодействия нескольких машин, используя только Python, Netmiko и pytest. Изучим подходы к созданию стабильных тестов в условиях, когда ОС и синтаксис команд на машинах могут различаться или меняться.

Разберём, как сохранять контроль над удалённой машиной в сценариях, предполагающих отключение WAN-интерфейса и последующий обрыв SSH-соединения. На примере автоматизации тестирования сетевого ПО на удалённых машинах рассмотрим создание универсального SSH-адаптера.

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

Что такое полевое тестирование телеком-оборудования и зачем оно нужно в реальной сети? Разберем, как проходит Drive Test, какое оборудование и ПО для него используются, какие показатели определяют качество связи и почему скорость может отличаться на разных устройствах.

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

Как сократить рутинные действия в мобильном тестировании и не терять важный контекст при поиске багов? Разберем инструмент для подготовки Android-устройств, установки сборок, работы с тестовыми данными и аккаунтами, сбора логов и информации о девайсе.

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

На воркшопе разберем основные уязвимости современных ИИ-агентов и на практике попробуем их эксплуатировать. Участники получат доступ к учебному приложению с ИИ-агентом и последовательно выполнят задания по обходу guardrails, prompt injection, атакам на tool calling и мультиагентные системы.

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

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

Делимся результатами опроса TechRadar.

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

Честно о фейлах в тестировании: реальные истории, полезные выводы и никакой записи. Есть свой эпичный провал? Заполняйте форму и рассказывайте!

Что на самом деле означает «достаточное покрытие тестами»? В этом докладе проследим, как эволюционировали подходы к оценке качества тестирования: от line coverage и data coverage до фаззинга, context coverage и business coverage. Разберем, почему классические метрики упираются в отсутствие контекста и как большие языковые модели помогают учитывать требования, предметную область и ценность сценариев для бизнеса. Поговорим о том, где проходят новые границы тестирования и почему покрывать нужно не всё, а то, что действительно важно.

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

Подводим итоги конференции, вспоминаем яркие моменты и рассказываем о дальнейших планах.