ProQuality Community

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

#ProQuality_interview Всем привет! С вами снова рубрика Scenario-based вопрос на собеседовании ✨ ❓Вопрос: В гибкой методологии разработки вы получаете всего один день на тестирование задачи. Как вы организуете тестирование? 🚦Пример ответа: ✔️Разбейте задачу на тестируемые части, чтобы каждую часть можно было эффективно и результативно протестировать. ✔️Проводите параллельное тестирование, пока разработчик завершает задачи. ✔️Сначала сосредоточьтесь на "happy path" с корректными входными данными, чтобы убедиться, что основная функция работает. ✔️Автоматизируйте проверки на корректность, чтобы ускорить тестирование. ✔️Используйте исследовательское тестирование для оптимизации покрытия кода.

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

#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? Как думаете, как быстро этот метод станет стандартом в индустрии? Делитесь мыслями в комментариях! 👇

#softwareTesting Когда идёт речь про микросервисы, большинству читателей представляется сложная архитектура связей между различными блоками, внешними системами, другими микросервисами и базой данных. То есть первым делом мы, конечно же, думаем о backend микросервисах. В данной статье описываются методология и практический опыт нагрузочного тестирования UI-микросервисов на реальном примере инцидента с троттлингом процессора, включая парсинг манифеста и загрузку статических ассетов в JMeter. Новая эра: нагрузочное тестирование UI‑микросервисов

#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? Делитесь мыслями в комментариях! 👇

​​#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_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_tasks

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

​​#ProQuality_tasks Всем привет! С вами снова рубрика задачки ProQuality ✨ Задача про свечи 🕯 У Дианы 100 свечей. Каждый вечер она зажигает одну свечу. Из остатков шести сгоревших свечей она всегда может сделать новую. Через сколько дней закончится запас свечей?

​​#proQuality_books #softwareTesting #dataQuality   📖 Data Quality Fundamentals: A Practitioner's Guide to Building Trustworthy Data Pipelines (2022) Авторы: Barr Moses, Lior Gavish, Molly Vorwerck Количество страниц: 308 Язык издания: Английский   Авторы предлагают комплексный подход к качеству данных в масштабе организации: Data Observability, SLA/SLI/SLO для данных, автоматические графы происхождения и детекторы аномалий.   Плюсы: ➕ Практический фокус на ETL/ELT процессах и хранилищах данных. ➕ Сильная концептуальная база по SLA/SLI/SLO для данных. ➕ Реальные кейсы и интервью с экспертами отрасли. ➕ Помогает руководителям обоснованно инвестировать в фреймворки качества данных.   Минусы: ➖ Страдает от самоповторов и слабой редактуры. ➖ Заметный маркетинговый тон в пользу определенной платформы. ➖ Связка качества данных с Data Mesh выглядит натянутой.   Для кого книга: ✔️ Для data и data quality инженеров и аналитиков, уставших от «поломанных» отчётов и недостоверных данных. ✔️ Для руководителей, выстраивающих прозрачные процессы мониторинга данных в компании. ✔️ Для начинающих специалистов, погружающихся в основы Data Observability.   Об авторах: Barr Moses, Lior Gavish и Molly Vorwerck — сооснователи платформы Monte Carlo, активно развивающие отраслевые стандарты мониторинга и контроля качества данных.

#ProQuality_news 🤖 Agentic Testing: Место ИИ-агентов в пирамиде тестирования (опыт Slack) Команда инженеров Slack опубликовала статью о том, как они прогнали более 200 E2E-тестов с помощью автономных ИИ-агентов (на базе моделей Claude). Цель — понять, готовы ли агенты заменить классические автотесты. Спойлер: не готовы, но у них есть своя суперсила. 🎯 Главное отличие: Путь vs. Цель Традиционные тесты жестко проверяют маршрут (кликни сюда -> введи текст -> проверь ассерт). ИИ-агенты проверяют цель (например, «отправь сообщение в тред и убедись, что оно там»). Агент сам анализирует DOM, адаптируется к изменениям верстки и каждый раз может находить разные пути для выполнения задачи. 📊 Что показал эксперимент Slack? Инженеры сравнили автономных агентов (через Playwright MCP и CLI) и детерминированные тесты, код которых был просто сгенерирован ИИ. 1️⃣ Надежность: На сложных UI-сценариях связка «Агент + Playwright MCP» показала лучшую стабильность (от 0 до 12% падений). А вот статичные автотесты, сгенерированные ИИ заранее, с треском провалились — 48% падений из-за малейших изменений стейта приложения. 2️⃣ Скорость и Цена (шок-контент): Агенты работают медленно (от 5 до 11 минут на тест). Но главное — это безумно дорого! Из-за того, что агенту постоянно нужно «скармливать» слепки DOM и историю шагов, один прогон агента стоил Slack от $15 до $30! 🤯 🔺 Новый слой пирамиды тестирования Slack делает однозначный вывод: ИИ-агенты пока не могут (и не должны) заменять быстрые и дешевые E2E-тесты в CI/CD пайплайнах. Вместо этого агенты формируют новый, четвертый слой на самой вершине пирамиды тестирования. Их идеальный юзкейс сегодня: • Exploratory Testing (исследовательское тестирование) сложных сценариев • Автоматический дебаг плавающих (flaky) багов • Воспроизведение хитрых дефектов прямо с продакшена 🔗 Agentic Testing: Where Agents Fit in the E2E Testing Stack 💬 Как вам стоимость в $15–30 за один проход автотеста? И как вам идея добавить четвертый уровень в классическую пирамиду тестирования? Делитесь мыслями в комментариях! 👇

