#automationTesting

В распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается.

В нашем сегодняшнем материале автор поделиться архитектурным разбором реализации Kafka Consumer для тестовой автоматизации, включая решения проблем SSL-сертификатов, конфликтов consumer group и асинхронных таймингов.

Kafka Consumer в тестовой автоматизации: архитектурный разбор

Желаем всем отличных выходных!🦎

Сегодня вы можете ознакомиться с решением задачи про свечи

Все самые интересные задачи и вопросы, в том числе те, с которыми можно столкнуться на собеседовании, мы публикуем в рубрике #ProQuality_tasks

#ProQuality_news

🔮 Будущее тестирования: К чему готовиться QA-инженерам в 2026 году?

Daniel Knott выпустил видео с разбором того, куда движется индустрия тестирования под давлением ИИ-технологий. Спойлер: паниковать рано, наша профессия никуда не исчезнет, но адаптироваться придется всем.

Вот 4 главных тренда, которые изменят нашу работу:

🤖 1. Три новых вектора приложения сил для QA
ИИ — это надолго, и он будет доминировать. Три главные зоны фокуса для тестировщиков прямо сейчас:
• Автономные ИИ-агенты: нужно учиться работать с ними и внедрять в процессы.
• Тестирование сгенерированного кода: ИИ пишет код быстро, но часто с багами и уязвимостями — кто-то должен это проверять.
• Тестирование ИИ-приложений: валидация продуктов, в которые уже встроены LLM и умные фичи (где результат часто недетерминирован).

🔄 2. Слияние Shift-Left и Shift-Right
Классические споры о том, куда сдвигать тестирование, в прошлом. Будущее за непрерывным качеством на всех этапах. Но особую важность приобретает Shift-Right: обсервабилити (observability), мониторинг в реальном времени и тестирование прямо в Production.

🛡 3. Хаос-инжиниринг и Безопасность (DevSecOps)
Поскольку объем сгенерированного ИИ кода растет в геометрической прогрессии, растут и риски утечек. Безопасность больше не забота отдельного отдела. А в мире сложных облачных микросервисов всё большую популярность набирает Chaos Engineering — намеренное внесение сбоев для проверки устойчивости системы.

🧠 4. Эволюция роли: от QA к Стратегу
Мы привыкли к изменениям (вспомните переход от десктопа к вебу, мобилкам и облакам). Технические навыки всё еще актуальны, но смещаются в сторону новых инструментов.
Но главной суперсилой (The Skill Asset) тестировщика в эпоху ИИ становится глубокое понимание бизнеса и доменной области. Инструменты автоматизируются, а вот экспертизу в продукте ИИ заменить пока не может.

🔗 The Future of Software Testing
💬 А как вы видите будущее QA? Согласны, что доменная и бизнес-экспертиза теперь важнее умения просто писать код автотестов? Делитесь мыслями и прогнозами в комментариях! 👇

​​#proQuality_books #softwareTesting #ai
 
📖 Navigating Quality Engineering in the AI Era (2024)
Автор: Evgeny Tkachenko
Количество страниц: 139
Язык издания: Английский
 
Книга о трансформации роли QA-инженера в эпоху ИИ и DevOps. Охватывает автоматизацию на базе AI, прогнозную аналитику, CI/CD и этические аспекты использования ИИ.
 
Плюсы:
➕ Простой язык и быстрое чтение — книга легко усваивается.
➕ Реальные примеры и личные истории автора, применимые в текущих проектах.
➕ Крепкая связка теории с практикой тестирования AI-систем.
➕ Ценные инсайты по Shift-Left и DevOps.
 
Минусы:
➖ Нет названий конкретных AI-инструментов для практического применения.
➖ Теме ИИ посвящены лишь две главы — остальное о DevOps и Agile.
 
Для кого книга:
✔️ Для QA/QE-инженеров любого уровня, адаптирующихся к трендам AI и DevOps.
✔️ Для QA-лидов и тест-менеджеров, выстраивающих процессы управления качеством.
✔️ Для всех IT-специалистов, развивающих quality mindset.
 
