Как сделать ИИ-агента для QA и автотестов

Что получится в результате

Соберем ИИ-агента для QA и автотестов, который берет требования, чек-листы, страницы продукта, результаты CI, Playwright/Cypress-отчеты и превращает это в тест-кейсы, черновики автотестов, bug reports, список flaky-тестов и понятную релизную сводку.

Рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. продукты и приложения хранятся в `applications`;
3. окружения хранятся в `environments`;
4. тестовые пользователи хранятся в `test_accounts`;
5. требования хранятся в `requirement_catalog`;
6. риски фич хранятся в `risk_catalog`;
7. тест-кейсы пишутся в `test_case_catalog`;
8. стабильные локаторы пишутся в `locator_catalog`;
9. тестовые данные пишутся в `test_data_catalog`;
10. API-контракты пишутся в `api_contracts`;
11. ручные проверки пишутся в `manual_checklist`;
12. черновики автотестов пишутся в `autotest_drafts`;
13. Playwright-спеки пишутся в `playwright_specs`;
14. Cypress-спеки пишутся в `cypress_specs`;
15. очередь прогонов пишется в `test_run_queue`;
16. CI-прогоны пишутся в `ci_runs`;
17. результаты тестов пишутся в `test_results`;
18. падения пишутся в `failure_log`;
19. нестабильные тесты пишутся в `flaky_tests`;
20. баг-репорты пишутся в `bug_reports`;
21. спорные действия уходят в `approval_queue`;
22. одобренные действия попадают в `execution_queue`;
23. релизная сводка пишется в `release_report`;
24. все решения пишутся в `audit_log`;
25. ошибки интеграций пишутся в `error_log`.

В первой версии агент не исправляет продуктовый код, не удаляет проверки, не закрывает баги, не отключает тесты и не пушит изменения в репозиторий без review. Он готовит черновики, объясняет падения, группирует проблемы и создает задачи для человека.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для управляющих таблиц MVP.
• Репозиторий продукта на GitHub, GitLab или Bitbucket.
• Node.js 20 LTS или новее.
• Playwright для E2E-тестов.
• Cypress, если команда уже использует Cypress.
• Allure Report или HTML-отчеты Playwright/Cypress.
• CI: GitHub Actions, GitLab CI, Jenkins или TeamCity.
• Доступ read-only к требованиям, задачам и логам CI.
• Тестовое окружение, которое можно ломать без риска для пользователей.
• Тестовые аккаунты с понятными ролями.
• API-ключ LLM-провайдера.
• QA-инженер или разработчик, который подтверждает тест-кейсы, баги и изменения автотестов.

Шаг 1. Выберите первый QA-сценарий

Не начинайте с агента, который “тестирует весь продукт”. Для MVP выберите один сценарий.

Подходящие варианты:

1. агент превращает требования в тест-кейсы;
2. агент пишет черновики Playwright-тестов;
3. агент анализирует падения CI;
4. агент группирует flaky-тесты;
5. агент готовит bug report по скриншоту, видео и trace;
6. агент делает release QA summary;
7. агент проверяет, что критические сценарии покрыты автотестами.

Самый практичный старт: `требование -> тест-кейсы -> черновик Playwright-теста -> прогон -> анализ падения -> bug report`.

Проверка: сценарий можно руками пройти на одной фиче за 30-60 минут.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

1. менять продуктовый код;
2. пушить код автотестов в основную ветку;
3. удалять тесты;
4. пропускать проверки через `test.skip`;
5. менять assertions так, чтобы тест просто проходил;
6. отключать flaky-тест без задачи;
7. закрывать баг;
8. менять severity бага;
9. запускать тесты на production;
10. использовать реальные данные пользователей;
11. раскрывать пароли тестовых аккаунтов в отчете;
12. менять CI-конфигурацию без approval.

Разрешите агенту:

1. читать требования;
2. читать тестовые спецификации;
3. читать CI-логи;
4. читать screenshots, videos, traces и Allure-attachments;
5. создавать черновики тест-кейсов;
6. создавать черновики автотестов;
7. предлагать локаторы;
8. объяснять падения;
9. создавать bug report draft;
10. создавать задачу на стабилизацию flaky-теста.

