✅ Почему у меня тесты гоняются на КАЖДЫЙ pull request

Правило, которое экономит недели: ни один PR не мёржится без зелёного CI.

На GitHub Actions вешаю на каждый PR: линт, юнит, ключевые API/E2E, проверку сборки. Баг ловится на ревью, а не на проде — дешевле в разы.

«Потом протестируем» = «никогда». Автопроверка на PR — самая выгодная инвестиция в качество.

У вас мёрж без прохождения CI возможен?

🏥 Автотесты под регуляторику (медтех, FDA 21 CFR Part 11)

Делал автоматизацию для регулируемого домена — там качество это требование закона, а не «хотелка».

Особенность: доказать нужно не только «работает», но и что каждое действие залогировано, подписано и воспроизводимо (audit trail, электронные подписи, контроль версий). Автотесты заодно генерят доказательную базу для аудита.

В регулируемых доменах тестировщик — часть комплаенса. Ответственность выше, и это интересно.

🔗 Баг, который не видно в UI: рассинхрон API и БД

UI зелёный, а в базе — мусор. Классика распределённых систем.

Поэтому проверяю сквозь слои:
— ответ API совпадает с тем, что реально легло в БД (PostgreSQL/Mongo)
— нет «осиротевших» записей и битых связей
— консистентность между сервисами после операции

Тестировать только через UI — значит видеть верхушку айсберга. Данные под ним важнее.

🛠️ Playwright 1.62: компонентные тесты переезжают на «stories и galleries»

Component testing в Playwright переосмыслили. Основа теперь — stories и galleries:
▪️ story оборачивает компонент в один конкретный сценарий — захардкоженные пропсы, мок-данные, нужное состояние;
▪️ galleries группируют истории — гоняешь и смотришь варианты компонента разом.

Зачем QA: меньше хрупких обёрток и рантайм-магии в тестах компонентов — по духу как Storybook, но прямо в Playwright, с его трейсами и стабильностью.

Подробнее ↗

#playwright #testing #frontend #e2e #release · Playwright

🛠️ Alibaba выложила open-code-review — гибридный авто-ревью кода

Опенсорсный инструмент код-ревью, обкатанный на масштабах Alibaba. Идея — гибрид:
▪️ детерминированные пайплайны (правила/линтеры) + LLM-агент → точечные комментарии на уровне строк;
▪️ не «AI написал абзац воды», а конкретные замечания по коду.

Зачем SDET: снимает рутину ревью и ловит очевидное до человека. Но LLM-часть держи на коротком поводке — детерминизм первичен, агент вторичен.

Подробнее ↗

#codereview #ai #devtools #quality · GitHub

👨‍🏫 Как перевести ручную QA-команду на автоматизацию (без бунта)

Менторил команду из 5 инженеров в переходе на современную автоматизацию. Что сработало:
— начинали с их же боли: самый нудный ручной кейс автоматизировали первым
— короткие воркшопы по Python вместо «идите читайте доки»
— автотест не враг ручного тестировщика, а его усилитель

Автоматизация приживается через людей, а не через фреймворк. Технологии вторичны.

🔥 GitHub Trending утонул в агентах для кодинга. Что из этого реально для QA

Открываешь трендинг — сплошь «AI coding agent»: pi, orca (флот параллельных агентов), code-review-graph и wigolo (контекст и поиск для агента через MCP), гейтвеи вроде OmniRoute. Волна.

Что стоит внимания SDET, а не только хайпа:
▪️ MCP-инструменты, дающие агенту ровно нужный контекст кодовой базы — меньше галлюцинаций в правках тестов;
▪️ оркестраторы параллельных агентов — но это сырой фронтир, не прод.

Остальное — обёртки вокруг одного LLM. Правило: агент помогает писать и чинить тесты, но диагноз и архитектуру держи за собой.

#ai #agents #mcp #sdet #devtools · наблюдение

🐳 Одинаковые окружения = конец «у меня локально работает»

Гонял Selenium/Pytest в Docker — и «работает только на моей машине» ушло как класс.

Плюсы для тестов:
— один образ локально и в CI → воспроизводимость
— поднял → погонял → снёс, никакого мусора между прогонами
— параллель на разных версиях браузера/сервиса без конфликтов

Контейнеры для QA — не «девопс-магия», а базовая гигиена стабильных тестов.