Об авторе:
Evgeny Tkachenko — Head of Quality Engineering, помогает организациям внедрять современные подходы к тестированию и адаптироваться к технологическим изменениям.

#ProQuality_tools

🔥 Webwright от Microsoft: ИИ-агент, который сам пишет и запускает тесты на Playwright

Коллеги, наткнулись на отличный практический разбор про Webwright. Автор поделился честным опытом использования нового инструмента от Microsoft, и результаты действительно интригуют.

Что за зверь этот Webwright?
Это компактный Python-фреймворк (всего около 1500 строк кода). Он меняет привычный подход к браузерным ИИ-агентам: вместо того чтобы заставлять LLM парсить сырой DOM или управлять браузером через "слепые" клики, Webwright дает нейросети доступ к терминалу, чтобы она сама писала и выполняла код на Playwright.

Как это показало себя на практике?
Автор протестировал инструмент на реальном интернет-магазине. Задачей было пройти 18-шаговый сценарий наполнения корзины продуктами и оформления заказа.
Итог: полная автоматизация сложного флоу всего по одному предложению на входе. 🤯

Ключевые инсайты из статьи:
1️⃣ Экономия токенов: Запуск Webwright в автономном режиме (standalone) тратит в 8 раз меньше токенов, чем при его использовании в качестве навыка (skill) внутри Claude Code или Codex.
2️⃣ Паттерн самопроверки (Self-verification): Инструмент использует крутую архитектуру — он создает план с чекпоинтами, пишет и выполняет код, а затем выступает в роли судьи, оценивая успешность шага по скриншотам.
3️⃣ Craft mode: Возможность создавать переиспользуемые CLI делает тулзу полезной не только для разовых тестов, но и для регулярных задач.

Подход, при котором ИИ мыслит на уровне написания автотестов, а не просто "кликает по координатам", выглядит как большой шаг вперед для стабильности AI-автоматизации.

🔗 My Honest Take on Webwright After Running It on a Real Web App and spending few human hours
💬 Как вам такой подход? Готовы ли доверить написание и выполнение e2e-тестов ИИ-агенту, который сам пишет код и проверяет себя по скриншотам? Или классическое ручное написание тестов всё еще единственный путь к стабильному CI? Делитесь мыслями в комментариях! 👇

#softwareTesting

Когда идёт речь про микросервисы, большинству читателей представляется сложная архитектура связей между различными блоками, внешними системами, другими микросервисами и базой данных. То есть первым делом мы, конечно же, думаем о backend микросервисах.

В данной статье описываются методология и практический опыт нагрузочного тестирования UI-микросервисов на реальном примере инцидента с троттлингом процессора, включая парсинг манифеста и загрузку статических ассетов в JMeter.

Новая эра: нагрузочное тестирование UI‑микросервисов

#ProQuality_news

🚀 Встречайте новый HTTP-метод — QUERY! Почему QA-инженерам стоит обратить на него внимание?

Если вы вдруг пропустили: в семействе HTTP-методов пополнение. Появился новый метод HTTP QUERY. Он решает давнюю головную боль проектирования API, с которой сталкивался, пожалуй, каждый тестировщик.

В чем была проблема?
Представьте, что вам нужно протестировать эндпоинт поиска со сложной фильтрацией (много параметров, массивы, вложенные объекты).
❌ Использовать GET? Длина URL ограничена, а передавать Request Body в GET-запросе — плохая практика (серверы и прокси часто его просто игнорируют или отбрасывают).
❌ Использовать POST? Это решает проблему размера, но ломает семантику REST (POST должен изменять состояние) и лишает нас кэширования, которое есть у GET.

Что меняет HTTP QUERY?
Он работает как GET (является безопасным, идемпотентным и поддерживает кэширование), но при этом официально поддерживает тело запроса (Payload / Request Body)! Теперь сложные фильтры, GraphQL-запросы и тяжелые поисковые параметры можно передавать по стандарту.