Проверка: любое действие, которое меняет репозиторий или статус бага, должно проходить через `approval_queue`.

Шаг 3. Создайте Google Sheet

Создайте таблицу `qa_agent_mvp`.

Добавьте листы:

settings
applications
environments
test_accounts
requirement_catalog
risk_catalog
test_case_catalog
locator_catalog
test_data_catalog
api_contracts
manual_checklist
autotest_drafts
playwright_specs
cypress_specs
test_run_queue
ci_runs
test_results
failure_log
flaky_tests
bug_reports
approval_queue
execution_queue
release_report
audit_log
error_log

Проверка: названия листов должны совпадать один в один, потому что n8n будет обращаться к ним по имени.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description

Добавьте строки:

llm_model | gpt-4.1-mini | модель для анализа требований и падений
default_framework | playwright | основной фреймворк автотестов
test_base_url | https://staging.example.com | тестовое окружение
max_test_cases_per_requirement | 12 | лимит тест-кейсов на одно требование
max_autotest_drafts_per_run | 5 | лимит черновиков автотестов за один запуск
allow_repo_write | false | агент не пишет в репозиторий напрямую
allow_production_tests | false | агент не запускает тесты на production
min_failure_repeats_for_flaky | 3 | сколько повторов нужно для flaky
approval_channel | telegram | канал согласований
report_channel | email | канал релизной сводки

Проверка: `allow_repo_write=false` и `allow_production_tests=false`.

Шаг 5. Заполните applications

В `applications` добавьте колонки:

app_id
name
repo_url
default_branch
test_framework
test_path
owner
status

Пример:

APP-WEB | Customer Portal | https://github.com/company/portal | main | playwright | tests/e2e | qa-lead | active
APP-ADMIN | Admin Panel | https://github.com/company/admin | main | cypress | cypress/e2e | frontend-lead | active

Проверка: для каждого приложения есть владелец и путь к тестам.

Шаг 6. Заполните environments

В `environments` добавьте колонки:

env_id
app_id
name
base_url
data_policy
can_run_tests
requires_vpn
status

Пример:

ENV-STAGE | APP-WEB | staging | https://staging.example.com | synthetic_only | yes | no | active
ENV-PROD | APP-WEB | production | https://example.com | no_ai_tests | no | yes | blocked

Проверка: production должен иметь `can_run_tests=no`.

Шаг 7. Заполните test_accounts

В `test_accounts` добавьте колонки:

account_id
env_id
role
login
secret_ref
allowed_actions
reset_instruction
status

Пример:

ACC-BUYER | ENV-STAGE | buyer | qa-buyer@example.com | vault://qa/buyer | signup,login,checkout | reset via seed script | active
ACC-ADMIN | ENV-STAGE | admin | qa-admin@example.com | vault://qa/admin | login,moderate,refund | reset manually | restricted

Не храните пароль в Google Sheets. Храните ссылку на секрет в vault, n8n credentials или переменной окружения.

Проверка: в таблице нет настоящих паролей.

Шаг 8. Заполните requirement_catalog

В `requirement_catalog` добавьте колонки:

requirement_id
app_id
feature
user_story
acceptance_criteria
source_url
priority
risk_level
owner
status
updated_at

Пример:

REQ-CHECKOUT-001 | APP-WEB | checkout | Покупатель оформляет заказ банковской картой | заказ создан, платеж успешен, письмо отправлено | https://tracker/task/123 | high | high | product | ready

Проверка: у требования есть acceptance criteria. Если критериев нет, агент не должен писать автотест, он должен создать вопрос в `approval_queue`.

Шаг 9. Заполните risk_catalog

В `risk_catalog` добавьте колонки:

risk_id
app_id
area
risk
impact
probability
must_test
owner

Пример:

RISK-PAYMENT | APP-WEB | checkout | платеж проходит, но заказ не создается | critical | medium | yes | qa-lead
RISK-AUTH | APP-WEB | login | пользователь не может войти после релиза | high | medium | yes | frontend-lead

