автоматизация

25 докладов на митапах Moscow QA

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

Moscow QA #28 x Чёрный митап 18+ ·

Я больше 10 лет в автоматизации тестирования. И когда начинал делать BugBuster, у меня в голове была железобетонная картина мира: «Все страдают от хрупких тестов, всем нужны автотесты максимально близкие к пользователю». Оказалось, эта картина была правильной для меня, но абсолютно неверной для бизнеса. Это не история о том, какой бизнес плохой. Это история о том, как я сам себя обманул, построив продукт вокруг собственных привычек, и почему в итоге проект ушёл в опенсорс.

Метрики автоматизации. Зачем, когда и как они вам нужны

Moscow QA #27 x Мир Plat.Form ·

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

Интеграционные тесты как сервис: платформа вместо героизма

Moscow QA #27 x Мир Plat.Form ·

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

Почему автоматизация тестов заканчивается там, где начинаются тестовые учетные записи

Moscow QA #26 x «Школа 21» ·

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

Тесты на API без рук

Moscow QA #25 x Ozon Tech ·

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

Локальный ИИ в контуре CI/CD: практика автономной генерации автотестов для микросервисов

Шорт-трек от сообщества Moscow QA на Heisenbug 2026 Spring ·

Можно ли доверить ИИ написание автотестов для продакшена? Да, если держать модель внутри контура, контролировать контекст и валидировать результат. Как выбрать модель, настроить промпты и масштабировать решение на множество микросервисов.

Смешать, но не взбалтывать: коктейль для разбора падений автотестов с GPT

Шорт-трек от сообщества Moscow QA на Heisenbug 2026 Spring ·

Каждый, у кого есть автотесты, знает боль: тест упал, логов много, времени мало, а причина неочевидна. Зачем страдать, если можно делегировать разбор ИИ.

Помогите, flaky!

Moscow QA #22 x 2ГИС ·

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

Как мы прокачали автотесты с 0 до keyword-driven

Moscow QA #22 x 2ГИС ·

Как менялись подходы к автоматизации тестирования на примере проекта с автотестами. Начали с рекордера и пришли к keyword-driven. Разные подходы к автоматизации и проблемы, с которыми столкнулись. Тестирование на основе ключевых слов и его реализация на стеке PW+TS.

Автоматизированное тестирование нового поколения: Как ИИ меняет жизнь тестировщика

Moscow QA #21 x M2 ·

Разработка уникального фреймворка для автоматизированного тестирования, универсализация инструментов, взаимодействие с ИИ и автоматическая генерация тестов.

Архитектура читаемых тестов на Playwright

Moscow QA #20 x Школа 21 ·

Тест упал на 37-й строке из 50. Что именно пошло не так? На каком логическом шаге произошла ошибка? Почему assertion не прошел? Доклад для тех, кто хотя бы раз тратил часы на разбор падений автотестов.

Как погрузиться в автоматизацию за 60 дней

Moscow QA #17 x Ви Tech ·

Опыт погружения QA-лида ручного тестирования в автотесты на Playwright + TypeScript за 2 месяца. Роль ИИ в обучении.

Как Flakyzavr съел наши проблемы

Moscow QA #14 x Газпромбанк.Тех ·

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

От интеграционных релизов к компонентным тестам

Moscow QA #14 x Газпромбанк.Тех ·

Путь от огромных интеграционных релизов к компонентному тестированию: внедрение feature toggle, TBD и смещение тестирования левее.

Тестируем словами: автотест без кода в реальном времени

Moscow QA #14 x Газпромбанк.Тех ·

Автотесты на Vision Language модели без кода, без локаторов, без инфраструктуры. Живое тестирование на языке пользователя с интерактивом.

Как мы укротили tempest и тестируем с его помощью компоненты облака

Moscow QA #11 x VK Tech ·

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

Allure Report 3

Moscow QA #10 (Санкт-Петербург) x ЮMoney ·

Новая версия Allure Report: доступные фичи, планы на будущее. Много технических примеров и лайвкодинга.

Аудит автотестов

Moscow QA #10 (Санкт-Петербург) x ЮMoney ·

Как снять «розовые очки» и трезво оценить покрытие процессов автотестами. Почему важно измерять покрытие и возможно ли приблизиться к 100%.

QA и юнит-тесты? Используем Jest и Testing Library

Moscow QA #9 x МТС Финтех ·

Инструменты для юнит-тестов, которые можно внедрить в любой frontend-проект. Почему не стоит бояться QA писать юнит-тесты, как помочь разработке и дёшево автоматизировать приложение.

SDET и разработка железа Flipper Zero. Получаем качественный продукт с конвейера

Moscow QA #8 x МТС Диджитал ·

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

Асинхронность в мире автоматизации тестирования

Moscow QA #8 x МТС Диджитал ·

Фронтенд разработчики используют асинхронность для создания отзывчивого UI, бэкенд разработчики — для обработки большего количества запросов. А как тестировщики могут использовать асинхронность? Есть ли вообще ей место в мире тестирования?

Чем мы заняты, когда не пишем автотесты

Moscow QA #6 x РТК ИТ ·

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

Проблемы поддержки АТ при большом регрессе

Moscow QA #3 x СберМаркет Tech ·

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

Тестируем Flipper Zero. Автотесты, электроника и синяя изолента

Moscow QA #2 x Самолет ·

Вы знаете теорию тестирования и легко пишете автотесты? Тогда предлагаем попробовать протестировать устройство, взаимодействующее с объектами вокруг нас. Константин кратко обсудит автотесты на стыке электроники и веба.

Практическая сторона тестов

Moscow QA #2 x Самолет ·

Александр поделится личным опытом болей и радостей жизни с тестами и без. Обсудим лучшие и худшие практики. Посмотрим вместе код.