🔍 Что это значит для нас, тестировщиков (QA):
1️⃣ Новые тест-кейсы на кэширование: В отличие от поисковых POST-запросов, ответы на QUERY могут и должны кэшироваться. Это нужно будет проверять отдельно.
2️⃣ Проверка тулинга: Придется убедиться, что ваши любимые инструменты (Postman, Swagger, Charles, фреймворки вроде RestAssured или Playwright) корректно переваривают новый метод.
3️⃣ Секьюрность и логирование: Параметры из URL всегда попадали в логи веб-серверов. Тело запроса (Body) часто не логируется по умолчанию. Стоит проверять, как логируются новые QUERY-запросы и не скрывается ли там что-то важное для дебага.

🔗 HTTP QUERY: Why QA Engineers Should Care About the New HTTP Method
💬 Уже слышали про метод QUERY? Как думаете, как быстро этот метод станет стандартом в индустрии? Делитесь мыслями в комментариях! 👇

​​#proQuality_books #requirements
 
📖 Software Requirements (Developer Best Practices, 3rd Edition) (2013)
Авторы: Karl Wiegers, Joy Beatty
Количество страниц: 672
Язык издания: Английский
 
Полный цикл работы с требованиями к ПО: от сбора, анализа и документирования до валидации и управления изменениями.
 
Плюсы:
➕ Готовые шаблоны и советы, применимые в работе сразу же.
➕ Живой язык, реальные кейсы и истории из опыта авторов.
➕ Расширенные разделы по нефункциональным требованиям, работе с данными и бизнес-требованиям.
➕ Надежный справочник для управления проектом и снижения рисков.
 
Минусы:
➖ Объем и глубина некоторых базовых тем могут утомлять при последовательном чтении.
➖ Ряд положений покажется очевидным опытным специалистам.
➖ Местами ощущается авторская догматика без охвата всех точек зрения индустрии.
 
Для кого книга:
✔️ Для бизнес-аналитиков и инженеров по требованиям любого уровня.
✔️ Для тестировщиков, разработчиков и архитекторов, желающих лучше понимать процесс формирования требований.
✔️ Для менеджеров проектов, отвечающих за управление объемом работ и контроль рисков.
 
Об авторах:
Karl Wiegers — эксперт в разработке ПО, автор бестселлеров по лучшим практикам индустрии. Joy Beatty — лидер сообщества специалистов по требованиям, обучившая тысячи бизнес-аналитиков.

#ProQuality_interview

Всем привет! С вами снова рубрика Scenario-based вопрос на собеседовании ✨

❓Вопрос: В гибкой методологии разработки вы получаете всего один день на тестирование задачи. Как вы организуете тестирование?

🚦Пример ответа:

✔️Разбейте задачу на тестируемые части, чтобы каждую часть можно было эффективно и результативно протестировать.

✔️Проводите параллельное тестирование, пока разработчик завершает задачи.

✔️Сначала сосредоточьтесь на "happy path" с корректными входными данными, чтобы убедиться, что основная функция работает.

✔️Автоматизируйте проверки на корректность, чтобы ускорить тестирование.

✔️Используйте исследовательское тестирование для оптимизации покрытия кода.

#automationTesting

Миграция с Selenium на Playwright часто выглядит простой: переписали локаторы, заменили WebDriver на новый фреймворк и вперёд. Но на практике большинство проблем переезжает вместе с кодом.

В сегодняшнем материале автор разбирает 7 типичных ошибок Java-команд при переходе на Playwright: от использования Thread.sleep и устаревших XPath-локаторов до неправильной работы с BrowserContext, авторизацией и тестовой изоляцией. На реальных примерах показано, почему смена инструмента не решает проблемы, если сохраняются старые подходы к автоматизации.

Playwright vs Selenium: 7 ошибок Java-миграции

​​​​#proQuality_events #proQuality_Conference2026

Приглашаем вас на онлайн-конференцию ProQuality Conference '26 — 5 дней о современных подходах к тестированию, Quality Engineering и работе с AI.

💡 В этом году конференция будет посвящена трем основным направлениям:

