#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 за один проход автотеста? И как вам идея добавить четвертый уровень в классическую пирамиду тестирования? Делитесь мыслями в комментариях! 👇

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

Всем привет! С вами снова рубрика задачки ProQuality ✨

Задача про свечи 🕯

У Дианы 100 свечей. Каждый вечер она зажигает одну свечу. Из остатков шести сгоревших свечей она всегда может сделать новую.

Через сколько дней закончится запас свечей?

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