Программа

Как часто мы видим баг-репорты вида «не работает кнопка» без скриншотов и деталей? К сожалению, это происходит, и никто от этого не застрахован. Чтобы уменьшить вероятность пустого тикета, было принято решение, написать простой инструмент по "отлавливанию" ошибок с целью быстрого реагирования и получения данных об ошибке, даже если мы забываем/не может открыть DevTools. Именно так и появился ErrorMonitor, о котором хотелось бы рассказать.

Инструмент будет полезен тестировщикам, аналитикам и специалистам поддержки для ускорения локализации и исправления ошибок.

Меня зовут Вадим и за свою карьеру в тестировании я провел, не одну сотню собеседований... И хочу поговорить об этом :)

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

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

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

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

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

В докладе мы поговорим о том, как тестировщик может работать с пользовательским фидбэком как с объектом тестирования. Я покажу, как из разрозненных отзывов и поведенческих данных формируются UX-гипотезы, и как QA-инженер помогает сделать их проверяемыми и технически валидными.

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

О Shift-left часто говорят как о безусловно полезном подходе: тестирование благодаря ему ускоряется, а качество растет. Но так ли все однозначно?

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

Знаете ли вы, что делать, если у вас начали вайб-кодить?

Вы готовы?

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

Призываем объединиться в группы и добрать необходимые компетенции среди участников конференции. Не хватило опытного специалиста в какой-то сфере? Кидай клич в чатик конфы, и помощь обязательно найдётся!

Участникам нужно иметь с собой:

• ноутбук с Android Studio (поможем установить);

• ваша любимая LLM (или готовность её приобрести);

• задор повайбтестить!

• группа единомышленников или решимость защищаться в соло.

Главный кошмар QA-Head — это неуправляемый “зоопарк” процессов, бесконечные совещания ради совещаний и тушение пожаров. QA превращается в изолированный остров, качество страдает, а конфликты растут. 

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

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

МК будет полезен всем, кто стремится автоматизировать рабочие процессы, — от новичков до опытных специалистов. Мы посмотрим, как превратить ИИ в эффективного помощника при работе с кодом непосредственно в IDE.

После мастер-класса станет понятнее какие задачи хорошо подходят для делегирования ИИ-агентам и как на практике добиваться результата, сохраняя контроль над процессом.

Технологии обновляются быстрее, чем когда-либо и под влиянием ИИ роль QA существенно перестраивается. 

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

О чем поговорим:

• Наши профессиональные страхи: deskilling,  FOMO и когнитивный шум

• Их влияние на каждого специалиста и какой путь они открывают к дальнейшей эволюции в профессии

• Концепция тестировщика будущего, сочетающего инженерию, аналитику, ИИ и стратегическое мышление, формирующие новый профессиональный профиль на ближайшие годы
  
  

P.S. Будет минимум субъективного и максимум крупных исследований

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

Софт-скилы — как много в этом звуке!.. 

В современном IT очень ценятся люди с развитыми софт-скилами. Часто говорят, что брать на работу надо именно того, у кого подходят софты, а харды — ну, в процессе подтянем. Круто быть востребованным спецом, который и общается экологично, и конфликты умеет разруливать, и планировать, и самоорганизовываться — просто идеально!

Но… Какая есть обратная сторона у мягких навыков и какая у них "цена" — расскажу в докладе.

Создание масштабируемой и поддерживаемой системы автоматизации — не только про выбор инструментов, но и про правильную архитектуру. 

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

Вы узнаете, как с помощью декораторов, дескрипторов, __getattr__, __init_subclass__ и других механизмов Python автоматизировать рутинные задачи: от поиска элементов на странице до динамического создания API-методов. 

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

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

Запятую придётся поставить вам.

До релиза осталось совсем немного времени. Дата уже объявлена, маркетинг всё анонсировал, фичи продолжают появляться. Команда тестирования понимает простую вещь: проверить всё невозможно.

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

По ходу игры будут появляться неожиданные события: новые вводные от бизнеса, изменения в требованиях, проблемы с автотестами, пропавшие сотрудники. Придётся пересобирать стратегию и договариваться внутри команды.

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

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

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

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

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

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

При использовании Backend-Driven UI (BDUI) подхода интерфейс приложений формируется через конфигурацию CMS и верстку UI на бэкенде, что усложняет тестирование, а традиционные подходы к мокированию становятся недостаточны.

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