#softwareTesting #automationTesting Apache Kafka — это система управления потоками данных, которая позволяет приложениям обмениваться сообщениями в реальном времени. В новой статье автор рассмотрит основы Apache Kafka, её архитектура, принципы работы, подходы и инструменты для тестирования сообщений в топиках (включая ручные и автоматизированные методы), а также приводятся практические примеры интеграционных тестов с использованием Testcontainers, Java и Awaitility. Apache Kafka: как настроить тестирование сообщений в топиках

#automationTesting Kubernetes — это платформа для автоматического развертывания, масштабирования и управления контейнеризированными приложениями. В данной статье описываются опыт построения системы автоматизированного тестирования для Kubernetes-платформы, включая выбор инструментов (Python, PyTest, Playwright), организацию выделенного тестового окружения, интеграцию с CI/CD, формирование отчётности. Автотесты: опыт построения системы качества для Kubernetes-платформы

#ProQuality_case 🚀 AI-Native Testing: Как Amazon полностью перестраивает QA-процессы под искусственный интеллект Carlos Arguelles (Senior Principal Engineer в Amazon) опубликовал крутую статью-выжимку своего недавнего доклада. Главный инсайт: ИИ уже генерирует код в 10 раз быстрее, но наша инфраструктура тестирования за этим не поспевает. Если скорость разработки растет, а тесты становятся узким горлышком — бизнес всегда будет жертвовать качеством ради скорости релизов. Чтобы этого избежать, Amazon внедряет концепцию автономных ИИ-агентов и 5 столпов AI-native тестирования: 1️⃣ Test Coverage (Покрытие): Amazon уходит от жестких UI-фреймворков. Вместо хрупких скриптов они используют инструкции на естественном языке. LLM получает промпт: «Найди книгу про Гарри Поттера, положи в корзину и проверь, что она там». Никаких локаторов — только plain English. Это радикально снизило уровень flaky-тестов. 2️⃣ Test Stability (Стабильность): Копии продакшена никогда не бывают идеальными. Поэтому Amazon делает смелую ставку на тестирование прямо в Production. Через сложную систему роутинга они гоняют тестовый трафик на реальных сервисах, обрезая критичные сайд-эффекты (например, списание денег с реальных карт). 3️⃣ Test Adequacy (Адекватность тестов): Как проверить, что тесты, написанные ИИ, вообще находят ошибки? Через продвинутое мутационное тестирование. Amazon разработали инструмент (в шутку названный Bug Injector 3000), который намеренно вносит хитрые баги в код, чтобы проверить, пропустит ли их пайплайн. 4️⃣ Test Efficiency (Эффективность): Традиционные фермы девайсов для мобильного тестирования не масштабируются при ускорении разработки в 10 раз. Выход — переход от физических устройств на десятки тысяч виртуальных девайсов в контейнерах. 5️⃣ Non-determinism (Недетерминированность): Классическая бинарная логика «pass/fail» плохо работает с ИИ-фичами (вроде умных чат-ботов). QA-инженерам нужно учиться тестировать недетерминированные системы, где результат может каждый раз немного отличаться. 🤯 Забавный фейл из практики Amazon: На первых этапах внедрения ИИ-агенту поручили протестировать логин, но дали неверный пароль. Вместо того чтобы выдать ожидаемый Test Failed, агент проявил инициативу: нашел кнопку «Создать аккаунт», попытался зарегистрироваться, а когда это не помогло — пошел в чат поддержки разбираться с живым оператором! 😂 Теперь разработчикам приходится ставить жесткие «ограждения» (guardrails) для ИИ-тестировщиков. 🔗 AI-Native Testing: Adapting our Validation Practices for Accelerated Development 💬 Давайте обсудим! Готовы ли доверить прохождение ваших UI-тестов ИИ-агентам, или хардкодный Playwright/Cypress с нами еще надолго? Делитесь мыслями в комментариях! 👇