Михаил Фёдоров, автор системы QA Assist, зафиксировал момент: после очередной оптимизации системного промта он снова написал в коммите «кажется, стало лучше» — и не смог это доказать. Ответом стал отдельный бенчмарк-проект с намеренно заложенными багами. Два прогона по одному и тому же набору из 14 эталонных дефектов — пайплайн QA Assist против нативного Claude с одним промтом. Оба используют Claude Opus. Разрыв в recall — 29 процентных пунктов.
Контекст
QA Assist — это пайплайн из специализированных агентов: декомпозиция требований, генерация тест-кейсов, запуск pytest и Playwright, оформление баг-репортов в Jira, traceability matrix. Автор публикует серию материалов о построении AI-тестирования в реальных условиях — от архитектуры до корпоративной реальности, где «4 часа подключения» превращаются в неделю согласований.
Бенчмарк-проект — маленькое Flask-приложение CallMeBack: форма обратного звонка, страница успеха, админка с Basic Auth. В репозитории две ветки: main с кодом и требованиями — то, что видит агент, и benchmark с эталонным списком дефектов — то, что агент видеть не должен. Намеренно заложено 25 багов по девяти категориям: security (XSS, SQL injection), валидация, функциональность, API-контракт, UX, accessibility, производительность, целостность данных, забытые артефакты (console.log в проде, мёртвый код).
Ключевой принцип — бенчмарк живёт отдельно от основного репозитория: агент работает с ним как с боевой задачей. Второй принцип — компактность: маленький проект означает маленький контекст и дешёвую итерацию. Гипотезу можно проверять несколько раз в день.
Аналитика
Разрыв в 29 п.п. recall — не разница в «уме модели». Под капотом у обоих один и тот же Claude Opus. Разница — в инструментарии: у QA Assist есть автогенерация pytest-тестов по acceptance criteria, DOM-инспекция через Playwright, оптимизаторы требований и сценариев. У Claude «в лоб» — только curl, DevTools через MCP и интуиция.
Разбивка по происхождению бага даёт чёткую картину: requirements-driven дефекты (описанные в acceptance criteria) — recall около 90%; баги, которые без спеки заметил бы опытный инженер (general_expertise) — около 50%. Stack trace в 500-х ответах, console.log в проде, вызов fetch без предварительной валидации — это не ловится ни pytest'ом по AC, ни DOM-инспекцией. Только осознанным «потыкать руками с гипотезами». Автор называет это следующим шагом для пайплайна: отдельный скилл для исследовательского тестирования.
Главное преимущество пайплайна — не победа по recall в одном прогоне, а то, что остаётся после: переиспользуемые артефакты (requirements → scenarios → tests), traceability matrix, сгенерированные pytest/Playwright-тесты в CI. Claude «в лоб» каждый раз начинает с нуля и снова тратит токены на повторение одной и той же работы.
Кейсы применения в бизнесе
B2B-SaaS стартап без выделенного QA. Даже без полного оркестратора — структурированный промт с явными acceptance criteria и браузерным MCP даёт recall выше 50% по требованиям. Следующий шаг: автоматизировать генерацию xfail-тестов с привязкой к тикетам, чтобы CI ловил регрессии без токенов при каждом PR.
Корпорация с legacy-кодом без тестов. Бенчмарк-подход работает в обратную сторону: сначала написать небольшой модуль-стенд с намеренными регрессиями, прогнать агента, убедиться что он их ловит — и только потом переносить подход на боевые компоненты. Recall по эталону сразу показывает, на что нельзя полагаться.
SMB и локальный бизнес в КР/СНГ. Веб-сервис с редкими релизами и нулевым QA. Claude «в лоб» с требованиями — уже лучше нуля. Но если зафиксировать пул из 10–15 типичных регрессий для своего проекта и гонять его при каждом релизе, бенчмарк превращается в smoke-suite с измеримым покрытием — за несколько минут и без найма тестировщика.
Кейсы в личной жизни
Разработчик-одиночка с pet-проектом. Claude с Playwright MCP + явные acceptance criteria в markdown — и recall по описанным требованиям уже около 90%. Главное — структурировать AC с ID перед прогоном, иначе агент работает только на интуиции.
QA-инженер, которому нужно обосновать бюджет на AI-инструменты. Собери мини-бенчмарк: модуль с известными тебе дефектами, эталонный список, два прогона. «Агент нашёл 9 из 14 известных багов за 20 минут» — это конкретный аргумент, а не «вроде помогает».
Студент или джун, изучающий тестирование. Открытый репозиторий CallMeBack (автор spoon03 на GitHub) — готовый учебный стенд: 25 намеренных багов девяти категорий, эталонный список в ветке benchmark, методика скоринга TP/FP/Miss. Попробуй найти баги вручную, потом сравни с агентом.
Как применить сегодня
- Найди репозиторий qa-benchmark-callmeback (автор spoon03) на GitHub — там готовый стенд, эталонный список багов и методика оценки.
- Прогони на нём Claude с Playwright MCP одним промтом: «Ты QA-инженер. Вот требования. Реализация на localhost:5000. Найди все баги.» Посчитай recall вручную по категориям.
- Структурируй acceptance criteria в явные требования с уникальными ID — это поднимает recall с ~50% до ~90% для requirements-driven дефектов.
- Добавь xfail-тесты с привязкой к тикетам в CI: исправление бага автоматически делает тест зелёным без ревью.
- Зафиксируй свой эталонный список типичных регрессий для реального проекта — и «вроде стало лучше» превратится в измеримый процент.
Claude «в лоб» решает одну задачу здесь и сейчас — найти баги. Пайплайн строит инфраструктуру вокруг этой задачи: изолированные скиллы, оркестрацию, переиспользуемые артефакты, заложенный путь к масштабированию.