👋 Всем привет!
Я Дима — QA/SDET-инженер. Пишу и гоняю автотесты, лезу в инфру и коллекционирую грабли, на которые наступаю по дороге.
Здесь, в «Тесты и грабли», будет по делу и без прикрас:
▪️ наблюдения из практики — реальные факапы с e2e, CI и окружениями, и как мы из них выбирались;
▪️ интервью с инженерами — QA/SDET/DevOps делятся живым опытом;
▪️ свежие инструменты и релизы по теме — Playwright, k8s, ИИ-агенты для тестов и не только.
так же будут видео с собесов
Я Дима — QA/SDET-инженер. Пишу и гоняю автотесты, лезу в инфру и коллекционирую грабли, на которые наступаю по дороге.
Здесь, в «Тесты и грабли», будет по делу и без прикрас:
▪️ наблюдения из практики — реальные факапы с e2e, CI и окружениями, и как мы из них выбирались;
▪️ интервью с инженерами — QA/SDET/DevOps делятся живым опытом;
▪️ свежие инструменты и релизы по теме — Playwright, k8s, ИИ-агенты для тестов и не только.
так же будут видео с собесов
Тесты и грабли pinned «👋 Всем привет! Я Дима — QA/SDET-инженер. Пишу и гоняю автотесты, лезу в инфру и коллекционирую грабли, на которые наступаю по дороге. Здесь, в «Тесты и грабли», будет по делу и без прикрас: ▪️ наблюдения из практики — реальные факапы с e2e, CI и окружениями…»
🔥 e2e-тесты и параллельный прогон — огонь. Но будь готов на щелчок по носу от окружения
Писать e2e, ускорять их, гонять на 2+ воркерах — правильно и мощно. Только параллелизм упирается не в тесты, а в то, что под ними.
Кейс с прод-подобного stg: прогоны посыпались каскадом. /studies/ висит >60 с — вечный спиннер, следом падают API и логин.
Первая мысль — «флейки, чиним тесты». А нет. Железо простаивало — упёрлись в потолок коннектов БД:
▪️ db-f1-micro даёт всего 25 соединений на всех — в норме мы и так сидим почти впритык.
▪️ Проверили экспериментом: +1 реплика backend → коннекты дошли до 26 → FATAL: connection slots → легли и API, и логин.
Что сделали (временно и обратимо):
▪️ Подняли max_connections 25 → 50 на том же дешёвом инстансе. Апгрейд размера БД не брали — слишком дорого; лимит коннектов снимает главный потолок почти даром.
▪️ Вернули 2 реплики backend — есть чем дышать, реальная параллельная ёмкость для /studies/.
Зачем так: если каскад исчезнет — это доказательство для команды, что упор в коннекты БД + ёмкость бэкенда, а лечится настройкой лимита и репликами — не переписыванием тестов и не дорогим апгрейдом БД. Плюс готовая целевая конфигурация под terraform.
Мораль: сильный e2e-инженер не только пишет и параллелит тесты — он читает метрики окружения и лезет в инфру. Иначе «тесты флейкают» останется вечным диагнозом там, где на самом деле задыхается БД.
#e2e #testing #devops #infra #postgres #staging · из практики
Писать e2e, ускорять их, гонять на 2+ воркерах — правильно и мощно. Только параллелизм упирается не в тесты, а в то, что под ними.
Кейс с прод-подобного stg: прогоны посыпались каскадом. /studies/ висит >60 с — вечный спиннер, следом падают API и логин.
Первая мысль — «флейки, чиним тесты». А нет. Железо простаивало — упёрлись в потолок коннектов БД:
▪️ db-f1-micro даёт всего 25 соединений на всех — в норме мы и так сидим почти впритык.
▪️ Проверили экспериментом: +1 реплика backend → коннекты дошли до 26 → FATAL: connection slots → легли и API, и логин.
Что сделали (временно и обратимо):
▪️ Подняли max_connections 25 → 50 на том же дешёвом инстансе. Апгрейд размера БД не брали — слишком дорого; лимит коннектов снимает главный потолок почти даром.
▪️ Вернули 2 реплики backend — есть чем дышать, реальная параллельная ёмкость для /studies/.
Зачем так: если каскад исчезнет — это доказательство для команды, что упор в коннекты БД + ёмкость бэкенда, а лечится настройкой лимита и репликами — не переписыванием тестов и не дорогим апгрейдом БД. Плюс готовая целевая конфигурация под terraform.
Мораль: сильный e2e-инженер не только пишет и параллелит тесты — он читает метрики окружения и лезет в инфру. Иначе «тесты флейкают» останется вечным диагнозом там, где на самом деле задыхается БД.
#e2e #testing #devops #infra #postgres #staging · из практики
🧪 Флейки лечат не ретраями, а изоляцией и ожиданиями
Ретрай на упавшем тесте прячет проблему, а не решает. Стабильные e2e начинаются не с --retries, а с трёх вещей:
▪️ Никаких sleep(3000) — только web-first ожидания (ждём состояние/элемент, а не время). Отсюда 90% «мигающих» падений.
▪️ Изоляция данных на воркер. Тесты дерутся за общего юзера/запись → рандомные падения на параллели. Дай каждому воркеру свои данные (префикс/namespace/отдельный аккаунт).
▪️ Чистый старт. Не полагайся на состояние от прошлого теста — каждый сам создаёт и убирает своё.
Ретрай оставь как сигнал «тест нестабилен, разберись», а не как лечение.
#e2e #flaky #testing #qa #automation · заметка
Ретрай на упавшем тесте прячет проблему, а не решает. Стабильные e2e начинаются не с --retries, а с трёх вещей:
▪️ Никаких sleep(3000) — только web-first ожидания (ждём состояние/элемент, а не время). Отсюда 90% «мигающих» падений.
▪️ Изоляция данных на воркер. Тесты дерутся за общего юзера/запись → рандомные падения на параллели. Дай каждому воркеру свои данные (префикс/namespace/отдельный аккаунт).
▪️ Чистый старт. Не полагайся на состояние от прошлого теста — каждый сам создаёт и убирает своё.
Ретрай оставь как сигнал «тест нестабилен, разберись», а не как лечение.
#e2e #flaky #testing #qa #automation · заметка
🟢 Прогон зелёный, а прод лёг. Почему e2e — не гарантия
e2e гоняет happy-path в стерильном stg на игрушечных данных. Прод падает от другого:
▪️ Нагрузка и конкуренция — коннекты к БД, лимиты, тайминги; на stg их нет.
▪️ Реальные данные — пустые/огромные/кривые записи, которых нет в фикстурах.
▪️ Интеграции и конфиг — сторонние сервисы, фичефлаги, env, отличные от stg.
e2e ловит регрессии логики, но не заменяет observability. Нужны метрики, алерты и синтетика в проде — иначе «у нас всё зелёное» прозвучит ровно в момент инцидента.
#testing #devops #observability #sre #qa · заметка
e2e гоняет happy-path в стерильном stg на игрушечных данных. Прод падает от другого:
▪️ Нагрузка и конкуренция — коннекты к БД, лимиты, тайминги; на stg их нет.
▪️ Реальные данные — пустые/огромные/кривые записи, которых нет в фикстурах.
▪️ Интеграции и конфиг — сторонние сервисы, фичефлаги, env, отличные от stg.
e2e ловит регрессии логики, но не заменяет observability. Нужны метрики, алерты и синтетика в проде — иначе «у нас всё зелёное» прозвучит ровно в момент инцидента.
#testing #devops #observability #sre #qa · заметка
🧩 Почему я разбиваю E2E на изолированные CI-стейджи
Монолитный E2E-джоб — боль: упал один шаг, а перезапускать надо всё, и непонятно, где течёт.
Что стабилизировало пайплайн на бизнес-критичных флоу:
— каждый логический блок = отдельный стейдж со своим сетапом/тир-дауном
— падение локализуется мгновенно, ретраится только упавший кусок
— скрины/трейсы/логи собираются по стейджам
«Мигающих» падений почти не осталось, надёжность выросла заметно.
Монолитный E2E-джоб — боль: упал один шаг, а перезапускать надо всё, и непонятно, где течёт.
Что стабилизировало пайплайн на бизнес-критичных флоу:
— каждый логический блок = отдельный стейдж со своим сетапом/тир-дауном
— падение локализуется мгновенно, ретраится только упавший кусок
— скрины/трейсы/логи собираются по стейджам
«Мигающих» падений почти не осталось, надёжность выросла заметно.
🔎 Разбор инцидента за минуты, а не часы
Самое дорогое в инциденте — не фикс, а поиск причины в тоннах логов.
Написал на Python движок, который парсит логи и тянет паттерны из Splunk: сам подсвечивает аномалии и вероятную первопричину. Время расследования инцидента упало примерно на 20%.
Мораль: наблюдаемость — это часть работы QA/SDET, а не только «девопсов». Кто первый находит причину — тот и герой релиза.
Чем копаете логи — грепом или чем-то умнее?
Самое дорогое в инциденте — не фикс, а поиск причины в тоннах логов.
Написал на Python движок, который парсит логи и тянет паттерны из Splunk: сам подсвечивает аномалии и вероятную первопричину. Время расследования инцидента упало примерно на 20%.
Мораль: наблюдаемость — это часть работы QA/SDET, а не только «девопсов». Кто первый находит причину — тот и герой релиза.
Чем копаете логи — грепом или чем-то умнее?
🎭 Playwright на Python или TypeScript — что выбрать?
Гонял оба в проде. Коротко:
— TS: роднее для Playwright (доки, релизы, авто-вейты «из коробки»), лучше для фронт-команд
— Python: если стек уже питоновый (API-тесты, дата-пайплайны, скрипты) — не плоди зоопарк языков
Мой критерий: бери язык, на котором говорит команда и бэкенд. Единый стек > «модный» фреймворк.
На чём вы пишете UI-автотесты?
Гонял оба в проде. Коротко:
— TS: роднее для Playwright (доки, релизы, авто-вейты «из коробки»), лучше для фронт-команд
— Python: если стек уже питоновый (API-тесты, дата-пайплайны, скрипты) — не плоди зоопарк языков
Мой критерий: бери язык, на котором говорит команда и бэкенд. Единый стек > «модный» фреймворк.
На чём вы пишете UI-автотесты?
🤖 Как AI реально экономит время в автотестах
Использую AI в рабочем цикле, но не слепо:
— черновик теста по описанию фичи → правлю под реальные локаторы
— разбор упавшего трейса: скармливаю лог → получаю гипотезу быстрее
— Playwright MCP: агент сам ходит по странице и помогает достать стабильные селекторы
Важно: AI — это ускоритель джуна внутри сеньора, не замена ревью. Всё, что он генерит, проходит через мои глаза.
Пускаете AI в свой тестовый код? И до какой границы?
Использую AI в рабочем цикле, но не слепо:
— черновик теста по описанию фичи → правлю под реальные локаторы
— разбор упавшего трейса: скармливаю лог → получаю гипотезу быстрее
— Playwright MCP: агент сам ходит по странице и помогает достать стабильные селекторы
Важно: AI — это ускоритель джуна внутри сеньора, не замена ревью. Всё, что он генерит, проходит через мои глаза.
Пускаете AI в свой тестовый код? И до какой границы?
📊 Prometheus + Grafana + Alertmanager глазами тестировщика
Собрал мониторинг на staging — и это изменило подход к QA:
— метрики приложения на дашборде = вижу деградацию ДО того, как её найдёт ручной тест
— алерты на аномалии = регресс ловится в реальном времени, а не в отчёте на следующий день
Тестировать без наблюдаемости — как вести машину с закрытыми глазами: едешь, пока не врежешься.
У вас QA смотрит в метрики или только в тест-репорты?
Собрал мониторинг на staging — и это изменило подход к QA:
— метрики приложения на дашборде = вижу деградацию ДО того, как её найдёт ручной тест
— алерты на аномалии = регресс ловится в реальном времени, а не в отчёте на следующий день
Тестировать без наблюдаемости — как вести машину с закрытыми глазами: едешь, пока не врежешься.
У вас QA смотрит в метрики или только в тест-репорты?
🔐 Как я закрыл дев/staging без возни с классическим VPN
Открытые тестовые окружения — дыра: и данные текут, и «левые» стучатся.
Поднял Tailscale (mesh-VPN на WireGuard): доступ к staging только для своих устройств, публичных портов — ноль. Настройка ~15 минут.
Тестовое окружение должно быть закрытым по умолчанию. Безопасность — тоже качество.
Чем закрываете нестендовые окружения?
Открытые тестовые окружения — дыра: и данные текут, и «левые» стучатся.
Поднял Tailscale (mesh-VPN на WireGuard): доступ к staging только для своих устройств, публичных портов — ноль. Настройка ~15 минут.
Тестовое окружение должно быть закрытым по умолчанию. Безопасность — тоже качество.
Чем закрываете нестендовые окружения?
🧪 Как тестировать дата-пайплайны (Airflow + Spark), а не только UI
Тестить кнопки умеют все, а данные — редко. А там самые дорогие баги: тихо испортил датасет — узнал через месяц.
Что проверяю в ETL:
— схема и типы на входе/выходе (контракт данных)
— «не потерялись ли строки»: count на источнике vs приёмнике
— битые записи не роняют пайплайн, а уходят в карантин
— идемпотентность: повторный прогон не дублирует
Данные — это тоже продукт. Их надо тестировать.
Тестить кнопки умеют все, а данные — редко. А там самые дорогие баги: тихо испортил датасет — узнал через месяц.
Что проверяю в ETL:
— схема и типы на входе/выходе (контракт данных)
— «не потерялись ли строки»: count на источнике vs приёмнике
— битые записи не роняют пайплайн, а уходят в карантин
— идемпотентность: повторный прогон не дублирует
Данные — это тоже продукт. Их надо тестировать.
🐤 Canary-проверки: как ловить дрейф данных рано
Canary — набор лёгких проверок, что данные «в норме» на каждом прогоне:
— ключевые поля не null, где не должны
— объёмы/распределения не скакнули в разы
— свежесть: данные обновились, а не застряли
Дешевле полного теста и ловит 80% «тихих» поломок данных до того, как их увидит бизнес.
Canary — набор лёгких проверок, что данные «в норме» на каждом прогоне:
— ключевые поля не null, где не должны
— объёмы/распределения не скакнули в разы
— свежесть: данные обновились, а не застряли
Дешевле полного теста и ловит 80% «тихих» поломок данных до того, как их увидит бизнес.
✅ Почему у меня тесты гоняются на КАЖДЫЙ pull request
Правило, которое экономит недели: ни один PR не мёржится без зелёного CI.
На GitHub Actions вешаю на каждый PR: линт, юнит, ключевые API/E2E, проверку сборки. Баг ловится на ревью, а не на проде — дешевле в разы.
«Потом протестируем» = «никогда». Автопроверка на PR — самая выгодная инвестиция в качество.
У вас мёрж без прохождения CI возможен?
Правило, которое экономит недели: ни один PR не мёржится без зелёного CI.
На GitHub Actions вешаю на каждый PR: линт, юнит, ключевые API/E2E, проверку сборки. Баг ловится на ревью, а не на проде — дешевле в разы.
«Потом протестируем» = «никогда». Автопроверка на PR — самая выгодная инвестиция в качество.
У вас мёрж без прохождения CI возможен?
🏥 Автотесты под регуляторику (медтех, FDA 21 CFR Part 11)
Делал автоматизацию для регулируемого домена — там качество это требование закона, а не «хотелка».
Особенность: доказать нужно не только «работает», но и что каждое действие залогировано, подписано и воспроизводимо (audit trail, электронные подписи, контроль версий). Автотесты заодно генерят доказательную базу для аудита.
В регулируемых доменах тестировщик — часть комплаенса. Ответственность выше, и это интересно.
Делал автоматизацию для регулируемого домена — там качество это требование закона, а не «хотелка».
Особенность: доказать нужно не только «работает», но и что каждое действие залогировано, подписано и воспроизводимо (audit trail, электронные подписи, контроль версий). Автотесты заодно генерят доказательную базу для аудита.
В регулируемых доменах тестировщик — часть комплаенса. Ответственность выше, и это интересно.