Проверка: для рисков `critical` и `high` агент обязан создавать хотя бы один тест-кейс.

Шаг 10. Создайте test_case_catalog

В `test_case_catalog` добавьте колонки:

test_case_id
requirement_id
app_id
title
preconditions
steps
expected_result
test_type
priority
automation_candidate
status
created_by
reviewer
updated_at

`test_type`:

smoke
regression
integration
negative
accessibility
visual
api
security

Проверка: каждый тест-кейс содержит шаги и ожидаемый результат. Пустое `expected_result` запрещено.

Шаг 11. Создайте locator_catalog

В `locator_catalog` добавьте колонки:

locator_id
app_id
page
element_name
preferred_locator
fallback_locator
bad_locator_examples
owner
status

Пример:

LOC-CHECKOUT-PAY | APP-WEB | checkout | кнопка оплаты | getByRole('button', { name: 'Оплатить' }) | [data-testid="pay-button"] | .btn:nth-child(3) | frontend | active

Правило: сначала используйте role, label, text и test id. CSS по структуре DOM используйте только как fallback.

Проверка: агент не предлагает локатор вида `.class:nth-child(4)` как основной.

Шаг 12. Создайте test_data_catalog

В `test_data_catalog` добавьте колонки:

data_id
env_id
scenario
payload_json
setup_instruction
cleanup_instruction
can_reuse
status

Пример:

DATA-CART-001 | ENV-STAGE | checkout_success | {"sku":"SKU-001","qty":1,"price":990} | run seed:cart:basic | clear cart after test | yes | active

Проверка: тестовые данные можно пересоздать, а не искать руками после каждого падения.

Шаг 13. Создайте api_contracts

В `api_contracts` добавьте колонки:

contract_id
app_id
method
path
request_example
response_example
required_fields
status_codes
owner
status

Пример:

API-ORDER-CREATE | APP-WEB | POST | /api/orders | {"sku":"SKU-001"} | {"order_id":"...","status":"created"} | order_id,status | 201,400,401,500 | backend | active

Проверка: если агент предлагает API-тест, он обязан ссылаться на `api_contracts`.

Шаг 14. Создайте manual_checklist

В `manual_checklist` добавьте проверки, которые пока не стоит автоматизировать.

Колонки:

check_id
requirement_id
app_id
title
steps
expected_result
reason_not_automated
owner
status

Пример:

MC-PAYMENT-3DS | REQ-CHECKOUT-001 | APP-WEB | Проверка 3DS-оплаты | открыть checkout, оплатить тестовой картой 3DS, подтвердить платеж | заказ создан после 3DS | зависит от внешнего платежного окна | qa-lead | active

Проверка: если сценарий зависит от внешнего сервиса, капчи, ручного звонка или нестабильного платежного окна, агент должен добавить его в `manual_checklist`, а не пытаться сделать хрупкий автотест.

Шаг 15. Установите Playwright

В репозитории приложения выполните:

npm init playwright@latest

Выберите:

1. TypeScript;
2. папку `tests/e2e`;
3. установить browsers;
4. добавить GitHub Actions, если используете GitHub.

Проверьте установку:

npx playwright test
npx playwright show-report

Проверка: локально открывается HTML-отчет Playwright.

Шаг 16. Добавьте базовую конфигурацию Playwright

В `playwright.config.ts` проверьте `baseURL`:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests/e2e',
  timeout: 30_000,
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: process.env.TEST_BASE_URL || 'https://staging.example.com',
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
});

Проверка: `TEST_BASE_URL` задается через CI secret, а не зашит в тестах.

Шаг 17. Создайте первый Playwright-тест руками

Создайте файл `tests/e2e/smoke.spec.ts`:

import { test, expect } from '@playwright/test';

test('главная страница открывается', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle(/Example/);
});

Запустите:

npx playwright test tests/e2e/smoke.spec.ts

Проверка: до подключения агента у вас есть один рабочий тест. Агент должен расширять рабочую базу, а не создавать хаос с нуля.

Шаг 18. Если нужен Cypress, установите его отдельно

Если команда уже использует Cypress, выполните:

npm install cypress --save-dev
npx cypress open

