#automationTesting
В UI-тестировании есть неприятная зона между ручной проверкой и полноценной автоматизацией. Руками делать долго и скучно, а полноценная автоматизация всё ещё требует кода, времени и поддержки. Особенно в регрессах где нужно просто повторять типовые действия: открыть окно, нажать кнопки, ввести данные, проверить текст, снять результат.
В нашем сегодняшнем материале автор поделится историей создания утилиты RTHelper для автоматизации ручного тестирования UI, расскажет о подходах к поиску и управлению элементами в Windows и браузерах, стабилизации сценариев с помощью умных ожиданий и проверок, а также о формировании отчётов и визуальной отладке тестов.
Как я сделал утилиту для автоматизации ручных тестов
В UI-тестировании есть неприятная зона между ручной проверкой и полноценной автоматизацией. Руками делать долго и скучно, а полноценная автоматизация всё ещё требует кода, времени и поддержки. Особенно в регрессах где нужно просто повторять типовые действия: открыть окно, нажать кнопки, ввести данные, проверить текст, снять результат.
В нашем сегодняшнем материале автор поделится историей создания утилиты RTHelper для автоматизации ручного тестирования UI, расскажет о подходах к поиску и управлению элементами в Windows и браузерах, стабилизации сценариев с помощью умных ожиданий и проверок, а также о формировании отчётов и визуальной отладке тестов.
Как я сделал утилиту для автоматизации ручных тестов
👍3
#softwareTesting #automationTesting
API-тестирование — это та часть QA, которую часто делают на глаз. Открыл Postman, потыкал пару эндпоинтов, всё ответило 200 — окей, работает. Но это не тестирование, это проверка что сервер вообще живой.
В статье автор разберёт конкретные вещи, которые стоит проверять в API, покажет как это делать в Postman и через автотесты на JavaScript, и даст чеклист который можно взять и использовать прямо сейчас.
Как я тестирую API: чеклист и подходы, и автоматизация
API-тестирование — это та часть QA, которую часто делают на глаз. Открыл Postman, потыкал пару эндпоинтов, всё ответило 200 — окей, работает. Но это не тестирование, это проверка что сервер вообще живой.
В статье автор разберёт конкретные вещи, которые стоит проверять в API, покажет как это делать в Postman и через автотесты на JavaScript, и даст чеклист который можно взять и использовать прямо сейчас.
Как я тестирую API: чеклист и подходы, и автоматизация
❤2
#softwareTesting
Тестовая стратегия (или стратегия тестирования) — это общий план и принципы, на которых строится процесс тестирования. Она помогает задать чёткую структуру, чтобы команда тестировщиков могла работать слаженно и без лишней суеты.
В нашем сегодняшнем материале автор поделиться подробным руководством по составлению тестовой стратегии: объяснит, что это такое, какие виды стратегий бывают, из каких ключевых разделов (уровни тестирования, цели, подходы, метрики, риски) она состоит, приведёт готовый пример и сравнит стратегию с планом тестирования.
Тестовая стратегия: что это и как её составить
Тестовая стратегия (или стратегия тестирования) — это общий план и принципы, на которых строится процесс тестирования. Она помогает задать чёткую структуру, чтобы команда тестировщиков могла работать слаженно и без лишней суеты.
В нашем сегодняшнем материале автор поделиться подробным руководством по составлению тестовой стратегии: объяснит, что это такое, какие виды стратегий бывают, из каких ключевых разделов (уровни тестирования, цели, подходы, метрики, риски) она состоит, приведёт готовый пример и сравнит стратегию с планом тестирования.
Тестовая стратегия: что это и как её составить
👍2
#proQuality_books #automationTesting
📖 Writing API Tests with Karate: Enhance your API testing for improved security and performance (2023)
Автор: Benjamin Bischoff
Количество страниц: 326
Язык издания: Английский
В этой книге рассматривается Karate — мощный, но простой в освоении фреймворк для автоматизации тестирования, описано, как бесшовно интегрировать тесты в CI/CD, проводить тестирование API и UI, а также оценивать производительность приложений.
Плюсы:
➕ Понятное и практичное руководство, охватывающее как основы, так и продвинутые функции фреймворка.
➕ Отличная модульная структура: главы легко читать по порядку или использовать как справочник для конкретных задач.
➕ Большое количество готовых примеров кода, включая интеграцию с GitHub Actions и нагрузочное тестирование в связке с Gatling.
➕ Наличие бесплатного репозитория на GitHub с демонстрационными материалами.
Минусы:
➖ Книга целиком сфокусирована на фреймворке Karate и не рассматривает теорию тестирования API без привязки к конкретному инструменту.
➖ Не подойдет тем, кто не знаком с концепциями веб-сервисов и протоколами передачи данных: книга требует предварительного освоения базовых терминов.
Для кого книга:
✔️ QA-инженеров и разработчиков, желающих автоматизировать тестирование API с помощью легкого современного фреймворка.
✔️ Начинающих автоматизаторов, которым нужно пошаговое руководство по настройке окружения и созданию первых автотестов с нуля.
Об авторе:
Benjamin Bischoff — QA-эксперт с 15-летним опытом в разработке ПО и автоматизации, создает популярные open-source решения для Cucumber BDD и ведет профессиональный блог о тестировании.
📖 Writing API Tests with Karate: Enhance your API testing for improved security and performance (2023)
Автор: Benjamin Bischoff
Количество страниц: 326
Язык издания: Английский
В этой книге рассматривается Karate — мощный, но простой в освоении фреймворк для автоматизации тестирования, описано, как бесшовно интегрировать тесты в CI/CD, проводить тестирование API и UI, а также оценивать производительность приложений.
Плюсы:
➕ Понятное и практичное руководство, охватывающее как основы, так и продвинутые функции фреймворка.
➕ Отличная модульная структура: главы легко читать по порядку или использовать как справочник для конкретных задач.
➕ Большое количество готовых примеров кода, включая интеграцию с GitHub Actions и нагрузочное тестирование в связке с Gatling.
➕ Наличие бесплатного репозитория на GitHub с демонстрационными материалами.
Минусы:
➖ Книга целиком сфокусирована на фреймворке Karate и не рассматривает теорию тестирования API без привязки к конкретному инструменту.
➖ Не подойдет тем, кто не знаком с концепциями веб-сервисов и протоколами передачи данных: книга требует предварительного освоения базовых терминов.
Для кого книга:
✔️ QA-инженеров и разработчиков, желающих автоматизировать тестирование API с помощью легкого современного фреймворка.
✔️ Начинающих автоматизаторов, которым нужно пошаговое руководство по настройке окружения и созданию первых автотестов с нуля.
Об авторе:
Benjamin Bischoff — QA-эксперт с 15-летним опытом в разработке ПО и автоматизации, создает популярные open-source решения для Cucumber BDD и ведет профессиональный блог о тестировании.
👍5❤1
#ProQuality_case
🚨 Искусственный интеллект пишет 80% кода в Anthropic: к чему готовиться QA?
Институт Anthropic (создатели нейросети Claude) опубликовал впечатляющий отчет о «рекурсивном самосовершенствовании» ИИ. Они наглядно показали, как разработка новых систем всё больше передается самим нейросетям, и это напрямую влияет на процессы обеспечения качества.
Ключевые инсайты из статьи, которые заставляют задуматься:
🔹 80% всего кода, который мержится в кодовую базу Anthropic (по данным на май 2026 года), сейчас пишет сам Claude! Инженеры выступают в роли постановщиков задач и ревьюеров.
🔹 Ускорение в 8 раз: сегодня средний инженер Anthropic мержит в 8 раз больше кода в день, чем в 2024 году, просто делегируя рутину ИИ-агентам.
🔹 Качество кода: авторы признают, что если в 2025 году ИИ-код уступал человеческому, то сегодня они достигли паритета. А в течение года ожидается, что ИИ начнет писать код строго лучше людей.
🛡 А что с багами и тестированием? (Самое интересное для нас)
С таким сумасшедшим ростом объема кода ручное тестирование и код-ревью моментально становятся «узким местом». Чтобы решить эту проблему, в Anthropic внедрили автоматизированного Claude-ревьюера, который проверяет все изменения на дефекты и уязвимости перед мержем.
Ретроспективный анализ показал: такой ИИ-агент отловил бы около 33% критических багов, которые в прошлом приводили к реальным инцидентам на проде. И это при том, что изначально этот код писали инженеры мирового уровня!
По прогнозам Anthropic, роль человека в SDLC стремительно сужается. Вскоре нашим главным преимуществом останется способность решать, какие именно проблемы тестировать, как оценивать риски и можно ли доверять результатам.
🔗 Anthropic Institute: When AI builds itself
💬 Когда разработчики с помощью ИИ начнут поставлять в 8 раз больше фичей, как QA-командам справляться с таким потоком? Станут ли ИИ-агенты для тестирования (которые сами пишут и проверяют автотесты) единственным способом выжить, или классический подход всё еще сможет конкурировать?
🚨 Искусственный интеллект пишет 80% кода в Anthropic: к чему готовиться QA?
Институт Anthropic (создатели нейросети Claude) опубликовал впечатляющий отчет о «рекурсивном самосовершенствовании» ИИ. Они наглядно показали, как разработка новых систем всё больше передается самим нейросетям, и это напрямую влияет на процессы обеспечения качества.
Ключевые инсайты из статьи, которые заставляют задуматься:
🔹 80% всего кода, который мержится в кодовую базу Anthropic (по данным на май 2026 года), сейчас пишет сам Claude! Инженеры выступают в роли постановщиков задач и ревьюеров.
🔹 Ускорение в 8 раз: сегодня средний инженер Anthropic мержит в 8 раз больше кода в день, чем в 2024 году, просто делегируя рутину ИИ-агентам.
🔹 Качество кода: авторы признают, что если в 2025 году ИИ-код уступал человеческому, то сегодня они достигли паритета. А в течение года ожидается, что ИИ начнет писать код строго лучше людей.
🛡 А что с багами и тестированием? (Самое интересное для нас)
С таким сумасшедшим ростом объема кода ручное тестирование и код-ревью моментально становятся «узким местом». Чтобы решить эту проблему, в Anthropic внедрили автоматизированного Claude-ревьюера, который проверяет все изменения на дефекты и уязвимости перед мержем.
Ретроспективный анализ показал: такой ИИ-агент отловил бы около 33% критических багов, которые в прошлом приводили к реальным инцидентам на проде. И это при том, что изначально этот код писали инженеры мирового уровня!
По прогнозам Anthropic, роль человека в SDLC стремительно сужается. Вскоре нашим главным преимуществом останется способность решать, какие именно проблемы тестировать, как оценивать риски и можно ли доверять результатам.
🔗 Anthropic Institute: When AI builds itself
💬 Когда разработчики с помощью ИИ начнут поставлять в 8 раз больше фичей, как QA-командам справляться с таким потоком? Станут ли ИИ-агенты для тестирования (которые сами пишут и проверяют автотесты) единственным способом выжить, или классический подход всё еще сможет конкурировать?
Anthropic
When AI builds itself
Our progress toward recursive self-improvement, and its implications.
👍3
#automationTesting
Есть две основные категории тестов: модульные (или юнит-тесты) и интеграционные. Модульные тесты — маленькие, быстрые и изолированные. Они проверяют одну единицу кода, обычно функцию или метод, отдельно от остальной системы. Интеграционные тесты, наоборот, проверяют, как разные части системы работают вместе.
В нашем сегодняшнем материале автор поделиться опытом написания изолированных интеграционных тестов с помощью Testcontainers на примере PostgreSQL, объяснит преимущества этого подхода перед моками и общими тестовыми окружениями, а также покажет, как поднять контейнер, применить миграции и интегрировать его в тесты на ASP.NET.
Как писать изолированные интеграционные тесты с Testcontainers
Есть две основные категории тестов: модульные (или юнит-тесты) и интеграционные. Модульные тесты — маленькие, быстрые и изолированные. Они проверяют одну единицу кода, обычно функцию или метод, отдельно от остальной системы. Интеграционные тесты, наоборот, проверяют, как разные части системы работают вместе.
В нашем сегодняшнем материале автор поделиться опытом написания изолированных интеграционных тестов с помощью Testcontainers на примере PostgreSQL, объяснит преимущества этого подхода перед моками и общими тестовыми окружениями, а также покажет, как поднять контейнер, применить миграции и интегрировать его в тесты на ASP.NET.
Как писать изолированные интеграционные тесты с Testcontainers
Хабр
Как писать изолированные интеграционные тесты с Testcontainers
Есть две основные категории тестов : модульные (или юнит-тесты) и интеграционные. Модульные тесты — маленькие, быстрые и изолированные. Они проверяют одну единицу кода, обычно функцию или метод,...
👍3
#softwareTesting
Микросервисы сегодня — это основа большинства современных приложений. Они дают гибкость, но взамен требуют другой подход к разработке и особенно в тестировании. В отличие от монолитов, каждый микросервис работает сам по себе, и убедиться, что вся система при этом не разваливается, задача не из простых.
В новой статье автор расскажет, как тестировать микросервисы эффективно: от базовых принципов до инструментов вроде Keploy.
Начало работы с тестированием микросервисов
Микросервисы сегодня — это основа большинства современных приложений. Они дают гибкость, но взамен требуют другой подход к разработке и особенно в тестировании. В отличие от монолитов, каждый микросервис работает сам по себе, и убедиться, что вся система при этом не разваливается, задача не из простых.
В новой статье автор расскажет, как тестировать микросервисы эффективно: от базовых принципов до инструментов вроде Keploy.
Начало работы с тестированием микросервисов
👍3
#softwareTesting
Docker упаковывает приложение и его зависимости в контейнер, который запускается одинаково на любой машине.
В нашем сегодняшнем материале автор поделиться подробным руководством по Docker для QA: от базовых понятий и установки до написания Dockerfile, работы с Docker Compose, организации тестовых окружений, отладки и типичных задач с собеседований.
Docker для QA
Docker упаковывает приложение и его зависимости в контейнер, который запускается одинаково на любой машине.
В нашем сегодняшнем материале автор поделиться подробным руководством по Docker для QA: от базовых понятий и установки до написания Dockerfile, работы с Docker Compose, организации тестовых окружений, отладки и типичных задач с собеседований.
Docker для QA
Хабр
Docker для QA
Привет, Хабр! Это продолжение серии про QA-собеседования. Уже разобрали тест-дизайн , API и Security , System Design и SQL . Теперь — Docker. Если при слове «контейнер» в...
👍4
#proQuality_books #ai #softwareEngineering
📖 The Agentic AI Bible: The Complete and Up-to-Date Guide to Design, Develop, and Scale Goal-Driven, LLM-Powered Agents that Think, Execute and Evolve (2026)
Автор: Thomas R. Caldwell
Количество страниц: 314
Язык издания: Английский
Книга содержит руководство по проектированию, разработке и масштабированию агентов на базе LLM — от базовых паттернов модульной архитектуры, механизмов памяти и планирования до внедрения в продакшен, мониторинга и обеспечения безопасности.
Плюсы:
➕ Понятное и практичное руководство по созданию AI-агентов, объясняющее сложные концепции (память, интеграция инструментов, планирование) простым языком.
➕ Разбор фундаментальных паттернов, таких как perception-action loop и модульный дизайн с использованием фреймворков вроде LangChain.
➕ Прагматичный подход к безопасности: предлагаются конкретные архитектурные паттерны и концепция human-in-the-loop для предотвращения сбоев в автономных процессах.
➕ Фокус на практике — книга учит создавать надежные автономные системы для реального бизнеса.
Минусы:
➖ Раздел, посвященный управлению и контролю, излишне перегружен теорией.
➖ В некоторых главах фокус смещен в сторону MLOps, что может показаться менее увлекательным, чем моделирование и стратегическое планирование.
Для кого книга:
✔️ Для QA-инженеров, разработчиков, архитекторов и техлидов, работающих над enterprise-системами.
✔️ Для AI-разработчиков и продакт-менеджеров, переходящих от автоматизации к автономным системам.
Об авторе:
Thomas R. Caldwell — эксперт в области системного проектирования и разработки ИИ, специалист по созданию масштабируемых архитектурных решений для автономных агентских систем.
📖 The Agentic AI Bible: The Complete and Up-to-Date Guide to Design, Develop, and Scale Goal-Driven, LLM-Powered Agents that Think, Execute and Evolve (2026)
Автор: Thomas R. Caldwell
Количество страниц: 314
Язык издания: Английский
Книга содержит руководство по проектированию, разработке и масштабированию агентов на базе LLM — от базовых паттернов модульной архитектуры, механизмов памяти и планирования до внедрения в продакшен, мониторинга и обеспечения безопасности.
Плюсы:
➕ Понятное и практичное руководство по созданию AI-агентов, объясняющее сложные концепции (память, интеграция инструментов, планирование) простым языком.
➕ Разбор фундаментальных паттернов, таких как perception-action loop и модульный дизайн с использованием фреймворков вроде LangChain.
➕ Прагматичный подход к безопасности: предлагаются конкретные архитектурные паттерны и концепция human-in-the-loop для предотвращения сбоев в автономных процессах.
➕ Фокус на практике — книга учит создавать надежные автономные системы для реального бизнеса.
Минусы:
➖ Раздел, посвященный управлению и контролю, излишне перегружен теорией.
➖ В некоторых главах фокус смещен в сторону MLOps, что может показаться менее увлекательным, чем моделирование и стратегическое планирование.
Для кого книга:
✔️ Для QA-инженеров, разработчиков, архитекторов и техлидов, работающих над enterprise-системами.
✔️ Для AI-разработчиков и продакт-менеджеров, переходящих от автоматизации к автономным системам.
Об авторе:
Thomas R. Caldwell — эксперт в области системного проектирования и разработки ИИ, специалист по созданию масштабируемых архитектурных решений для автономных агентских систем.
👍5
#proQuality_Conference2026 #proQuality_Speakers
📢 Приём заявок на ProQuality Conference 2026 продолжается!
💡В 2025 году нашу конференцию посетили более 2000 участников онлайн.
В этом году мы возвращаемся с фокусом на 3 ключевых направлениях:
✔️ ИИ в функциональном тестировании
✔️ Тестирование приложений с ИИ
✔️ Автоматизация тестирования с помощью ИИ
👉 Отправьте свои темы или идеи прямо сейчас по ссылке.
📢 Приём заявок на ProQuality Conference 2026 продолжается!
💡В 2025 году нашу конференцию посетили более 2000 участников онлайн.
В этом году мы возвращаемся с фокусом на 3 ключевых направлениях:
✔️ ИИ в функциональном тестировании
✔️ Тестирование приложений с ИИ
✔️ Автоматизация тестирования с помощью ИИ
👉 Отправьте свои темы или идеи прямо сейчас по ссылке.
🔥3❤1
#ProQuality_tools
🛠 Встречайте API Spector — новый мощный open-source клиент для тестирования API без телеметрии и регистраций! 🚀
Сегодня поговорим про совсем свежий, но крайне многообещающий инструмент для API-тестирования — API Spector.
Инструменту всего несколько месяцев, но он уже представляет собой очень мощный REST-клиент для исследовательского тестирования (exploratory testing). Если вы устали от тяжеловесного Postman с его обязательными аккаунтами и облаками, присмотритесь к этой новинке!
🔥 Главные фишки API Spector:
🔹 Полностью Free & Open Source. Никаких платных подписок.
🔹 Максимальная приватность. Не требует регистраций и не имеет скрытой телеметрии — вся ваша работа остается только у вас.
🔹 Git-friendly. Все коллекции и запросы сохраняются в виде простого текста. Их максимально удобно хранить и версионировать в GitHub.
🔹 Киллер-фича с ассертами. В инструменте есть крутое древовидное отображение ответа (tree view). Вы просто кликаете на любое значение в ответе, и API Spector автоматически генерирует для него проверку (assertion). Это реализовано проще и быстрее, чем в большинстве других инструментов!
🔹 Продвинутый скриптинг. Поддержка переменных в pre-request скриптах, добавление ассертов в after-scripts, запуск целых коллекций и даже генерация кода.
🔹 Mock API и Контракты. Инструмент умеет не только делать проверки по ассертам, но и валидировать запросы на соответствие контракту, а также работать в режиме заглушки (Mock API).
🔗 Подробный обзор от EvilTester
🔗 API Spector
💬 Похоже, у Bruno, Hoppscotch и Insomnia появился серьезный конкурент. А чем вы сейчас пользуетесь для тестирования API на проектах? Хватает ли вам старого доброго Postman или уже перешли на легковесные аналоги? Пишите в комментарии, готовы ли дать шанс API Spector!
🛠 Встречайте API Spector — новый мощный open-source клиент для тестирования API без телеметрии и регистраций! 🚀
Сегодня поговорим про совсем свежий, но крайне многообещающий инструмент для API-тестирования — API Spector.
Инструменту всего несколько месяцев, но он уже представляет собой очень мощный REST-клиент для исследовательского тестирования (exploratory testing). Если вы устали от тяжеловесного Postman с его обязательными аккаунтами и облаками, присмотритесь к этой новинке!
🔥 Главные фишки API Spector:
🔹 Полностью Free & Open Source. Никаких платных подписок.
🔹 Максимальная приватность. Не требует регистраций и не имеет скрытой телеметрии — вся ваша работа остается только у вас.
🔹 Git-friendly. Все коллекции и запросы сохраняются в виде простого текста. Их максимально удобно хранить и версионировать в GitHub.
🔹 Киллер-фича с ассертами. В инструменте есть крутое древовидное отображение ответа (tree view). Вы просто кликаете на любое значение в ответе, и API Spector автоматически генерирует для него проверку (assertion). Это реализовано проще и быстрее, чем в большинстве других инструментов!
🔹 Продвинутый скриптинг. Поддержка переменных в pre-request скриптах, добавление ассертов в after-scripts, запуск целых коллекций и даже генерация кода.
🔹 Mock API и Контракты. Инструмент умеет не только делать проверки по ассертам, но и валидировать запросы на соответствие контракту, а также работать в режиме заглушки (Mock API).
🔗 Подробный обзор от EvilTester
🔗 API Spector
💬 Похоже, у Bruno, Hoppscotch и Insomnia появился серьезный конкурент. А чем вы сейчас пользуетесь для тестирования API на проектах? Хватает ли вам старого доброго Postman или уже перешли на легковесные аналоги? Пишите в комментарии, готовы ли дать шанс API Spector!
Eviltester
API Spector Open Source API Testing Tool
API Spector is a new free HTTP and WebSocket Testing Tool. It is open source and has more features than most free tools
👍2❤1
#automationTesting #databases
Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом.
В данной статье описываются опыт и методология внедрения юнит-тестирования функций на уровне базы данных PostgreSQL, включая выбор инструментов (PLPG Unit), процесс разработки тестов, промежуточные результаты (обнаружение 16 ошибок) и планы по дальнейшему развитию.
Юнит-тестирование на уровне базы данных PostgreSQL
Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом.
В данной статье описываются опыт и методология внедрения юнит-тестирования функций на уровне базы данных PostgreSQL, включая выбор инструментов (PLPG Unit), процесс разработки тестов, промежуточные результаты (обнаружение 16 ошибок) и планы по дальнейшему развитию.
Юнит-тестирование на уровне базы данных PostgreSQL
👍3
#softwareTesting
Несколько лет назад можно было услышать такой вопрос: «Что делать, если до релиза остался день, а полная регрессия занимает три?»
В нашем сегодняшнем материале автор поделиться практическими подходами к приоритизации регрессионных проверок при сжатых сроках релиза: от выбора сценариев по скорости обнаружения дефектов, зоне изменений и истории ошибок до фиксации остаточных рисков и честной коммуникации с командой.
Как приоритизировать регрессионные проверки, когда сжаты сроки релиза
Несколько лет назад можно было услышать такой вопрос: «Что делать, если до релиза остался день, а полная регрессия занимает три?»
В нашем сегодняшнем материале автор поделиться практическими подходами к приоритизации регрессионных проверок при сжатых сроках релиза: от выбора сценариев по скорости обнаружения дефектов, зоне изменений и истории ошибок до фиксации остаточных рисков и честной коммуникации с командой.
Как приоритизировать регрессионные проверки, когда сжаты сроки релиза
👍2
#ProQuality_news
🤖 Skill-Driven Development (SDD): новый подход к архитектуре автотестов в эпоху ИИ-агентов
Слышали про TDD, BDD и DDD? Знакомьтесь с новым подходом — Skill-Driven Development (SDD). В статье автор разобрал, как эта концепция может избавить инженеров от боли поддержки хрупких E2E-тестов.
😩 В чем проблема?
Поддержка E2E-тестов — это рутина. Одно переименованное поле в UI, и десятки тестов в CI краснеют. Идея просто «скормить» логи с ошибками базовой LLM-модели работает плохо: раздутые промпты ведут к галлюцинациям нейросети, непредсказуемым изменениям в коде и лишним расходам.
💡 Что предлагает SDD?
SDD делает базовой единицей проектирования системы «навык» (skill).
Навык — это строго описанная способность (с жестким контрактом, до- и постусловиями, прописанными сценариями сбоя и стоимостью выполнения).
Вместо хаоса ИИ-агент (оркестратор) использует реестр таких навыков, чтобы автономно собирать цепочки для «самоисцеления» (Self-healing) QA-пайплайна.
Как это выглядит на практике (через MCP):
1️⃣ Навык 1: Запустить Playwright-тест (детерминированный, 0 токенов).
2️⃣ Навык 2: Проанализировать причину падения по логам и коду (когнитивный навык ИИ).
3️⃣ Навык 3: Сгенерировать фикс, изменив строго не более 20 строк E2E-теста.
Всё это работает со строгими ограничениями (Guardrails), а финальное решение (Approve/Reject сгенерированного PR) всегда остается за инженером через удобный UI. SDD не заменяет TDD или BDD, он дополняет их для систем, где агенты должны автономно мыслить.
🔗 Skill-Driven Development (SDD): Designing Software for the Age of Agents
💬 Как вам концепция разделения ИИ-автоматизации на строгие «навыки»? Верите ли вы в успешный self-healing E2E-тестов в ближайшем будущем, или автономные ИИ-агенты пока разобьются о суровый и непредсказуемый продакшен? Делитесь мнением в комментариях! 👇
🤖 Skill-Driven Development (SDD): новый подход к архитектуре автотестов в эпоху ИИ-агентов
Слышали про TDD, BDD и DDD? Знакомьтесь с новым подходом — Skill-Driven Development (SDD). В статье автор разобрал, как эта концепция может избавить инженеров от боли поддержки хрупких E2E-тестов.
😩 В чем проблема?
Поддержка E2E-тестов — это рутина. Одно переименованное поле в UI, и десятки тестов в CI краснеют. Идея просто «скормить» логи с ошибками базовой LLM-модели работает плохо: раздутые промпты ведут к галлюцинациям нейросети, непредсказуемым изменениям в коде и лишним расходам.
💡 Что предлагает SDD?
SDD делает базовой единицей проектирования системы «навык» (skill).
Навык — это строго описанная способность (с жестким контрактом, до- и постусловиями, прописанными сценариями сбоя и стоимостью выполнения).
Вместо хаоса ИИ-агент (оркестратор) использует реестр таких навыков, чтобы автономно собирать цепочки для «самоисцеления» (Self-healing) QA-пайплайна.
Как это выглядит на практике (через MCP):
1️⃣ Навык 1: Запустить Playwright-тест (детерминированный, 0 токенов).
2️⃣ Навык 2: Проанализировать причину падения по логам и коду (когнитивный навык ИИ).
3️⃣ Навык 3: Сгенерировать фикс, изменив строго не более 20 строк E2E-теста.
Всё это работает со строгими ограничениями (Guardrails), а финальное решение (Approve/Reject сгенерированного PR) всегда остается за инженером через удобный UI. SDD не заменяет TDD или BDD, он дополняет их для систем, где агенты должны автономно мыслить.
🔗 Skill-Driven Development (SDD): Designing Software for the Age of Agents
💬 Как вам концепция разделения ИИ-автоматизации на строгие «навыки»? Верите ли вы в успешный self-healing E2E-тестов в ближайшем будущем, или автономные ИИ-агенты пока разобьются о суровый и непредсказуемый продакшен? Делитесь мнением в комментариях! 👇
Medium
Skill-Driven Development (SDD): Designing Software for the Age of Agents
Abstract: Maintaining E2E test suites is painful. One renamed field and dozens of tests turn red. LLMs promise automatic fixes, but a…
❤4
#proQuality_books
📖 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Авторы: Jez Humble, David Farley
Количество страниц: 512
Язык издания: Английский
Книга заложила основы Continuous Delivery — практики быстрой, инкрементальной и безопасной доставки ПО. Авторы описывают концепцию deployment pipeline и охватывают автоматизацию сборки, тестирования и развертывания, управление конфигурациями и рисками. Несмотря на год издания, остается классикой жанра.
Плюсы:
➕ Фундаментальный труд по CD с множеством готовых идей для улучшения процессов доставки ПО.
➕ Детальный разбор сложных тем: управление тестовыми данными, версионирование БД и автоматизация инфраструктуры.
➕ Акцент на культуре DevOps: объединение разработчиков, тестировщиков, администраторов и DBAs в единую команду.
➕ Принципы применимы как в стартапах, так и в enterprise-проектах со сложным legacy-кодом.
Минусы:
➖ Местами затянута — некоторые идеи повторяются из главы в главу.
➖ Неоднородный стиль и устаревшие примеры инструментов могут затруднить восприятие, особенно для новичков.
Для кого книга:
✔️ Для разработчиков, тестировщиков, администраторов и DevOps-инженеров, выстраивающих процесс CI/CD.
✔️ Для техлидов и менеджеров, стремящихся сократить time-to-release и минимизировать риски.
Об авторах:
Jez Humble — эксперт по CD и DevOps, соавтор ключевых книг по доставке ПО, исследователь и преподаватель в UC Berkeley. David Farley — пионер Agile-разработки, независимый консультант и автор YouTube-канала «Continuous Delivery».
📖 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Авторы: Jez Humble, David Farley
Количество страниц: 512
Язык издания: Английский
Книга заложила основы Continuous Delivery — практики быстрой, инкрементальной и безопасной доставки ПО. Авторы описывают концепцию deployment pipeline и охватывают автоматизацию сборки, тестирования и развертывания, управление конфигурациями и рисками. Несмотря на год издания, остается классикой жанра.
Плюсы:
➕ Фундаментальный труд по CD с множеством готовых идей для улучшения процессов доставки ПО.
➕ Детальный разбор сложных тем: управление тестовыми данными, версионирование БД и автоматизация инфраструктуры.
➕ Акцент на культуре DevOps: объединение разработчиков, тестировщиков, администраторов и DBAs в единую команду.
➕ Принципы применимы как в стартапах, так и в enterprise-проектах со сложным legacy-кодом.
Минусы:
➖ Местами затянута — некоторые идеи повторяются из главы в главу.
➖ Неоднородный стиль и устаревшие примеры инструментов могут затруднить восприятие, особенно для новичков.
Для кого книга:
✔️ Для разработчиков, тестировщиков, администраторов и DevOps-инженеров, выстраивающих процесс CI/CD.
✔️ Для техлидов и менеджеров, стремящихся сократить time-to-release и минимизировать риски.
Об авторах:
Jez Humble — эксперт по CD и DevOps, соавтор ключевых книг по доставке ПО, исследователь и преподаватель в UC Berkeley. David Farley — пионер Agile-разработки, независимый консультант и автор YouTube-канала «Continuous Delivery».
❤3
#ProQuality_tasks
Всем привет! С вами снова рубрика задачки ProQuality ✨
Задача про проект 🏠
Шести людям требуется 36 часов, чтобы покрасить дом.
Сколько времени потребовалось бы на покраску дома, если бы в середине проекта к работе присоединились ещё три человека?
Идеями и решениями делитесь в комментариях под постом 👇
В ближайшую пятницу мы опубликуем ответ на задачу 🤓
Всем привет! С вами снова рубрика задачки ProQuality ✨
Задача про проект 🏠
Шести людям требуется 36 часов, чтобы покрасить дом.
Сколько времени потребовалось бы на покраску дома, если бы в середине проекта к работе присоединились ещё три человека?
Идеями и решениями делитесь в комментариях под постом 👇
В ближайшую пятницу мы опубликуем ответ на задачу 🤓
❤2
#proQuality_Conference2026 #proQuality_Speakers
📢 Дедлайн приёма заявок на ProQuality Conference 2026 продлён до 1 августа!
Мы получили уже много заявок, но решили дать экспертам больше времени на подготовку предложений.
💡 В 2025 году онлайн конференцию посетили более 2000 участников — в этом году ожидаем ещё больше!
Ищем спикеров на стыке ИИ и тестирования ПО. Особенно приветствуются доклады включающие демо с примерами из практики.
Фокус — 3 направления:
✔️ ИИ как инструмент функционального тестирования
✔️ Как тестировать AI-приложения
✔️ Автоматизация тестирования на базе ИИ
Будем рады видеть тебя среди спикеров! 🎤
👉 Отправь свои темы или идеи прямо сейчас по ссылке
📢 Дедлайн приёма заявок на ProQuality Conference 2026 продлён до 1 августа!
Мы получили уже много заявок, но решили дать экспертам больше времени на подготовку предложений.
💡 В 2025 году онлайн конференцию посетили более 2000 участников — в этом году ожидаем ещё больше!
Ищем спикеров на стыке ИИ и тестирования ПО. Особенно приветствуются доклады включающие демо с примерами из практики.
Фокус — 3 направления:
✔️ ИИ как инструмент функционального тестирования
✔️ Как тестировать AI-приложения
✔️ Автоматизация тестирования на базе ИИ
Будем рады видеть тебя среди спикеров! 🎤
👉 Отправь свои темы или идеи прямо сейчас по ссылке
🔥4
#automationTesting
Фикстуры — одна из центральных частей Playwright. Они позволяют вынести подготовку и сброс состояния за пределы теста, чтобы сам тест был сосредоточен на проверяемом поведении. Если коротко, фикстуры это before/after хуки на стероидах.
В данной статье рассмотрим основные варианты использования фикстур и автор расскажет, как каждый из них выглядит на таймлайне.
Playwright в картинках: как работают фикстуры
Фикстуры — одна из центральных частей Playwright. Они позволяют вынести подготовку и сброс состояния за пределы теста, чтобы сам тест был сосредоточен на проверяемом поведении. Если коротко, фикстуры это before/after хуки на стероидах.
В данной статье рассмотрим основные варианты использования фикстур и автор расскажет, как каждый из них выглядит на таймлайне.
Playwright в картинках: как работают фикстуры
👍3
Желаем всем отличных выходных!🦎
Сегодня вы можете ознакомиться с решением задачи про проект
Все самые интересные задачи и вопросы, в том числе те, с которыми можно столкнуться на собеседовании, мы публикуем в рубрике #ProQuality_tasks
Сегодня вы можете ознакомиться с решением задачи про проект
Все самые интересные задачи и вопросы, в том числе те, с которыми можно столкнуться на собеседовании, мы публикуем в рубрике #ProQuality_tasks
Telegraph
Задача про проект
Шести людям требуется 36 часов, чтобы покрасить дом. Сколько времени потребовалось бы на покраску дома, если бы в середине проекта к работе присоединились ещё три человека? Ответ: 30 часов. Шесть человек покрасили половину дома за 36 / 2 = 18 часов. После…
❤2