Тестирование «отстаёт» от разработки, автотесты не успевают за сценариями, а увеличение бюджета на QA ситуацию не спасает. Знакомо?
Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.
Оглавление
Проблема: почему тестирование буксует
Идея: QA-инженер как оператор AI-ассистента
Архитектура: 11 скиллов, один пайплайн
Подробнее о каждом этапе
Оркестрация: мульти-агентное параллельное выполнение
Интеграции: Jira, Figma, Zephyr, GitLab
Технические решения и грабли
Результаты и метрики
Чему мы научились
Что дальше
1. Проблема: почему тестирование буксует
Представьте типичную ситуацию. Разработка выкатывает фичу, QA-инженер садится писать тест-кейсы, параллельно разбирается в требованиях, заводит их в TMS, готовит тестовые данные, пишет автотесты… А к этому моменту разработка уже выкатила следующую фичу. Автотесты не дописаны, приходится быстро проверять руками, пропускать менее приоритетные виды проверок. Тест-кейсы пишутся в формате чеклистов — на подробные сценарии с шагами времени нет. Ротация тестировщика – катастрофа: на погружение нужен месяц минимум. Подключение автоматизатора – тоже проблема: сначала нужно детализировать сценарии, чтобы он хоть что-то понял из чеклистов. В итоге ручной регресс растёт от спринта к спринту.
Мы проанализировали, на что уходит время QA-инженера:
Активность | Доля времени |
|---|---|
Анализ требований и тест-дизайн | ~20% |
Создание тест-кейсов в TMS | ~15% |
Подготовка тестовых данных | ~10% |
Автоматизация тестовых сценариев | ~25% |
Проведение тестирования | ~15% |
Регресс | ~10% |
Подготовка отчётов | ~5% |
До 80% времени инженера уходит на задачи, которые поддаются систематизации и автоматизации. При этом:
С ростом сложности продукта растёт число багов
Автотесты «не успевают» за доработками сценариев, растет время регресса
Сложно понять, что именно проверяют автотесты и насколько оптимально покрытие
С ростом бюджета на QA ситуация принципиально не меняется
Нам нужно было не просто ускорить отдельные этапы, а перестроить весь процесс – от получения требований до готового отчёта.
2. Идея: QA-инженер как оператор AI-ассистента
Мы сформулировали концепцию так: QA-инженер не заменяется, а усиливается. Как экзоскелет умножает физическую силу, так AI-ассистент умножает продуктивность инженера.
Что изменилось в роли инженера
Было:
Инженер лично выполняет каждый этап тестирования
Каждый использует свой набор промптов и инструментов
Ручное управление тестовыми данными, ручной тест-дизайн
Формат результата не учитывает дальнейший жизненный цикл
Стало:
Инженер определяет правила работы ассистента, руководствуясь корпоративной стратегией
Инженер ставит задачи ассистенту
Инженер контролирует качество артефактов на каждом этапе
Инженер корректирует результат при необходимости
Ключевые принципы
Ассистент не требует глобальных изменений – он подстраивается под ваш стек. Привычные TMS, Task-tracker, язык автоматизации, CI/CD – всё остаётся прежним.
Прозрачность – все артефакты генерируются в привычных форматах. Сценарии и отчеты в Zephyr, автотесты на pytest. Инженер всегда видит, что происходит.
Полный контроль – возможность аудита ассистента на любом этапе. Чёткие зоны ответственности.
Масштабируемость – один QA может управлять несколькими проектами. Легко прогнозировать рост трат при масштабировании с сохранением стандартного уровня качества.
3. Архитектура: 11 скиллов, один пайплайн
Система построена на базе Claude Code Skills – модульной системе агентов, где каждый скилл отвечает за свой этап QA-процесса.
Общая схема
Jira/Confluence │ ▼ ┌─────────────┐ ┌──────────────┐ ┌────────────────────┐ │ Загрузка │───→│ Декомпозиция│───→│ Генерация сценариев│ │ требований │ │ требований │ │ │ └─────────────┘ └──────────────┘ └────────┬───────────┘ │ ┌──────────────────────┤ │ │ ┌──────▼──────┐ ┌──────────▼──────────┐ │ Автоматизация│ │ Автоматизация │ │ API тестов │ │ UI тестов │ └──────┬──────┘ └──────────┬──────────┘ │ │ └──────────┬───────────┘ │ ┌──────▼──────┐ │ Валидация │ │ и доставка │ └──────┬──────┘ │ ┌───────┴───────┐ ▼ ▼ GitLab MR Zephyr Scale
11 скиллов системы
# | Скилл | Назначение | Вход | Выход |
|---|---|---|---|---|
1 | jira-fetch | Загрузка задач из Jira/Confluence | URL задачи | Markdown + вложения |
2 | requirements-decomposer | Декомпозиция на User Stories и Tasks | Markdown | Структурированные US/Task |
3 | scenarios-generator | Генерация тестовых сценариев по ISTQB | Требования + Figma | JSON-сценарии + RTM |
4 | scenario-data-fix | Сбор недостающих тестовых данных | Сценарии + Global Context | Обновлённые сценарии |
5 | scenario-discrepancies-fix | Исправление расхождений с UI/API | ERRORS_DISCREPANCIES.md | Исправленные сценарии |
6 | selectors-collector | Сбор CSS/Playwright селекторов из DOM | Сценарии | SELECTORS.json (POM) |
7 | automation-api | Генерация pytest + requests | JSON-сценарии | Готовый проект автотестов |
8 | automation-ui | Генерация pytest + Playwright | JSON-сценарии + SELECTORS.json | Готовый проект UI-тестов |
9 | automation-compare | Сверка сценариев с автотестами | JSON + pytest-код | COMPARISON_REPORT.md |
10 | zephyr-uploader | Загрузка тест-кейсов в Zephyr Scale | JSON-сценарии | Кейсы в TMS |
11 | mr-creator | Создание Merge Request в GitLab | Готовые автотесты | MR в целевом репозитории |
Плюс оркестратор – координатор, который управляет параллельным выполнением и контролирует качество на каждом этапе.
4. Подробнее о каждом этапе
4.1. Загрузка и анализ требований
Всё начинается с URL Jira-задачи. Скилл jira-fetch через REST API вытягивает:
Описание задачи и поля
Вложения (PDF, DOCX, XLSX, PPTX) – автоматически скачиваются и парсятся
Подзадачи рекурсивно
Данные из связанных страниц Confluence
Важно, что входные данные не обязаны следовать какой-то жёсткой структуре – задача может быть оформлена как угодно: свободным текстом, таблицами, вложенными документами. Главное, чтобы требования были полными по содержанию. Всё остальное система разберёт сама.
Затем requirements-decomposer декомпозирует всё это в структурированные документы. Для этого этапа мы совместно с отделом аналитики проработали специальные шаблоны декомпозиции, которые учитывают принятые в компании стандарты описания User Stories и Tasks. Это обеспечивает единообразие артефактов независимо от того, в каком формате пришли исходные требования.
testing/requirements/DEVAI-258/ ├── US-001.md # User Story с Acceptance Criteria ├── TASK-001.md # Backend Task ├── TASK-002.md # Frontend Task ├── NOTES-classification.md └── _index.json # Метаданные для машинной обработки
На каждом уровне – будь то User Story или задача на разработку компонента – формируются функциональные требования, нефункциональные требования и критерии приёмки. Требования декомпозированы до атомарных проверок, и именно с ними идёт основная работа на всех последующих этапах:
## Функциональные требования (ФТ) ### Endpoint подключения - **F-DEVAI-283-BE-01**: Endpoint `POST /api/v1/integrations/confluence/connect` принимает `url` и `token` - **F-DEVAI-283-BE-02**: При невалидном формате данных возвращать `400 Bad Request` ## Нефункциональные требования (НФ) - **NF-DEVAI-283-BE-01**: Время ответа эндпоинта подключения ≤ 3 секунд ## Acceptance Criteria ### Подключение — успех - **AC-DEVAI-283-01**: Пользователь с валидными `url + token` успешно подключает Confluence. Запрос возвращает `success: true` ### Подключение — ошибка - **AC-DEVAI-283-03**: При невалидных данных показывается сообщение «Неверные данные для входа»
Здесь же автоматически подгружается Global Context – централизованное хранилище знаний о проекте (API-контракты, эндпоинты, тестовые данные, архитектура). Это позволяет генерировать сценарии с учётом реального окружения, а не в вакууме.
4.2. Генерация тестовых сценариев
Это ключевой этап. Тест-дизайн строится в соответствии с пирамидой тестирования: на уровне User Story генерируются e2e-сценарии, покрывающие сквозные пользовательские пути, а на уровне компонентных задач – изолированные тесты отдельных модулей (API-эндпоинтов, UI-форм).
scenarios-generator применяет техники тест-дизайна по ISTQB автоматически:
Эквивалентное разбиение – группировка входных данных в классы
Анализ граничных значений – тестирование пределов (min, max, off-by-one)
Таблицы решений – комбинаторное тестирование сложных условий
Переходы состояний – многошаговые пользовательские сценарии
Каждый сценарий генерируется в строгом JSON-формате с полной трассируемостью:
{ "testSuite": { "name": "US-001: Авторизация пользователя", "level": "api", "testCases": [ { "id": "TC-001-001", "name": "Успешная авторизация с валидными данными", "priority": "HIGH", "preconditions": [ "Пользователь valid@test.com зарегистрирован в системе", "Сервис авторизации доступен" ], "testSteps": [ { "stepNumber": 1, "action": "POST /api/auth/login", "inputData": "{ email: 'valid@test.com', password: 'ValidPass123' }", "expectedResult": "HTTP 200, JWT токен в ответе" } ], "traceability": { "requirementIds": ["F-DEVAI-258-01"], "acceptanceCriteria": ["AC-DEVAI-258-01"], "userStory": "US-001" } } ] } }
Параллельно формируется Requirements Traceability Matrix (RTM) – матрица покрытия требований тестами. Она показывает, какой процент требований покрыт сценариями:
| ID требования | Название | Статус | Тесты | Покрытие | |----------------|--------------------|-----------|-------|----------| | F-DEVAI-258-01 | Авторизация | Покрыто | 2 | 100% | | F-DEVAI-258-02 | Поиск товаров | Покрыто | 2 | 100% | | F-DEVAI-258-03 | Оформление заказа | Частично | 1 | 50% |
4.3. Интеграция с Figma (MCP)
Для фронтенд-задач система подключается к Figma через Model Context Protocol (MCP). Это не просто скриншоты – мы анализируем структуру макетов:
Извлекаем UI-элементы, текст, состояния и ограничения
Определяем расхождения между требованиями и дизайном
Выявляем неочевидные кейсы (например, дизайн показывает, что кнопка скрыта, а не задизейблена – это разные тест-кейсы)
Результаты сохраняются в FIGMA_DATA.json и автоматически учитываются при генерации UI-сценариев.
4.4. Автоматизация: API и UI тесты
Генератор API-тестов (automation-api) создаёт полностью автономный pytest-проект:
testing/auto/DEVAI-258/api/ ├── conftest.py # Фикстуры: APIClient, авторизация, тестовые данные ├── tests/ │ ├── test_auth.py │ ├── test_search.py │ └── test_orders.py ├── config.yaml # Конфигурация окружения ├── test_data.yaml # Тестовые данные ├── requirements.txt └── pytest.ini
Аналогично работает automation-ui, но с Playwright и использованием собранных DOM-селекторов.
Важный момент – четырёхфазный пайплайн автоматизации:
Setup: загрузка контекста, API-контрактов, тестовых данных
Генерация кода: создание pytest-файлов из JSON-сценариев
Отладка – состоит из двух этапов (подробнее ниже)
Отчёты: маркировка тестов (pass/skip/xfail), генерация DEBUG_REPORT.md
4.5. Отладка автотестов
Отладка состоит из двух этапов.
Этап 1 – функциональная отладка. Каждый тест запускается индивидуально. Ошибки классифицируются: баг в коде теста (опечатка, неверный эндпоинт, неправильные данные) или реальный дефект системы. Баги кода исправляются автоматически, реальные дефекты маркируются как xfail. Для UI-тестов на этом же этапе подбираются и уточняются селекторы элементов через отдельный скилл selectors-collector.
Этап 2 – мутационное тестирование. После того как тест прошёл, мы инвертируем его assert’ы:
# Оригинальный тест assert response.status_code == 200 # Мутация: инвертируем ожидание assert response.status_code == 400 # Должен упасть!
Если мутированный тест тоже проходит – значит, оригинальный тест ничего не проверяет. Это позволяет отсеять «пустые» тесты, которые создают иллюзию покрытия.
4.6. Обработка расхождений
На протяжении всего пайплайна скиллы фиксируют расхождения между источниками данных: требования говорят одно, Figma показывает другое, а реальный интерфейс ведет себя по-третьему. Все такие расхождения записываются в единый протокол – ERRORS_DISCREPANCIES.md. Скилл discrepancies-fix обрабатывает этот протокол, классифицирует каждый пункт и контролирует его статус.
В авто-режиме работает иерархия приоритетов источников: Jira > Figma > Требования > Тестовые сценарии > Реализация. Расхождения, где приоритет однозначен, закрываются автоматически. Остальные – выносятся на решение инженера.
Пример автоматического закрытия. В требованиях написано: «Показать текст: При удалении папки мы перенесем все чаты в архив. Удалить папку?» – одной фразой. В Figma – заголовок «Удалить папку?» и отдельный текст «При удалении папки мы перенесем все чаты в архив». Тип расхождения – FIGMA_REQ_MISMATCH. Figma имеет приоритет над текстовыми требованиями для UI-элементов, поэтому сценарий обновляется автоматически.
Пример обработки бага. Backend должен возвращать 400 при имени домена длиннее 50 символов, но реально возвращает 201 Created. Тип – BUG_MISSING_VALIDATION. Это реальный дефект, и автоматически его закрыть нельзя. Скилл перепроверяет воспроизводимость, оформляет баг-репорт и запрашивает у инженера разрешение на создание дефекта в Jira. После подтверждения – создаёт тикет и маркирует затронутые тесты как xfail с привязкой к нему.
4.7. Доставка результатов
На финальном этапе:
zephyr-uploader загружает тест-кейсы в Zephyr Scale через ATM API, с правильными приоритетами, тегами и привязкой к проекту. После загрузки маркирует автотесты ключами Zephyr для связи между кодом и TMS
mr-creator клонирует целевой репозиторий автотестов, создаёт feature-ветку, анализирует совместимость (конфликты фикстур, зависимости, .env), копирует файлы и создаёт Merge Request через GitLab API
5. Оркестрация: мульти-агентное параллельное выполнение
Оркестратор – это координатор, который управляет всем пайплайном. Он никогда не выполняет скиллы сам – вся работа делегируется субагентам через Task API.
Ключевые задачи оркестратора:
Точка входа для инженера – всегда может объяснить текущий статус задачи, что уже сделано и что осталось
Контроль соблюдения этапов – гарантирует правильную последовательность выполнения и не пропускает шаги
Контроль качества артефактов – валидирует выходные данные каждого этапа перед передачей на следующий
Ускорение пайплайна – распараллеливает независимые задачи между агентами
Режимы выполнения
Режим | Описание | Пример |
|---|---|---|
single_skill | N агентов работают над одним скиллом | 3 агента генерируют API-тесты параллельно |
parallel_types | API и UI автоматизация параллельно | Два агента одновременно пишут API и UI тесты |
batch_issues | Обработка нескольких задач | DEVAI-258 и DEVAI-259 одновременно |
pipeline | Полный цикл с зависимостями | Jira → сценарии → автотесты → MR |
Контрольные точки (Quality Gates)
Оркестратор проверяет качество на каждом этапе. Например, после генерации сценариев проверяется:
Корректность JSON-схемы
Наличие трассируемости требований
Полнота покрытия (по RTM)
Наличие и заполненность шагов
Разметка приоритетов
Отсутствие дублирования
После автоматизации – ещё более строгая проверка: 14+ контрольных точек для API и 16+ для UI, включая валидацию синтаксиса Python-кода, запуск тестов, проверку фикстур.
Структура полного пайплайна
Этап 1: Подготовка → jira-fetch + requirements-decomposer [CHECKPOINT: 6 проверок] Этап 2: Генерация → scenarios-generator (2 агента: API + UI) [CHECKPOINT: 6 проверок] Этап 2.5: Селекторы → selectors-collector + валидация [CHECKPOINT: проверка SELECTORS.json] Этап 3: Автоматизация → automation-api + automation-ui (параллельно) [CHECKPOINT: 14 проверок API + 16 проверок UI] Этап 4: Валидация → automation-compare [CHECKPOINT: матрица соответствия] Этап 5: Исправления → discrepancies-fix + data-fix (авто-режим) Этап 6: Доставка → zephyr-uploader + mr-creator
6. Интеграции: Jira, Figma, Zephyr, GitLab
Схема данных
┌──────────────────────────┐ │ Knowledge & Data │ │ ┌───────┐ ┌───────────┐ │ │ │System │ │Integration│ │ │ │Contr. │ │ Contracts │ │ │ ├───────┤ ├───────────┤ │ │ │Test │ │Confluence │ │ │ │Data │ │ │ │ │ ├───────┤ └───────────┘ │ │ │ Jira │ │ │ └───────┘ │ └────────────┬─────────────┘ │ User QA ──→ AI Layer ←─────────┘ │ │ │ └──→ AI Agent Test Design │ └──→ AI Agent Automation │ └──→ LLM (Claude) │ └──→ Dev & QA Tools ├── TMS (Zephyr Scale) └── GitLab CI/CD
Что подключается
Система | Как используется | Протокол |
|---|---|---|
Jira | Загрузка задач, подзадач, вложений | REST API |
Confluence | Загрузка спецификаций | REST API |
Figma | Анализ UI-макетов | MCP (Model Context Protocol) |
Zephyr Scale | Загрузка тест-кейсов | ATM REST API |
GitLab | Создание MR с автотестами | REST API + Git |
Playwright | Сбор селекторов, UI-тестирование | Browser Automation |
Корпоративный Global Context
Централизованное хранилище знаний о проекте:
testing/jira/Global-context/PROJECT/ ├── services_endpoints.yaml # API URLs, базовые пути ├── test_data.yaml # Тестовые пользователи, данные ├── architecture.md # Описание архитектуры ├── openapi.yaml # API-спецификации └── glossary.md # Терминология проекта
Это позволяет каждому скиллу работать с реальным контекстом проекта, а не генерировать абстрактные тесты.
7. Технические решения и грабли
Решение 1: Минимальный стек для пилота
Для пилотной версии мы сознательно выбрали максимально простой стек: Claude Code и его нативные агенты. Никаких дополнительных фреймворков для оркестрации, очередей сообщений или кастомных рантаймов. Вся логика скиллов, координация агентов и интеграции реализованы средствами платформы. Это позволило сосредоточиться на бизнес-логике QA-процесса, а не на инфраструктуре.
Решение 2: JSON-сценарии как единый источник правды
Вместо того чтобы позволить тест-кейсам и автотестам расходиться (классическая проблема), мы сделали JSON-сценарии центральным элементом:
Требования → JSON-сценарии → pytest-код ↑ │ └─── Валидация ───┘
Скилл automation-compare сверяет код обратно с JSON: анализирует каждый шаг каждого тест-кейса и проверяет, как именно он реализован в pytest-коде. На выходе – метрика процента соответствия между сценариями и автотестами. Если соответствие ниже порога, расхождения автоматически исправляются. Это обеспечивает синхронизацию на протяжении всего пайплайна.
Решение 3: Идемпотентность операций
Каждый скилл можно безопасно перезапустить:
selectors-collectorобновляет только невалидированные селекторыdiscrepancies-fixпропускает уже закрытые пунктыmr-creatorпри повторном запуске определяет, что ветка существует, и делает инкрементальное обновление
Решение 4: Авто-режим для рутинных решений
Многие скиллы поддерживают флаг --auto:
discrepancies-fix --auto– автоматически закрывает очевидные расхождения по правилам приоритетов, оставляя неоднозначные для ручного разбораdata-fix --auto– сначала пытается найти данные в Global Context, спрашивает только по оставшимся пунктам
Это сокращает количество точек, где нужно вмешательство человека, при этом сохраняя контроль над неоднозначными решениями.
Грабли 1: Контекстное окно LLM
Организация работы с контекстным окном – один из ключевых моментов для получения хорошего результата. Причём проблема не только в переполнении: даже приближение к максимально допустимому объёму уже приводит к снижению качества ответа. Модель начинает «забывать» нюансы сложных промптов, пропускать детали, упрощать логику. Когда у вас задача с множеством API-контрактов и Figma-данными, всё это физически не помещается в один промпт без потери качества.
Решение: мы дробим задачи в двух измерениях. По горизонтали – декомпозиция требований: большая задача разбивается на User Stories и подзадачи с независимыми требованиями, каждая из которых помещается в свой контекст. По вертикали – разделение пайплайна на независимые этапы с чёткими input/output контрактами: каждый скилл получает ровно тот контекст, который нужен для его работы, а Global Context загружается частично, по запросу. В итоге система решает много мелких задач и объединяет результат.
Грабли 2: Галлюцинации при генерации тестов
LLM иногда «придумывает» несуществующие API-эндпоинты или параметры запросов.
Решение: интеграция с корпоративным Global Context (OpenAPI-спецификации, реальные эндпоинты). Генератор работает не в вакууме, а с привязкой к реальным контрактам. Плюс мутационное тестирование отлавливает тесты, которые проходят по случайности.
Отдельная история – нежелательное поведение модели, которое лечится точечными фиксами в промптах скиллов. Написать автотест без assert, проигнорировать нефункциональные требования, пропустить негативный сценарий – модель может ошибаться там, где не ждёшь. Мы постоянно отслеживаем результат и фиксим обнаруженные проблемы. Это непрерывный процесс, а не разовая настройка.
Грабли 3: Параллельное выполнение агентов
Когда несколько агентов работают одновременно, возникают конфликты: доступ к файлам, перезапись результатов, гонки состояний.
Решение: оркестратор изолирует рабочие пространства агентов и использует checkpoint-валидацию между этапами. Агент не начинает работу, пока не подтверждено качество артефактов предыдущего этапа.
Грабли 4: Ограничения платформы
Субагенты в Claude Code – экспериментальная функция со своими особенностями. Например, субагент безвозвратно завершается при достижении часового лимита на токены, и оркестратор должен это корректно обработать. Из-за бага субагенты некорректно работают с MCP-серверами (в частности с Figma), что приходится обходить на уровне архитектуры скиллов. Платформа активно развивается, и часть ограничений со временем уходит, но нужно быть готовым к тому, что инструмент ещё сырой.
8. Результаты и метрики
Что получаем на выходе
На входе – ссылка на Jira-задачу. На выходе:
Структурированные требования (User Stories + Tasks)
JSON-сценарии с полной трассируемостью
Матрица покрытия требований (RTM)
Готовый проект API-автотестов (pytest + requests)
Готовый проект UI-автотестов (pytest + Playwright)
Тест-кейсы в Zephyr Scale
Merge Request в целевом репозитории автотестов
Отчёты о качестве и расхождениях
Результаты за 1.5 месяца пилота
Метрика | До | После |
|---|---|---|
Регрессионных тест-кейсов | ~50 | ~400 |
Детализация шагов | Абстрактная, не хватало времени на подробности | Максимально подробная, каждый шаг с данными и ожидаемым результатом |
Автоматизация | Отсутствовала | ~100% покрытие регресса |
Время регресса | ~1 день | Десятки минут |
Время от завершения разработки до апрува QA | Несколько дней | Несколько часов |
Подключение тестирования на новый проект | Найм + адаптация (месяцы) | ~4 часа настройки, первые баги уже в бэклоге |
Обнаруженные противоречия в требованиях + баги | Единицы | 10+, система замечает нюансы, которые сложно уловить вручную |
Сравнение «было/стало»
Этап | Было | Стало |
|---|---|---|
Анализ требований | Ручная подгрузка, свои промпты | Автоматический сбор контекста по задачам |
Тест-дизайн | Ручной, у каждого свой подход | Единые шаблоны на базе стратегии QA |
Тестовые данные | Ручное управление | Генерация из корпоративных источников |
Создание кейсов в TMS | Ручное | Автоматический импорт |
Автоматизация | Ручная подготовка к автоматизации | Сценарии сразу генерируются с учётом автоматизации |
Тестирование новой фичи | Руками, т.к. автоматизация дорога | Автотесты готовы к завершению разработки |
Главное – теперь процесс тестирования это чётко структурированный пайплайн с понятным результатом и возможностью тонкой настройки под проект в соответствии с выбранной стратегией. Хотите внедрить pixel-perfect тестирование? Исследовательские тесты? Расширить нефункциональное покрытие? Добавить поддержку нового протокола или интеграцию со своей TMS? Всё гибко и решаемо – достаточно добавить или доработать соответствующий скилл.
Стоимость
Пилотная версия работает на подписке Claude Pro ($100/мес). Этого хватает для поддержки 2–3 проектов с объёмом около 100+ тестов в месяц на проект.
9. Чему мы научились
1. Модульность – ключ к развитию
Каждый скилл – это отдельный, самодостаточный агент с чёткими входами и выходами. Это позволяет:
Разрабатывать и тестировать скиллы независимо
Запускать параллельно через оркестратор
Заменять или дорабатывать отдельные этапы, не трогая остальные
2. Global Context решает проблему галлюцинаций
Централизованное хранилище знаний о проекте – это не просто удобство. Это необходимость для работы с LLM. Без контекста модель генерирует правдоподобный, но бесполезный код. С контекстом – рабочие тесты, привязанные к реальным эндпоинтам и данным.
3. Качество важнее скорости
На каждом этапе пайплайна стоит checkpoint-валидация. Это замедляет процесс, но предотвращает «каскад ошибок», когда некачественные артефакты одного этапа порождают мусор на следующем.
4. Авто-режим + ручной контроль = баланс
Полная автоматизация невозможна (и не нужна). Лучшая стратегия – автоматизировать очевидное и оставить человеку неоднозначные решения. Флаг --auto сначала закрывает всё, что может, а остальное предлагает на рассмотрение.
5. Инвестируйте в сбор контекста
LLM не сделает чуда, но он способен качественно проработать все поданные на вход данные. Если требования были описаны – они точно будут покрыты тестами. Но если у вас принято писать только заголовки в Jira-задачах, то сначала нужно поработать над процессами в команде. Качество результата напрямую зависит от качества входных данных.
10. Что дальше
Развитие функциональности
Идей для улучшения – больше, чем рук. Вот основные направления:
Расширение стека – сейчас система работает с Web + REST API, впереди поддержка SOAP, gRPC, GraphQL, мобильных приложений
Умный мёржинг в регресс – автоматическое встраивание новых тестов в существующую регрессионную модель с учётом приоритетов и зависимостей
Покрытие старой функциональности – генерация тестов не только для новых фич, но и для уже существующего функционала, где покрытие недостаточно
Работа с дефектами – полный цикл: обнаружение, классификация, создание в Jira, отслеживание статуса, автоматическое снятие xfail после фикса
Путь к SaaS
Реализация на Claude Code отлично подошла для пилота: минимальный стек, быстрый старт, возможность итеративно отлаживать каждый скилл. Но для полноценного продукта нужен другой уровень – управление пользователями, мониторинг, биллинг, стабильная работа без ограничений CLI. Поэтому мы уже смотрим в сторону создания самостоятельного продукта – многопользовательского веб-сервиса с:
Веб-интерфейсом для управления пайплайнами (React)
Асинхронной обработкой через Temporal
Multi-tenancy с изоляцией данных (PostgreSQL RLS)
Системой подписки и usage-based billing (Stripe)
Интеграцией с Claude Agent SDK для управления агентами
Безопасность данных
Мы понимаем, что безопасность – краеугольный камень при работе с внешними LLM. В рамках пилота контроль чувствительных данных лежит в зоне ответственности пользователей: инженер сам решает, какие данные попадают в контекст. Но для продуктового решения этого недостаточно, и мы прорабатываем варианты:
Маскирование данных – автоматическая замена чувствительных значений (токены, пароли, персональные данные) перед отправкой в LLM и восстановление в результатах
On-premise LLM – возможность развёртывания с локальными моделями, когда данные не покидают контур компании
Политики доступа – гранулярное управление тем, какие проекты, репозитории и данные доступны каждому пользователю
Аудит-лог – полная запись всех запросов к LLM для контроля и compliance
Заключение
Так уволят ли завтра всех тестировщиков? Мы проверили на практике и вот что поняли:
QA Assist – это не замена тестировщика. Это инструмент, который превращает QA-инженера из исполнителя рутинных задач в оператора, управляющего AI-агентами. Инженер принимает ключевые решения, определяет стратегию, контролирует качество – а система выполняет объём работы, который раньше требовал целой команды.
Мы не пытались создать «чёрный ящик», который магически выдаёт автотесты. Мы построили прозрачный, контролируемый пайплайн с чёткими промежуточными результатами на каждом этапе. И именно эта прозрачность позволяет доверять результату.
Использование AI безусловно станет корпоративным стандартом на горизонте нескольких лет. Но глубокая экспертиза в тестировании будет востребована всегда – именно она определяет, чему учить ассистента и как оценивать его результат.
Буду рад обсудить в комментариях или в личке – делитесь опытом, задавайте вопросы, критикуйте.