Создайте `cypress/e2e/smoke.cy.ts`:

describe('smoke', () => {
  it('opens home page', () => {
    cy.visit('/');
    cy.contains('Example').should('be.visible');
  });
});

Запуск:

npx cypress run

Проверка: используйте один основной фреймворк. Не заставляйте агента писать одновременно Playwright и Cypress для одного и того же сценария без причины.

Шаг 19. Создайте workflow в n8n

Создайте workflow `QA Agent MVP`.

Добавьте узлы:

1. `Manual Trigger`;
2. `Read settings`;
3. `Read applications`;
4. `Read environments`;
5. `Read requirement_catalog`;
6. `Read risk_catalog`;
7. `Generate test cases`;
8. `Write test_case_catalog`;
9. `Generate autotest draft`;
10. `Write autotest_drafts`;
11. `Create approval item`;
12. `Write audit_log`.

Проверка: первый запуск должен работать на одном `requirement_id`, а не на всех требованиях сразу.

Шаг 20. Настройте prompt для генерации тест-кейсов

В LLM-узле используйте prompt:

Ты QA-инженер. Твоя задача - превратить требование в проверяемые тест-кейсы.

Правила:
1. Не придумывай бизнес-логику, которой нет в requirement.
2. Если acceptance criteria неполные, верни status=needs_clarification.
3. Для high и critical риска добавь negative и regression проверки.
4. Каждый test case должен иметь preconditions, steps, expected_result.
5. Не создавай автотесты на сценарии, где нет стабильных локаторов.
6. Не используй персональные данные.

Вход:
requirement:
{{$json.requirement}}

risks:
{{$json.risks}}

locators:
{{$json.locators}}

Верни JSON:
{
  "status": "ok | needs_clarification",
  "questions": [],
  "test_cases": [
    {
      "title": "...",
      "preconditions": "...",
      "steps": ["..."],
      "expected_result": "...",
      "test_type": "smoke | regression | negative | api | accessibility",
      "priority": "critical | high | medium | low",
      "automation_candidate": "yes | no",
      "reason": "..."
    }
  ]
}

Проверка: если `status=needs_clarification`, запись идет в `approval_queue`, а не в `test_case_catalog`.

Шаг 21. Записывайте тест-кейсы в test_case_catalog

После LLM-узла добавьте Code-узел, который присваивает ID:

return items[0].json.test_cases.map((testCase, index) => ({
  json: {
    test_case_id: `TC-${Date.now()}-${index + 1}`,
    requirement_id: items[0].json.requirement.requirement_id,
    app_id: items[0].json.requirement.app_id,
    title: testCase.title,
    preconditions: testCase.preconditions,
    steps: testCase.steps.join('\n'),
    expected_result: testCase.expected_result,
    test_type: testCase.test_type,
    priority: testCase.priority,
    automation_candidate: testCase.automation_candidate,
    status: 'draft',
    created_by: 'ai_agent',
    reviewer: items[0].json.requirement.owner,
    updated_at: new Date().toISOString(),
  },
}));

Проверка: все новые тест-кейсы имеют `status=draft`, а не `approved`.

Шаг 22. Настройте prompt для автотеста

Второй LLM-узел должен получать только утвержденные тест-кейсы.

Prompt:

Ты senior QA automation engineer.

Напиши черновик Playwright-теста на TypeScript.

Правила:
1. Используй только baseURL из конфигурации.
2. Используй устойчивые локаторы из locator_catalog.
3. Не используй sleep/timeouts без причины.
4. Не проверяй внутреннюю верстку, если можно проверить пользовательское поведение.
5. Не добавляй test.skip.
6. Не меняй продуктовый код.
7. Если локаторов не хватает, верни status=needs_locator.

Вход:
test_case:
{{$json.test_case}}

locators:
{{$json.locators}}

test_data:
{{$json.test_data}}

Верни JSON:
{
  "status": "ok | needs_locator | needs_data",
  "file_path": "tests/e2e/...",
  "code": "...",
  "notes": [],
  "required_locators": []
}

Проверка: агент возвращает код как черновик, а не пишет файл напрямую.