Что делать, когда тестирование стало узким горлышком разработки, а высокая загрузка тестировщиков замедляет поставку бизнес-ценности и увеличивает риск ошибок?

Решением может стать стандартизированный процесс интеграции AI в QA процессы, который охватывает все стадии shift-left testing: от тестирования требований до генерации автотестов.

Результаты такого внедрения говорят сами за себя:

• Ускорение тестирования в 4 раза.
• Экономия 75% времени на создание тестовой документации (5-6 часов → 1.5 часа).
• Ускорение написания автотестов на 60-70%.

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

В докладе поделюсь практическим опытом трансформации хаоса в работе с багами в управляемый процесс. На примере стрима "Заказ и Платежи" Яндекс Лавки покажу, как за 9 месяцев удалось снизить ZBP с 1000 до 150, при этом уменьшив нагрузку на QA и повысив вовлечённость разработки.

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

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

В докладе я расскажу о нашем опыте внедрения практики QA Notes в процесс разработки и тестирования.

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

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

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

Сегодня QA Notes — неотъемлемая и привычная часть работы нашей команды.

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

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

Я это четко почувствовал в поездке осенью по китайским технологические компании: Baidu, Xiaomi, SenseTime, BYD и другим. Там неудачный опыт воспринимают как важную часть истории: в музее BYD отдельный зал посвящен первой неудачной модели автомобиля, а в Xaomi рассказывают про 22 прототипа для powerbank, прежде чем появился хит продаж, и так далее. 

Такая культура эксперимента – важная составляющая быстрого развития Китая, в результате которого он готов перехватить технологическое и политическое лидерство у США в ходе промышленной революции в ближайшие 3-7 лет. В выступлении мы поговорим про китайский mindset и про логику развития мира в целом.

Доклад о практическом пути внедрения ИИ в тестирование в компании с ограничениями безопасности.

Мы покажем эволюцию использования ИИ:

• от генерации тест-кейсов по требованиям,

• к поддержке ручного тестирования,

• к формированию структурированной базы знаний,

• к генерации автотестов,

• и далее — к модели непрерывной поставки автотестов.

Разберём:

• почему “голый” вайбкодинг не масштабируется в бизнесе,

• почему кастомные AI-агенты не всегда оправданы,

• как универсальный инженерный промпт может заменить собственного агента,

• как встроить ИИ в CI/CD без сложной AI-инфраструктуры.

Покажем реальные ограничения, экономику внедрения и метрики эффективности.

Ключевая идея:

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

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

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

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

Приходите, будет не только интересно, но и полезно!

Интеграционное тестирование в масштабных экосистемах — это настоящий вызов и поле для бесконечных гонок.

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

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

Матрица компетенций в QA часто звучит как приговор: “сейчас вас измерят и сравнят”. В итоге лиды боятся внедрять, а QA — переживают, что их оценят «не так» или «по таблице без контекста».

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

В итоге матрица становится не только инструментом контроля, а частью системы управления компетенциями: она связывает роли, грейды, развитие, найм и деньги. А значит — снижает стресс, потому что у команды появляется простая логика: «это не про наказать, это про договориться и расти». 

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

АСС (Attribute, Component, Capability) – подход фирмы Google к построению тест-планов. Атрибуты – это свойства системы, важные пользователю. Компоненты – это структурные единицы с точки зрения пользователя. Возможности – это действия системы, реализуемые компонентами для обеспечения атрибутов. В АСС система представляется матрицей, где столбцы соответствуют атрибутам, строки – компонентам, а в ячейках располагаются возможности. Для каждой возможности оценивается риск отказа, что позволяет оптимально распределить ресурсы на тестирование. 

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

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

Что делать, если ты единственный E2E QA на проекте, где сошлись воедино железо, компьютерное зрение, машинное обучение и облачная инфраструктура?

В докладе я расскажу историю тестирования умной камеры с AI — устройства, которое использует VLM (Vision Language Models) для описания происходящего в кадре и создаёт суммаризацию событий дня. Покажу забавные моменты, когда модель может описать вашего кота как "маленькую собаку", почему иногда приходится выкатывать фичи без тестирования, и какие методы помогают охватить полное E2E-тестирование сложного продукта в одиночку.

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

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

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

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

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