🤝 Параллельное тестирование с AI — мой любимый воркфлоу

Перед тестированием фичи прошу Claude построить тест-план и гонять его через Playwright MCP — а сам параллельно тестирую то же руками.

Проверяем одно и то же, но с РАЗНЫМИ гипотезами:
— AI находит краевые случаи, о которых я не подумал
— я нахожу то, что AI пропускает: там, где нужен бизнес-контекст и интуиция

По отдельности никто не ловит всё. Вместе — покрытие заметно шире.

Это не замена ручному QA. Это второй тестировщик, который не устаёт повторять одни и те же сценарии. Но результат всё равно нужно ревьюить: AI застревает, не понимает приложение, копает несуществующее.

Пробовали так? 👇

🧪 «Anti-AI-slop»: инструменты против мусорного кода от агентов

Появился hallmark — «скилл» для Claude Code / Cursor / Codex против AI-slop (генеративной воды и шаблонного мусора). Симптом времени: агенты пишут много, а качество проседает.

Для QA это сигнал: с ростом AI-ассистированной разработки растёт класс дефектов «выглядит правдоподобно, но неверно». Ревью и тесты теперь ловят не только логические баги, но и правдоподобный slop.

Подробнее ↗

#ai #codequality #review #testing · GitHub

📚 Чем больше контекста у AI — тем меньше догадок (у всех)

Без контекста о проекте, архитектуре и ограничениях AI начинает придумывать — тянет лишнюю сложность или решает не ту задачу.

Отсюда неожиданный вывод: актуальная дока теперь нужна не только людям, но и AI — как контекст для вменяемых решений.

Тот же эффект в автотестах: AI проверяет тесты и спокойно пропускает проблемы с изменяемыми тест-данными и скрытыми зависимостями между тестами. На проверке всё зелёное — а через месяц эти тесты нестабильны и их тяжело поддерживать.

Хорошая дока = меньше времени на догадки. И у людей, и у AI.

⚠️ AI не защищает от ошибок — отвечаешь всё равно ты

Плотно работаю с Claude и параллельно прохожу DevOps-курсы. Главный вывод: инструменты, агенты, prompt-библиотеки не страхуют от ошибок. За то, что уехало в прод, отвечаешь ты.

Ещё заметил: AI склонен к оверинжинирингу — задачу часто можно решить проще, дешевле и поддерживаемее, а он предлагает громоздкое.

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

AI — отличный ускоритель, но не замена инженерному суждению.

🔥 book to skill конвертирует pdf в код

Инструмент book-to-skill позволяет конвертировать любой технический pdf в код, готовый для изучения и использования. Это может быть полезно для разработчиков, которые хотят быстро ознакомиться с новыми технологиями или изучить конкретные аспекты программирования.

Подробнее ↗

#devtools #pdf #code · GitHub Trending

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

Реальный кейс: AI-агент через Playwright/MCP может долго пытаться кликнуть по элементу или дёрнуть эндпоинт, которого просто НЕТ. Без валидации он продолжает копать в фоне, не понимая настоящей причины.

Видел то же в инфре: агент застревает из-за отсутствующих прав, недоступных ресурсов или требований, которых на деле не существует.

Вывод: чем лучше ты понимаешь свою систему — тем больше пользы от AI. Чем хуже — тем выше риск потратить время на красивое решение не той задачи.

🔥 playwright релиз 1.62.1

Выпущена новая версия Playwright 1.62.1, в которой исправлены различные ошибки, включая регрессии, связанные с разрешением tsconfig и доступом к объектам page. Эта версия также исправляет проблемы с доступностью и обновляет функциональность image-type.

Подробнее ↗

#playwright #testing · Playwright

🧪 Slopsquatting: атака, что охотится на галлюцинации твоего ИИ

Typosquatting ставит на твою опечатку. Slopsquatting — на галлюцинацию ассистента: LLM уверенно советует npm i несуществующего пакета, а атакующий заранее регистрирует это имя с малварью.

Вывод для SDET/DevSecOps: «ИИ предложил зависимость» — теперь вектор атаки. Не ставь пакеты из ответа модели не глядя: проверь, что репо реально существует, живое и не вчера создано. Плюс lockfile, приватный реестр, сканеры.

Подробнее ↗

#supplychain #security #ai #devsecops · dev.to