#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
#ProQuality_news
🟢 Кодинг больше не узкое место: Как Spotify масштабирует разработку с помощью ИИ-агента Honk
В инженерном блоге Spotify вышла потрясающая статья о том, как они перестроили процессы под автономных ИИ-агентов (на базе Claude). Главный тезис: писать код стало настолько легко и быстро, что главным «узким местом» теперь является ревью и принятие решений.
Что происходит внутри Spotify прямо сейчас:
🚀 Взрывной рост: 99% инженеров компании используют ИИ-тулы еженедельно. Количество создаваемых пулл-реквестов (PR) выросло на 76%! Подавляющее большинство из них написаны разработчиками в паре с ИИ.
🦆 Знакомьтесь, Honk (Фоновый ИИ-агент):
Spotify не стали полагаться только на Copilot в IDE. Они написали собственного агента Honk, который крутится в кластерах Kubernetes.
• Масштабный рефакторинг: Агент интегрирован в систему Fleet Management. Недавняя сложная миграция Java на бэкенде, которая раньше заняла бы у сотен команд долгие месяцы, была выполнена одним инженером всего за 3 дня.
• Автономность: Разработчик может тегнуть Honk прямо в треде Slack, дать контекст проблемы, и агент «улетит» писать код.
• Встроенная проверка: Honk имеет доступ к CI-инфраструктуре. Он сам запускает билды и гоняет автотесты, чтобы валидировать свои изменения перед тем, как создать PR.
Что это значит для QA и автоматизаторов (SDET)?
1️⃣ Цунами пулл-реквестов: Рост числа PR на 76% означает колоссальную нагрузку на тестирование. Пока ИИ пишет код, валидация бизнес-логики и ручное/исследовательское тестирование становятся главными задачами людей.
2️⃣ CI/CD — это «глаза» для ИИ: Агенты вроде Honk полностью полагаются на результаты автотестов, чтобы понять, рабочий ли код они написали. Если ваши тесты flaky или падают ложно — ИИ сойдет с ума, пытаясь починить несуществующие баги. Стабильные автотесты теперь — критический фундамент для ИИ-разработки.
3️⃣ Guardrails (Ограждения): Spotify использует портал Backstage и протокол MCP, чтобы давать агентам строгие стандарты (Golden state).
🔗 Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify
💬 Представьте, что завтра ваши разработчики начнут выдавать на 70-80% больше кода и фичей благодаря таким агентам. Справится ли с этим ваш текущий QA-процесс? Достаточно ли стабильны ваши автотесты, чтобы автономный ИИ мог на них опираться при рефакторинге? Делитесь мыслями в комментариях! 👇
🟢 Кодинг больше не узкое место: Как Spotify масштабирует разработку с помощью ИИ-агента Honk
В инженерном блоге Spotify вышла потрясающая статья о том, как они перестроили процессы под автономных ИИ-агентов (на базе Claude). Главный тезис: писать код стало настолько легко и быстро, что главным «узким местом» теперь является ревью и принятие решений.
Что происходит внутри Spotify прямо сейчас:
🚀 Взрывной рост: 99% инженеров компании используют ИИ-тулы еженедельно. Количество создаваемых пулл-реквестов (PR) выросло на 76%! Подавляющее большинство из них написаны разработчиками в паре с ИИ.
🦆 Знакомьтесь, Honk (Фоновый ИИ-агент):
Spotify не стали полагаться только на Copilot в IDE. Они написали собственного агента Honk, который крутится в кластерах Kubernetes.
• Масштабный рефакторинг: Агент интегрирован в систему Fleet Management. Недавняя сложная миграция Java на бэкенде, которая раньше заняла бы у сотен команд долгие месяцы, была выполнена одним инженером всего за 3 дня.
• Автономность: Разработчик может тегнуть Honk прямо в треде Slack, дать контекст проблемы, и агент «улетит» писать код.
• Встроенная проверка: Honk имеет доступ к CI-инфраструктуре. Он сам запускает билды и гоняет автотесты, чтобы валидировать свои изменения перед тем, как создать PR.
Что это значит для QA и автоматизаторов (SDET)?
1️⃣ Цунами пулл-реквестов: Рост числа PR на 76% означает колоссальную нагрузку на тестирование. Пока ИИ пишет код, валидация бизнес-логики и ручное/исследовательское тестирование становятся главными задачами людей.
2️⃣ CI/CD — это «глаза» для ИИ: Агенты вроде Honk полностью полагаются на результаты автотестов, чтобы понять, рабочий ли код они написали. Если ваши тесты flaky или падают ложно — ИИ сойдет с ума, пытаясь починить несуществующие баги. Стабильные автотесты теперь — критический фундамент для ИИ-разработки.
3️⃣ Guardrails (Ограждения): Spotify использует портал Backstage и протокол MCP, чтобы давать агентам строгие стандарты (Golden state).
🔗 Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify
💬 Представьте, что завтра ваши разработчики начнут выдавать на 70-80% больше кода и фичей благодаря таким агентам. Справится ли с этим ваш текущий QA-процесс? Достаточно ли стабильны ваши автотесты, чтобы автономный ИИ мог на них опираться при рефакторинге? Делитесь мыслями в комментариях! 👇
Spotify Engineering
Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify | Spotify Engineering
👍3
#proQuality_books
📖 Agile Testing Condensed: A Brief Introduction (2019)
Авторы: Janet Gregory, Lisa Crispin
Количество страниц: 113
Язык издания: Английский
Лаконичное руководство по тестированию и культуре качества в Agile-среде: как встроить QA в итеративный цикл, кто отвечает за качество и как вовлечь всю команду в непрерывное тестирование.
Плюсы:
➕ Концентрат практической ценности: максимум пользы на 113 страницах.
➕ Простой живой язык — сложные концепции объясняются без лишней «воды».
➕ Мотивирует на эксперименты и помогает быстро внедрить новые практики в команде.
Минусы:
➖ Некоторые иллюстрации слишком мелкие для комфортного чтения.
➖ Скорее сжатое изложение предыдущих работ авторов с обилием отсылок к ним, чем самостоятельный труд.
Для кого книга:
✔️ Для QA-специалистов, желающих быстро погрузиться в специфику тестирования в Agile.
✔️ Для разработчиков и участников команды, внедряющих культуру Agile-тестирования.
✔️ Для менеджеров и продакт-оунеров, переходящих на гибкие методологии.
Об авторах:
Janet Gregory и Lisa Crispin — пионеры Agile-тестирования, сооснователи Agile Testing Fellowship и авторы культовых книг «Agile Testing» и «More Agile Testing».
📖 Agile Testing Condensed: A Brief Introduction (2019)
Авторы: Janet Gregory, Lisa Crispin
Количество страниц: 113
Язык издания: Английский
Лаконичное руководство по тестированию и культуре качества в Agile-среде: как встроить QA в итеративный цикл, кто отвечает за качество и как вовлечь всю команду в непрерывное тестирование.
Плюсы:
➕ Концентрат практической ценности: максимум пользы на 113 страницах.
➕ Простой живой язык — сложные концепции объясняются без лишней «воды».
➕ Мотивирует на эксперименты и помогает быстро внедрить новые практики в команде.
Минусы:
➖ Некоторые иллюстрации слишком мелкие для комфортного чтения.
➖ Скорее сжатое изложение предыдущих работ авторов с обилием отсылок к ним, чем самостоятельный труд.
Для кого книга:
✔️ Для QA-специалистов, желающих быстро погрузиться в специфику тестирования в Agile.
✔️ Для разработчиков и участников команды, внедряющих культуру Agile-тестирования.
✔️ Для менеджеров и продакт-оунеров, переходящих на гибкие методологии.
Об авторах:
Janet Gregory и Lisa Crispin — пионеры Agile-тестирования, сооснователи Agile Testing Fellowship и авторы культовых книг «Agile Testing» и «More Agile Testing».
👍3❤1
#ProQuality_interview
Всем привет! С вами снова рубрика Scenario-based вопрос на собеседовании ✨
❓Вопрос: Вам нужно протестировать API без документации. Что вы будете делать?
🚦Пример ответа:
✔️Используйте такие инструменты, как Swagger или Postman, для проверки заголовков и тела ответа API.
✔️Ищите комментарии разработчиков и определения схемы.
✔️Проведите reverse-engineer полей, таких как типы данных и правила валидации, чтобы проанализировать работу API.
✔️Запросите у разработчиков минимальные сведения о контракте.
✔️Тестируйте, используя типичные, граничные и отрицательные входные данные.
Всем привет! С вами снова рубрика Scenario-based вопрос на собеседовании ✨
❓Вопрос: Вам нужно протестировать API без документации. Что вы будете делать?
🚦Пример ответа:
✔️Используйте такие инструменты, как Swagger или Postman, для проверки заголовков и тела ответа API.
✔️Ищите комментарии разработчиков и определения схемы.
✔️Проведите reverse-engineer полей, таких как типы данных и правила валидации, чтобы проанализировать работу API.
✔️Запросите у разработчиков минимальные сведения о контракте.
✔️Тестируйте, используя типичные, граничные и отрицательные входные данные.
❤2