В этом докладе представлена стратегия “Турбулентное тестирование” - системный подход к управлению качеством в условиях нестабильной нагрузки. Вместо универсального процесса предлагается контекстно-адаптивная модель, где глубина тестирования определяется критичностью и риском задачи.

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

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

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

Вы увидите:

• Что делает вопрос качественным: структура, контекст, цель и ожидаемый результат
• Техники уточнения требований через вопросы: какие вопросы задавать на разных стадиях цикла разработки
• Как избегать типичных ловушек: двусмысленности, предположения и перегрузка информации
• Методы быстрой валидации ответов: как проверить полноту, полезность и применимость полученной информации
• Роль вопросов в сокращении обходных путей и деградации качества
• Практические упражнения: формируем набор вопросов под конкретные сценарии, учимся быстро получать нужные ответы и экономим время команды

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

Представим, команда использует коробочное решение, более 15 сервисов и примерно 100 SQL-интеграций. И это только одна «коробка». Их может быть две, три и больше.

Как подобрать тестовые данные для регрессионного тестирования между системами и коробками? По каким правилам подобрать тестовые данные? Какие инструменты использовать? 

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

Поделюсь своим опытом и примерами в докладе.

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

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

Покажу, как мы реализовали SDD (Spec-Driven Development), чтобы ИИ генерировал действительно запускаемые сценарии, как скрестили кодогенерацию с SDD и какие техники помогают справляться с проблемами.

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

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

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

На примерах из реального проекта я разберу ключевые классы уязвимостей из OWASP Top-10 — от Broken Access Control до SSRF — и покажу, как их можно выявить с помощью простых, но системных проверок.

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

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

И так у нас большой проект и много всего хорошего сделано.

И у нас есть задача встроить Ай-Ай в процесс автоматизации тестирования и тестирования в целом.

Желания особого нет, а задача есть. 

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

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

Доклад посвящён тому, как выстроить стратегию QA на проекте с помощью метода «Карта гипотез».
Мы разберём принципы этого подхода, посмотрим на быстрые практические примеры и поймём, как карта помогает связывать цели качества с конкретными метриками, гипотезами и задачами команды. Участники узнают, как превращать абстрактные ожидания от качества в измеримые шаги и строить стратегию которая реально работает.

Этот доклад посвящен применению открытой геоинформационной системы QGIS (Quantum Geographic Information System) для визуализации и комплексного тестирования веб-сервисов пространственных данных.

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

Вы узнаете о ключевой роли консорциума OGC (Open Geospatial Consortium) в стандартизации протоколов географических данных. Рассмотрим популярные протоколы и единую философию их тестирования, а также разберу на практике тестирование протокола WFS (Web Feature Service) через QGIS.

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

Доклад посвящён вопросам обеспечения безопасности тестовой инфраструктуры в современных ИТ-проектах.

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

Доклад будет полезен тестировщикам, DevOps-инженерам и специалистам по качеству, заинтересованным в построении безопасной и управляемой тестовой среды.

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

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

• Процессы: почему 100% покрытие регрессом — это утопия, и как умная нарезка тест-кейсов на паки позволяет тестировать меньше, а находить больше.
• Документация и тулинг: как продуктовая документация и простые инструменты (релизный календарь, таск-боты) снимают с людей рутину.
• Автоматизация: как мы научили ботов самостоятельно собирать паки для регресса и при чем тут автотесты.

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

Знаете ли вы, что делать, если у вас начали вайб-кодить?

Вы готовы?

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

Призываем объединиться в группы и добрать необходимые компетенции среди участников конференции. Не хватило опытного специалиста в какой-то сфере? Кидай клич в чатик конфы, и помощь обязательно найдётся!

Участникам нужно иметь с собой:

• ноутбук с Android Studio (поможем установить);

• ваша любимая LLM (или готовность её приобрести);

• задор повайбтестить!

• группа единомышленников или решимость защищаться в соло.

В докладе расскажу о нашем опыте внедрения пирамиды тестирования мобильных приложений с микросервисной архитектурой (BDUI) и о том, как это существенно сократило рутинную ручную работу QA-инженеров и позволило делать релизы каждый день.

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

На своем опыте я прошел все эти крайности и пришел к системности как подходу управления людьми и командами.