🤖 AI-Augmented Testing
Как AI-агенты и LLM уже сегодня помогают QA-инженерам создавать тесты, находить селекторы, поддерживать BDD-сценарии и анализировать дефекты.

🛡 Testing and Governing AI Systems
Как тестировать AI-системы и управлять рисками? В программе — AI security, prompt engineering, регрессионное тестирование моделей и особенности контроля AI-агентов в production.

👥 Human Readiness and Quality Culture
Как выстраивать культуру качества в команде, усиливать голос тестировщиков, находить общий язык с другими участниками разработки и эффективнее говорить о рисках.

🎤 Спикеры поделятся реальными кейсами, покажут рабочие процессы и live-demo, а также расскажут о решениях, которые используют в production.

📆 Присоединяйтесь к нам 21–25 сентября 2026 11:00 UTC+3, язык EN!

Если вы работаете в QA, автоматизации, Quality Engineering или создаёте AI-powered продукты — присоединяйтесь к конференции, чтобы узнать о практиках, которые уже применяются в индустрии.

👉 Регистрируйтесь на ProQuality Conference '26

Другие наши мероприятия на wearecommunity.io.

​​#softwareTesting

Термин «нагрузочное тестирование» часто используют как общее название. Но за ним стоит несколько видов разных испытаний – и каждое предназначено для решения конкретных задач.

В нашем сегодняшнем материале автор поделиться ключевыми аспектами нагрузочного тестирования для менеджеров, маркетологов и основателей: объяснит виды тестов, важные метрики (процентили, доля ошибок), опасность нереалистичных сценариев и миф об автомасштабировании, а также расскажет, когда проводить тестирование и как ИИ ускоряет анализ, но не заменяет человеческую экспертизу.

Как нагрузочное тестирование защищает бизнес от убытков?

#ProQuality_interview

📚 Находка для QA: Practical Testing — масштабная база знаний в одном месте

Коллеги, если вы устали собирать полезные материалы по крупицам из разных блогов и чатов, этот ресурс точно для вас. Знакомьтесь с Practical Testing — великолепной открытой коллекцией структурированных гайдов по тестированию ПО.

Это настоящая настольная книга (в формате GitBook), где все разложено по полочкам. Независимо от того, хотите ли вы быстро освежить в памяти конкретную технику тест-дизайна перед сложной задачей (или собеседованием), или же планируете изучить совершенно новый для себя подход — это идеальное место для старта.

Чем хорош ресурс:
• Вся информация собрана в одном месте и логично структурирована.
• Отлично подходит как для новичков, так и для мидлов, которым нужен быстрый quick refresher по забытой теории.
• Никакой лишней воды — только практические советы и четкие руководства.

🔗 Обязательно сохраняем в закладки: Practical Testing
💬 А какими справочниками, вики-системами или шпаргалками пользуетесь вы на регулярной основе? Есть ли у вас свои проверенные ресурсы, куда вы заглядываете, если нужно быстро вспомнить теорию или подсмотреть чек-лист? Делитесь своими любимыми ссылками и находками в комментариях! 👇

​​#proQuality_books #softwareTesting
 
📖 Drawn to Testing (2025)
Автор: Wayne Roseberry
Количество страниц: 142
Язык издания: Английский
 
Эссе и комиксы об искусстве тестирования ПО: от поиска идей для тестов и управления проблемами до борьбы с flaky-багами. Простые иллюстрации раскрывают нюансы профессии, о которых редко говорят в подобном ключе.
 
Плюсы:
➕ Живая и увлекательная книга, основанная на реальном опыте автора.
➕ Уникальный формат комиксов и диаграмм помогает взглянуть на сложные вещи под новым углом.
➕ Отличный инструмент критического мышления с идеями, применимыми на практике.
 
Минусы:
➖ Формат эссе и комиксов понравится не всем — любители структурированных руководств могут почувствовать нехватку системности.
 
Для кого книга:
✔️ Для тестировщиков, желающих освежить взгляд на профессию и углубить понимание ремесла.
✔️ Для разработчиков, которые хотят научиться мыслить как тестировщик.
 