Шаг 23. Записывайте черновики в autotest_drafts

В `autotest_drafts` добавьте колонки:

draft_id
test_case_id
app_id
framework
file_path
code
status
reviewer
created_at
review_comment

Статусы:

draft
needs_locator
needs_data
approved
rejected
merged

Проверка: `code` хранится как черновик, а человек переносит его в репозиторий или approving workflow делает pull request.

Шаг 24. Создайте playwright_specs

В `playwright_specs` добавьте колонки:

spec_id
app_id
test_case_id
file_path
test_title
owner
status
last_run_at
last_result

Записывайте сюда только тесты, которые уже лежат в репозитории.

Проверка: `autotest_drafts` и `playwright_specs` не одно и то же. Первый лист для черновиков, второй для реальных тестов.

Шаг 25. Создайте cypress_specs

Если Cypress не используется, оставьте лист пустым.

Колонки:

spec_id
app_id
test_case_id
file_path
test_title
owner
status
last_run_at
last_result

Проверка: агент не создает Cypress-спеки, если `default_framework=playwright`.

Шаг 26. Создайте test_run_queue

В `test_run_queue` добавьте колонки:

run_request_id
app_id
env_id
framework
scope
command
requested_by
status
created_at
started_at
finished_at

Пример:

RUN-001 | APP-WEB | ENV-STAGE | playwright | smoke | npx playwright test --grep @smoke | qa-agent | pending | 2026-05-23T10:00:00Z | |

Проверка: команда запуска не содержит production URL.

Шаг 27. Подключите CI

Для GitHub Actions создайте `.github/workflows/e2e.yml`:

name: e2e

