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

🎥 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