Об авторе:
Wayne Roseberry — эксперт в области тестирования ПО, делящийся опытом через наглядные иллюстрации и комиксы для поддержания живого интереса к ремеслу тестирования.

#ProQuality_case

🔥 Проблема тестовых окружений, которую так никто и не решил (и как с ней жить)

Всем привет! 👋 Знакома ситуация, когда на staging-сервере опять всё сломалось, кто-то затер ваши тестовые данные, а локальные моки давно не соответствуют реальности продакшена?

Carlos Arguelles (Senior Principal Engineer в Amazon) недавно опубликовал отличную статью: "The test environment problem nobody has solved". В ней он разбирает, почему классический подход к тестовым стендам в сложных распределенных системах (таких как микросервисная архитектура Amazon) больше не работает.

🤷‍♂️ Трилемма плохого выбора
При масштабировании проекты неизбежно сталкиваются с тремя вариантами настройки окружений, и все они плохие:
1️⃣ Использовать моки/фейки: они быстро расходятся с реальным поведением системы, из-за чего вы пропускаете настоящие баги на прод.
2️⃣ Общие staging-окружения: со временем они «протухают» и превращаются в дорогие, хрупкие системы. А тестировщики постоянно мешают друг другу, меняя общее состояние (state) базы.
3️⃣ Эфемерные full-stack копии: на масштабах гигантов поднять точную изолированную копию продакшена со всеми его зависимостями просто невозможно.

📉 Математика flaky-тестов и ИИ-ускорение
В распределенных системах общая надежность тестов перемножается. Если ваш интеграционный тест затрагивает всего три микросервиса, и каждый из них стабилен на 95%, итоговая надежность падает до неприемлемого уровня.
Ситуация усугубляется внедрением AI-ассистентов: нейросети генерируют код со скоростью машины, но медленный, мигающий (flaky) контур CI/CD и интеграционных тестов просто не успевает за ними, ломаясь на скрытых стыках сервисов.

💡 Какой выход видят архитекторы?
Передовой рубеж — безопасное использование самого продакшена как идеальной тестовой среды.
Вместо попыток воссоздать Prod, компании учатся гонять тестовый трафик на «живых» серверах. Как это делается:
✅ Продвинутая маршрутизация трафика;
✅ Изолированные (sandboxed) токены транзакций;
✅ Переопределение поведения (например, инжекция задержек или ошибок для конкретных вызовов);
✅ Строгое подавление побочных эффектов (side-effect suppression).
Это позволяет выполнять тесты в реальной графе продакшена без малейшего риска задеть реальных клиентов.

🔗 The test environment problem nobody has solved
💬 А какой подход к тестовым окружениям используется в вашей компании? Всё ещё воюете за общий staging, поднимаете on-demand стенды для каждого PR или уже практикуете безопасное тестирование прямо в проде? Делитесь болью и опытом в комментариях! 👇

​​#automationTesting

«Playwright сейчас модный, Selenium старый, Cypress удобный». Именно так чаще всего звучит выбор фреймворка на планировании и иногда поэтому команды разгребают последствия решения, принятого за один созвон.

В нашем сегодняшнем материале автор поделиться детальным сравнением Playwright, Selenium и Cypress, разберёт их архитектурные различия, сильные и слабые стороны, приведёт практические сценарии выбора, а также честно оценит стоимость миграции с одного фреймворка на другой.

Playwright vs Selenium vs Cypress: как на самом деле выбирать фреймворк для автотестов в 2026

​​#softwareTesting

Традиционных показателей вдруг стало недостаточно для релизных решений. Современные метрики в тестировании всё чаще рассматриваются как инструмент управления рисками, но какие метрики в тестировании остаются актуальными в 2026 году?

В новой статье автор расскажет о том, почему традиционные QA-метрики больше не отражают реальный риск продукта, и разберёт современные метрики тестирования, а также даст практические шаги по их внедрению для принятия релизных решений.

Какие метрики в тестировании в 2026 году действительно влияют на релиз и бизнес