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

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

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

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

Но что делать с теми, кто сопротивляется?

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

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

Часто QA замыкается в привычном квадрате задач: тест-планы, регресс, автоматизация, метрики. Но если ты хочешь расти в профессии, пора взглянуть шире. 

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

Этот доклад для тех, кто хочет перестать быть просто исполнителем и начать видеть реальное влияние своей работы.

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

С течением времени меняются подходы, инструменты, а также понимание и важность метрик. 

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

В качестве бонуса — полезные лайфхаки для создания удобных и информативных дашбордов.

Будни техподдержки:

- Алло, у меня интернета нет, пришлите кого-нибудь исправить

- Подойдите, пожалуйста, к роутеру, мигают ли на нём лампочки?

- Нет, не мигают, электричества во всём доме нет.

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

А если совсем не доверять — насколько это осложнит жизнь тестировщику, как много подводных камней мы не заметим?

А как им вообще доверять, если они сами друг другу не верят? (для чего и придумали код-ревью)

Приходи к нам на круглый стол в секции X5 Tech в заключительный час первого дня конференции, и сможешь принять участие в эпичном холиваре, а после все дружно отправимся на After-Party

В программе круглого стола:

• Безграничное взаимное доверие - польза или вред?
• Как разработка отвечает за качество?
• Как разработка видит тестирование?
• Должен ли QA проводить code-review?
• Может ли разработчик мыслить как тестировщик?
• Дружить или не дружить?
• Нужен ли регламент взаимодействия QA и Dev?

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

Поговорим про карьерный путь QA вне QA. Как из тестирования переходить в соседние области ИТ и не только ИТ.

Посмотрим модели развития и почему T-shape уже не модно.

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

Покажу пути — через практику и реальные кейсы, а не теорию переходов.

В данном докладе автор раскроет тему роли ведущего тестировщика (QA Lead). 

• На примере собственного опыта, будет продемонстрировано как и когда роль появляется.
• Как она ложится в структуру компании.
• Какова зона ответственности ведущего тестировщика. 
• Какие ожидания от других участников команды.
• Как стать ведущим тестировщиком и какие навыки нужны. 
• Какой бывает ведущий тестировщик ("перекладыватель" задач/маленький head и т.д.)

В докладе разберём тему роли QA Lead.

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

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

Приведу пример нашей структуры, роли в ней QA лида и зону ответственности.

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

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

Давайте поговорим об особенностях работы распределенной команды, от «классических» проблем найма и до адаптации процессов.

Я более 5 лет взаимодействую с распределенной командой, в офисе нет ни одного тестировщика!

Давайте поговорим об особенностях работы распределенной команды, от «классических» проблем найма и до адаптации процессов.

Я более 5 лет взаимодействую с распределенной командой, в офисе нет ни одного тестировщика!

Му’да — это одно из японских слов, которое означает потери, отходы, то есть любую деятельность, которая потребляет ресурсы, но не создает ценности.

Если посмотреть на работу QA, то очень быстро находятся вещи, которые являются той самой Му’да, например:

• потери времени из-за ожидания;

• потери при ненужных действиях;

• потери из-за ошибочных действий;

• потери из-за лишних этапов.

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

Особенно это заметно при работе новых сотрудников.

Мы стараемся автоматизировать все вещи, где:

• возможен человеческий фактор (ошибки, невнимательность, неопытность);

• все, что не нравится и не интересно делать;

• все, что занимает слишком много времени при ручном режиме.

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

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

Расскажу, как мы начинали набирать и как трансформировался процесс в момент, когда нужно было набирать по 3-4 человека в месяц, а ресурсов на это было 1 HR и 1 QA head.

CI/CD - процесс который должен быть быстрым и стабильным. 

Но, что делать, если UI тесты занимают 10 часов в одном потоке, а к этому еще прибавить нагрузочные тесты, unit, API и другие.

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

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

Тема: CI для тестировщиков или как отказаться от релизов

• Как ускорить тестирование, не теряя качества

• Контроль удаленной команды

• Как повысить прозрачность тестирования для разработки и помочь им выдавать задачи качественнее
• Эффективное использование Jira и TestRail - связка и автоматизация