on:
  workflow_dispatch:
  pull_request:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
        env:
          TEST_BASE_URL: ${{ secrets.TEST_BASE_URL }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

Проверка: отчет сохраняется даже при падении тестов.

Шаг 28. Записывайте ci_runs

В `ci_runs` добавьте колонки:

ci_run_id
run_request_id
app_id
branch
commit_sha
workflow_url
status
started_at
finished_at
report_url

Статусы:

queued
running
passed
failed
cancelled
infra_failed

Проверка: `infra_failed` отделен от обычного `failed`, чтобы агент не создавал продуктовый баг из сбоя окружения.

Шаг 29. Записывайте test_results

В `test_results` добавьте колонки:

result_id
ci_run_id
spec_id
test_title
status
duration_ms
retry_count
browser
error_message
trace_url
screenshot_url
video_url
created_at

Статусы:

passed
failed
skipped
timed_out
flaky_passed_on_retry

Проверка: у падения есть хотя бы `error_message` или ссылка на trace/screenshot/video.

Шаг 30. Создайте failure_log

В `failure_log` добавьте колонки:

failure_id
result_id
app_id
failure_type
summary
evidence
suspected_area
confidence
needs_human_review
created_at

`failure_type`:

product_bug
test_bug
locator_changed
test_data_issue
environment_issue
timeout
network_issue
unknown

Проверка: если confidence ниже `medium`, агент не создает баг, а отправляет запись на review.

Шаг 31. Настройте prompt для анализа падений

Prompt:

Ты QA automation engineer. Проанализируй падение автотеста.

Правила:
1. Не называй падение багом продукта без доказательств.
2. Разделяй product_bug, test_bug, test_data_issue, environment_issue и unknown.
3. Используй error_message, screenshot, trace, video и историю повторов.
4. Если причина неясна, верни failure_type=unknown.
5. Не предлагай удалить assertion.
6. Не предлагай test.skip как исправление.

Вход:
test_result:
{{$json.test_result}}

recent_failures:
{{$json.recent_failures}}

locator_catalog:
{{$json.locator_catalog}}

Верни JSON:
{
  "failure_type": "product_bug | test_bug | locator_changed | test_data_issue | environment_issue | timeout | network_issue | unknown",
  "summary": "...",
  "evidence": ["..."],
  "suspected_area": "...",
  "confidence": "high | medium | low",
  "recommended_next_step": "...",
  "create_bug_report": true
}

Проверка: `create_bug_report=true` допустим только при `confidence=high` или после approval.

Шаг 32. Создайте flaky_tests

В `flaky_tests` добавьте колонки:

flaky_id
spec_id
test_title
app_id
failure_count_14d
pass_after_retry_count_14d
suspected_reason
evidence
owner
status
created_at

`suspected_reason`:

unstable_locator
async_race
test_data_conflict
environment_latency
third_party_dependency
bad_waiting_strategy
unknown

Проверка: flaky-тест не удаляется. Он получает задачу на стабилизацию.

Шаг 33. Создайте bug_reports

В `bug_reports` добавьте колонки:

bug_id
failure_id
app_id
title
steps_to_reproduce
actual_result
expected_result
evidence_links
severity
priority
status
assignee
created_at
tracker_url

Шаблон bug report:

Title: Checkout: заказ не создается после успешной оплаты

Steps:
1. Открыть staging.
2. Войти под buyer account.
3. Добавить SKU-001 в корзину.
4. Нажать "Оплатить".

Expected:
Заказ создан, статус payment_success, пользователь видит страницу успеха.

Actual:
После оплаты пользователь остается на checkout, в trace видно 500 на POST /api/orders.

Evidence:
trace_url, screenshot_url, ci_run_url.

Проверка: bug report содержит шаги, expected, actual и evidence. Без evidence баг остается draft.

Шаг 34. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
action_type
action_text
risk_level
payload_json
approver
status
requested_at
approved_at
decision_comment

В approval отправляйте:

1. запись файла автотеста в репозиторий;
2. создание pull request;
3. изменение CI;
4. отключение теста;
5. изменение severity бага;
6. создание бага без полной уверенности;
7. запуск тестов на чувствительном окружении;
8. массовый прогон регресса.

Проверка: `approval_queue.status` не может сразу быть `approved`.

Шаг 35. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
action_type
payload_json
status
executor
started_at
finished_at
result_url
error_message

Статусы:

pending
running
done
failed
cancelled

В первой версии оставьте `executor=manual`. Это значит, что человек сам делает PR, запускает регресс или создает баг в трекере.

Проверка: агент не выполняет approved action автоматически, пока вы специально не включили executor.

Шаг 36. Сделайте Telegram approval

В n8n добавьте Telegram-узел после записи в `approval_queue`.

Сообщение:

QA Agent approval

Action: {{$json.action_type}}
Risk: {{$json.risk_level}}
Source: {{$json.source}} {{$json.source_id}}

{{$json.action_text}}

Approve: /approve {{$json.approval_id}}
Reject: /reject {{$json.approval_id}}

Проверка: команда `/approve` меняет только одну строку по `approval_id`.

Шаг 37. Создайте release_report

В `release_report` добавьте колонки:

report_id
app_id
release_id
period
summary
passed_count
failed_count
flaky_count
open_bug_count
critical_risks
recommendation
status
created_at

Пример summary:

Release REL-2026-05-23 готов к ограниченному выкатыванию. Smoke passed 18/18, regression failed 2/74. Оба падения относятся к test_data_issue, product_bug не подтвержден. Flaky: 3 теста, один критичный checkout test требует стабилизации до полного выкатывания.

Проверка: recommendation не должна быть только “все хорошо”. В ней должны быть ограничения и риски.

Шаг 38. Настройте audit_log

В `audit_log` добавьте колонки:

audit_id
run_id
actor
action
entity_type
entity_id
before_json
after_json
reason
created_at

Логируйте:

1. генерацию тест-кейса;
2. генерацию черновика автотеста;
3. анализ падения;
4. создание bug report draft;
5. отправку в approval;
6. решение approval;
7. создание release report.

Проверка: по `audit_log` можно восстановить, почему агент предложил конкретный баг или автотест.

Шаг 39. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
node_name
error_type
message
payload_sample
retry_count
status
created_at

Типы ошибок:

missing_requirement
invalid_acceptance_criteria
missing_locator
missing_test_data
ci_api_error
report_parse_error
llm_json_error
permission_denied

Проверка: если LLM вернула невалидный JSON, workflow не должен молча продолжаться.

Шаг 40. Протестируйте на одном требовании

Добавьте в `requirement_catalog` строку:

REQ-LOGIN-001 | APP-WEB | login | Пользователь входит по email и паролю | успешный вход ведет в личный кабинет, неверный пароль показывает ошибку | https://tracker/task/login | high | high | qa-lead | ready | 2026-05-23

Заполните `locator_catalog`:

LOC-EMAIL | APP-WEB | login | поле email | getByLabel('Email') | [data-testid="login-email"] | input:nth-child(1) | frontend | active
LOC-PASSWORD | APP-WEB | login | поле пароля | getByLabel('Пароль') | [data-testid="login-password"] | input:nth-child(2) | frontend | active
LOC-SUBMIT | APP-WEB | login | кнопка входа | getByRole('button', { name: 'Войти' }) | [data-testid="login-submit"] | .button.primary | frontend | active

Запустите workflow только для `REQ-LOGIN-001`.

Ожидаемый результат:

1. в `test_case_catalog` появилось 3-6 тест-кейсов;
2. тест-кейсы имеют `status=draft`;
3. один тест-кейс помечен `automation_candidate=yes`;
4. в `autotest_drafts` появился Playwright-код;
5. в `approval_queue` появилась запись на review автотеста;
6. в `audit_log` есть все шаги;
7. в `error_log` нет ошибок.

Шаг 41. Проверьте негативные сценарии

Проведите проверки:

1. удалите `acceptance_criteria` из требования;
2. запустите workflow;
3. убедитесь, что агент вернул `needs_clarification`;
4. удалите локатор кнопки входа;
5. убедитесь, что автотест получил `needs_locator`;
6. подставьте production URL;
7. убедитесь, что запуск заблокирован;
8. загрузите CI-лог без screenshot и trace;
9. убедитесь, что bug report не создан автоматически;
10. добавьте одно и то же падение 3 раза;
11. убедитесь, что появилась запись в `flaky_tests`;
12. проверьте, что агент не предложил `test.skip`.

Проверка: негативные сценарии важнее красивого happy path. Они показывают, что агент не будет портить тесты ради зеленого CI.

Что нельзя автоматизировать в первой версии

Не автоматизируйте сразу:

1. прямую запись автотестов в main branch;
2. автоудаление тестов;
3. автоизменение assertions;
4. автоотключение flaky-тестов;
5. принятие решения “релиз можно выкатывать” без QA;
6. создание багов в трекере без evidence;
7. запуск тестов на production;
8. работу с реальными персональными данными;
9. изменение CI secrets;
10. массовую генерацию сотен тестов без review.

Минимальный хороший MVP: агент генерирует тест-кейсы, делает один черновик Playwright-теста, анализирует один CI-прогон, создает bug report draft и релизную сводку. Все опасные действия подтверждает человек.

Частые вопросы

Может ли агент сам писать автотесты?

Да, но в первой версии только как черновики в `autotest_drafts`. Код должен проверить QA automation engineer или разработчик. Автоматическая запись в репозиторий допустима только после approval и лучше через pull request.

Что выбрать: Playwright или Cypress?

Если проекта еще нет, чаще проще начать с Playwright: он хорошо работает с несколькими браузерами, traces, screenshots и CI. Если команда уже использует Cypress и набор тестов живой, не мигрируйте ради агента. Подключите агента к текущему стеку.

Почему агент не должен удалять flaky-тесты?

Flaky-тест может показывать реальную нестабильность продукта, данных или окружения. Если агент просто удалит тест, команда потеряет сигнал. Правильный путь: записать проблему в `flaky_tests`, собрать evidence и создать задачу на стабилизацию.

Какие данные нужны для первого запуска?

Достаточно одного требования, одного тестового окружения, одного тестового аккаунта, 3-5 локаторов, одного тестового набора данных и одного базового Playwright-теста. Не надо сначала описывать весь продукт.

Что считать готовым результатом MVP?

MVP готов, если по одному требованию агент создает тест-кейсы, генерирует черновик автотеста, не пишет в репозиторий без approval, умеет разобрать падение CI, создает bug report draft с evidence и оставляет понятный `audit_log`.