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

🎥 Heisenbug 2025 Spring Плейлист
🎥 SQA Days 36 Плейлист

SQA Days:
🟣Страх задавать вопросы: как перестать бояться и начать работать — Анастасия Ушакова
🟣Как расти и растить с помощью матрицы компетенций и ИПР — Сергей Лебедев
🟣BDUI: эволюция динамических интерфейсов — Елена Кислякова
🟣Тестируем Flipper Zero: нужна ли синяя изолента — Константин Волков
🟣Quality Gates: путь к качеству на каждом этапе развития компании

Heisenbug:
🟣 Как изменится тулинг в тестировании с приходом AI — Артём Ерошенко
🟣 Падаем красиво в Playwright-тестах — Алексей Иванов
🟣Vision Language и AI Web Agent — автоматизация с BugBuster AI — Даниил Ахетов
🟣 Поднимаем Android-ферму за 10 минут — Алексей Тюрин
🟣 Пишем тесты на race conditions, deadlocks и остальной concurrency hell — Нина Лукина

Что такое сообщество?

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

И нас с Ксюшей часто спрашивают:
— Какая у вас цель? Чего вы хотите добиться?
А у нас нет цели. Это хобби.


Расскажу, как я к этому пришёл — вдруг у вас откликнется:

1⃣ Когда я начинал в IT, ходил на митапы и в бары, был в движухе, но только как участник.
2⃣Когда получил опыт, захотел об этом рассказать на конференции — и попал на другой уровень. Сообщество спикеров — это совсем другой мир.
3⃣После ковида не осталось митапов от сообществ, мне этого сильно не хватало. И тогда я понял: надо делать свой митап и своё сообщество.

Зачем вообще ходить на митапы и быть в сообществе?

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

Если вы созрели для выступления?
Можно выступить у нас на митапе MoscowQA или SPBQA
Можно подать доклад на конференцию, например на Гейзенбаг

Сообщество — это люди!
Подобрал для вас сообщество по другим направлениям в Москве

Сейчас появилось настроение писать технические заметки, пока есть мотивация буду это делать и первая в этом году естественно про ai/vibecode

Как использовать AI-ассистенты на 300% эффективнее

Проблема
Запустил промпт → сидишь 2-3 минуты → получил результат → запустил следующий
❌ Мёртвое время
❌ Сливаешь деньги впустую (если у вас тариф крутой)

⚠ Неожиданное открытие
Исследование METR (2025): опытные разработчики с AI работали на 19% медленнее, хотя сами думали, что быстрее на 20%.

Причина — время на промпты и проверку кода и ответ агента.

💡 Решение
Настройка:
1⃣ Добавь 3-4 проекта в workspace
2⃣Открой терминал для каждого проекта

Что делать?
1⃣ Запусти промпт в терминале #1
2⃣Переключись на #2 → дай промпт
3⃣ Переключись на #3 → дай промпт
4⃣ Вернись к #1 → проверь, запусти новый
5⃣ Повторяй цикл

Принцип: Пока AI работает в одном проекте — ты работаешь в друго

Завтра расскажу как это все автоматизировать!

Python — это незрелый dev-тулинг

Захотел написать кастомные линтер-правила
В JavaScript это один инструмент. В Python — это франкенштейн.

ESLint (JS):
Проверка + автофикс + плагин = один файл

Python:
🟣Ruff — быстрый, но плагинов нет
🟣Flake8 — плагины есть, автофикс нет
🟣Pylint — плагины есть, автофикс нет
🟣Автофикс — отдельно (autopep8, LibCST)

Итого: чтобы получить аналог одного ESLint-плагина, собираешь франкенштейна из трёх плюс библиотек.
2026 год на дворе

Или я что-то упускаю?
_____________
На этом пост должен был закончится!
И изначально это был наброс на эмоциях. Проанализировав, поспрашивал коллег/ребят из сообщества — оказалось, упускаю.

Есть Fixit от Meta. Тот же принцип что в ESLint: правило + автофикс = один файл. Построен на LibCST.

Но: в Fixit нет PEP8 и стандартных проверок.
Только для своих правил

Итоговый стек:
🟣Ruff — PEP8 + 800 готовых правил
🟣Fixit — кастомные правила с автофиксом

Я что-то пропустил выход DevTools MCP

И когда я читал возможности, мне показалось, что это копия Playwright MCP, но сейчас, когда разобрался, понял, что это очень крутой инструмент.

Небольшое сравнение как использовать 2 инструмента

1. Экономия токенов / контекста
✅ Chrome DevTools MCP — экономит до 90–95% контекста (не забывайте смотреть используемый контекст в Claude Code /context )
❌ Playwright MCP — жрёт очень много (13–18k токенов на старте + каждый шаг)

2. Глубина дебаггинга и перфоманс
✅ DevTools MCP — 🔥 король здесь
• Performance traces (LCP, CLS, INP, TBT)
• Core Web Vitals анализ в реальном времени
• Network + Console + Sources + всё, что есть в DevTools
• Идеально для «почему тормозит / 500 ошибка / CLS скачет»
❌ Playwright MCP — базовые логи

3. Автоматизация и тесты (E2E, формы, клики)
✅ Playwright MCP — до сих пор сильнее
• Кросс-браузер (Chrome + Firefox + Safari/WebKit)
• Лучше справляется с drag-and-drop, сложными SPA
❌ DevTools MCP — тоже умеет, но иногда менее предсказуемо + только Chrome

4. Скорость и удобство
✅ DevTools MCP — быстрее запускается, может подключатся к твоей сессии браузера
❌ Playwright MCP — часто новая чистая сессия (не разобрался как подключиться)

Что брать?
Дебаг, перфоманс, network, console, «почему сломалось приложение» → Chrome DevTools MCP
E2E-тесты → Playwright MCP

🥹 Сегодня выступаю на MoscowQA

Интересное чувство — для меня этот митап особенный: нашему сообществу 2 года и это уже 20-й митап!

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

И сейчас мне очень захотелось выступить именно на 20-м митапе.

Я очень рад, как сообщество выросло и расширяется. Призываю каждого приходить на мероприятие MoscowQA, а после — ходить в бар!
Любим вас 😍

Трансляция: https://vkvideo.ru/video-167479002_456239502

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

Стратегия выбора локаторов

Приоритет от лучшего к худшему:

1⃣ getByRole() - Лучший выбор
2⃣ getByLabel() - Для полей форм
3⃣ getByPlaceholder() - Если нет label
4⃣ getByText() - Для статического текста
5⃣ getByAltText() - Для изображений
6⃣ getByTitle() - Редко, но можно
7⃣getByTestId() - Для сложных случаев
8⃣ CSS/XPath - Не рекомендуется к использованию

Алгоритм выбора:

Это кнопка/ссылка/поле? ➡ getByRole()
Это поле с лейблом? ➡ getByLabel()
Это текст на странице? ➡ getByText()
Ничего не подходит? ➡ Добавить data-testid

🔗 Дока

Нашёл интересное исследование!

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

Собрали 1 539 реальных сценариев из open-source проектов на Python, Java и Go и оценили LLM на трёх задачах:

🎥Создание тестов с нуля
🎥 Починка тестов, которые сломались после рефакторинга
🎥Доработка тестов под новую или изменившуюся логику

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

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

Генерация — ок, а вот сопровождение тестов — пока слабое место.

🔗 Статья: huggingface.co/papers/2601.18241
🔗 Код: github.com/trndcenter/TAM-Eval