Back to Details

qa-report

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Real-User QA Planner

真实用户QA规划工具

Plan and document the deliverables that drive real-user QA execution — personas, journey maps, exploratory charters, persona/journey/tour test cases, regression suites, Figma fidelity validations, and user-impact bug reports.
规划并记录驱动真实用户QA执行的交付物——personas（用户角色）、journey maps（旅程图）、探索性测试章程、基于角色/旅程/引导流程的测试用例、回归测试套件、Figma还原度验证，以及用户影响型Bug报告。

Required Reading Router

必读文档指引

Match your task to the row. Read the listed files in full before producing the deliverable. They are not appendices — they are the templates and contracts the deliverable must conform to. Inline content in this SKILL.md is a pointer, not a substitute.
TaskMUST read
Defining personas (Step 3 — persona deliverable)
references/persona_test_cases.md
+ 
../qa-execution/references/user-personas.md
Mapping a journey (Step 3 — journey deliverable)
references/journey_test_plans.md
+ 
../qa-execution/references/journey-maps.md
Writing an exploratory charter (Step 3)
references/exploratory_charters.md
+ 
../qa-execution/references/exploratory-charters.md
Planning a tour-driven test case (Step 4)
references/test_tours_catalog.md
+ 
../qa-execution/references/test-tours.md
Generating standard / functional / UI test cases
references/test_case_templates.md
Generating CFR test cases (Step 4)
references/cfr_test_cases.md
+ 
../qa-execution/references/cfr-checks.md
Building a regression suite (Step 5)
references/regression_testing.md
Validating against Figma (Step 6)
references/figma_validation.md
Filing a bug report (Step 7)
references/bug_report_templates.md
+ 
assets/issue-template.md
+ 
../qa-execution/references/bug-severity-by-user-impact.md
将你的任务与对应行匹配。在生成交付物前完整阅读列出的文件，这些文件不是附录——它们是交付物必须遵循的模板和规范。本SKILL.md中的内联内容仅为指引，不能替代必读文档。
任务必读文档
定义用户角色（步骤3——角色交付物）
references/persona_test_cases.md
+ 
../qa-execution/references/user-personas.md
绘制旅程图（步骤3——旅程交付物）
references/journey_test_plans.md
+ 
../qa-execution/references/journey-maps.md
编写探索性测试章程（步骤3）
references/exploratory_charters.md
+ 
../qa-execution/references/exploratory-charters.md
规划基于引导流程的测试用例（步骤4）
references/test_tours_catalog.md
+ 
../qa-execution/references/test-tours.md
生成标准/功能/UI测试用例
references/test_case_templates.md
生成CFR测试用例（步骤4）
references/cfr_test_cases.md
+ 
../qa-execution/references/cfr-checks.md
构建回归测试套件（步骤5）
references/regression_testing.md
基于Figma验证（步骤6）
references/figma_validation.md
提交Bug报告（步骤7）
references/bug_report_templates.md
+ 
assets/issue-template.md
+ 
../qa-execution/references/bug-severity-by-user-impact.md

Reference Index

参考文档索引

  • references/test_case_templates.md
    — Test case variants for real-user QA: Standard, Functional, UI/Visual, Regression, Smoke, Persona, Journey, Charter, Tour, CFR. The Automation Metadata block parsed by 
    qa-execution
    .
  • references/persona_test_cases.md
    — TC-PERSONA-* template and persona attributes recording schema.
  • references/journey_test_plans.md
    — TC-JOURNEY-* template and journey-driven plan structure.
  • references/exploratory_charters.md
    — Charter planning template plus worked examples for common product surfaces.
  • references/test_tours_catalog.md
    — Planning view of the test tour catalog. Each tour generates one TC-TOUR-*. Canonical tour definitions live in 
    ../qa-execution/references/test-tours.md
    (avoid drift).
  • references/cfr_test_cases.md
    — TC-CFR-* template for usability / accessibility / perf-perception / compatibility / recoverability test cases.
  • references/regression_testing.md
    — Journey-driven regression suite tiers (Smoke / Targeted / Full / Sanity), prioritization, automation tagging, pass/fail criteria.
  • references/figma_validation.md
    — Figma MCP queries, spec → inspect → document workflow, responsive checks at 1280 / 768 / 375.
  • references/bug_report_templates.md
    — Standard, UI/Visual, and User-Friction bug variants with full required-field sets. 
    assets/issue-template.md
    is the minimum-viable subset bundled for in-skill use and shared with 
    qa-execution
    .
  • references/test_case_templates.md
    — 真实用户QA的测试用例变体：标准、功能、UI/视觉、回归、冒烟、角色、旅程、章程、引导流程、CFR。qa-execution会解析其中的自动化元数据块。
  • references/persona_test_cases.md
    — TC-PERSONA-*模板及用户角色属性记录规范。
  • references/journey_test_plans.md
    — TC-JOURNEY-*模板及基于旅程的测试计划结构。
  • references/exploratory_charters.md
    — 探索性测试章程规划模板及常见产品场景的示例。
  • references/test_tours_catalog.md
    — 测试引导流程目录的规划视图。每个引导流程生成一个TC-TOUR-*。标准引导流程定义位于
    ../qa-execution/references/test-tours.md
    （避免内容不一致）。
  • references/cfr_test_cases.md
    — TC-CFR-*模板，用于可用性/可访问性/性能感知/兼容性/可恢复性测试用例。
  • references/regression_testing.md
    — 基于旅程的回归测试套件层级（冒烟/定向/完整/ sanity）、优先级划分、自动化标记、通过/失败标准。
  • references/figma_validation.md
    — Figma MCP查询、规范→检查→记录流程，以及在1280/768/375分辨率下的响应式检查。
  • references/bug_report_templates.md
    — 标准、UI/视觉、用户摩擦类Bug的变体模板及必填字段集合。
    assets/issue-template.md
    是精简版模板，供本工具使用并与qa-execution共享。

Required Inputs

必填输入项

  • qa-output-path (optional): Directory where all QA artifacts are stored. When provided, create the directory if it does not exist. When omitted, use the current working directory. This path must match the same argument passed to 
    qa-execution
    when both skills are used together.
  • qa-output-path（可选）：存储所有QA产物的目录。若提供该路径，目录不存在时将自动创建；若未提供，则使用当前工作目录。当同时使用本工具和qa-execution时，该路径必须与传入qa-execution的参数一致。

Shared Output Structure

共享输出结构

All artifacts follow this directory layout, shared with 
qa-execution
:
<qa-output-path>/qa/
├── test-plans/          # Test plan documents (journey plans, regression suites, persona docs)
│   └── charters/        # Charter drafts (CH-NN-*.md)
├── test-cases/          # Individual test case files (TC-*.md)
├── issues/              # Bug reports (BUG-*.md)
├── screenshots/         # Visual evidence and Figma comparisons
└── verification-report.md  # Generated by qa-execution
所有产物遵循以下目录结构，与qa-execution共享：
<qa-output-path>/qa/
├── test-plans/          # 测试计划文档（旅程计划、回归套件、角色文档）
│   └── charters/        # 测试章程草稿（CH-NN-*.md）
├── test-cases/          # 单个测试用例文件（TC-*.md）
├── issues/              # Bug报告（BUG-*.md）
├── screenshots/         # 视觉证据及Figma对比图
└── verification-report.md  # 由qa-execution生成

Procedures

流程步骤

Step 1: Resolve Output Directory
  1. If the user provided a 
    qa-output-path
    argument, use that path.
  2. Otherwise, default to the current working directory.
  3. Create the 
    qa/
    subdirectory under the resolved path, then 
    qa/test-plans/
    , 
    qa/test-plans/charters/
    , 
    qa/test-cases/
    , 
    qa/issues/
    , 
    qa/screenshots/
    .
Step 2: Identify the Deliverable Type
Parse the user request to determine which deliverable to generate:
Request PatternDeliverableOutput Path
"Define personas for…"Persona document
test-plans/personas.md
"Map the journey for…"Journey map
test-plans/<journey-slug>-map.md
"Plan exploratory session for…"Charter draft
test-plans/charters/CH-<NN>-<slug>.md
"Create test plan for…"Test Plan (journey-centric)
test-plans/<feature-slug>-test-plan.md
"Generate test cases for…"Test cases (TC-FUNC / TC-UI / TC-REG / SMOKE / TC-PERSONA / TC-JOURNEY / TC-TOUR / TC-CFR)
test-cases/
"Build regression suite…"Journey-driven regression suite
test-plans/<suite-name>-regression.md
"Compare with Figma…"Figma fidelity TC
test-cases/TC-UI-*.md
"Document bug…"Bug report (user-impact framing)
issues/BUG-*.md
Step 3: Generate Test Plans (Journey-Centric)
  1. STOP. Read 
    references/journey_test_plans.md
    in full before drafting the plan.     That file owns the section structure, the Automation Metadata block, and the entry/exit criteria framed by user impact.
  2. Generate a test plan document with these mandatory sections:
    • Executive summary with the user value the change delivers and the journey-level risks.
    • Personas covered (cite each from 
      ../qa-execution/references/user-personas.md
      ).
    • Journeys mapped (cite each from 
      ../qa-execution/references/journey-maps.md
      ; include abandonment paths).
    • Charters planned (mission + persona + tour + time-box for each).
    • CFR scope (which of the six CFR categories the change affects).
    • Test strategy and approach.
    • Automation strategy — which journeys should become E2E, which remain manual-only, which are blocked.
    • Entry criteria (all must hold before execution begins):
      • Build is reachable in a production-parity environment.
      • CI gate has run separately and is green (this skill does not run it — see 
        agent-output-audit
        ).
      • Test data and fixture state matches journey preconditions.
      • Personas, journeys, and charters are documented.
    • Exit criteria (all must hold before execution concludes):
      • Every P0 journey reached its goal observable.
      • Zero open 
        Blocks-Completion
        or 
        Data-Loss
        bugs on P0 journeys.
      • CFR pass completed on at least 2 journeys with no critical findings open.
      • Automation follow-up registered for every 
        Missing
        or 
        Blocked
        automation annotation.
    • Retesting vs Regression distinction:
      • Retesting — re-validates the fix of a specific reported defect. Scope is the BUG and its narrow reproduction.
      • Regression — validates that a change did not break unrelated journeys. Scope is the journey-driven suite.
    • Risk assessment table (Risk, Probability, User-Impact, Mitigation).
    • Timeline and deliverables.
  3. Write the plan to 
    <qa-output-path>/qa/test-plans/<feature-slug>-test-plan.md
    .
Step 4: Generate Test Cases
  1. STOP. Read 
    references/test_case_templates.md
    in full before writing any test case.     Variant selection (Functional / UI / Regression / Smoke / Persona / Journey / Charter / Tour / CFR) and per-variant required fields live there.
  2. Assign each test case an ID following the naming scheme:
    TypePrefixExample
    FunctionalTC-FUNC-TC-FUNC-001
    UI/VisualTC-UI-TC-UI-045
    RegressionTC-REG-TC-REG-089
    SmokeSMOKE-SMOKE-001
    Persona-drivenTC-PERSONA-TC-PERSONA-012
    Journey-drivenTC-JOURNEY-TC-JOURNEY-007
    Charter (planning artifact)TC-CHARTER-TC-CHARTER-003
    Tour-driven (off-script)TC-TOUR-TC-TOUR-014
    CFR (usability / a11y / perf-perception / compat / recovery)TC-CFR-TC-CFR-008
  3. Each test case must include:
    • Priority: P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low).
    • Persona: the user role acting (
      ../qa-execution/references/user-personas.md
      ).
    • Objective: what is being validated, from the user's perspective.
    • Preconditions: setup requirements, test data, environment.
    • Real-User Conditions: network profile, device, browser, locale, timezone, autofill state. (Replaces the technical 
      External Dependencies
      field.)
    • Test Steps: numbered actions in user-language with an 
      **Expected:**
      observable for each.
    • Edge Cases: boundary user behaviors (not technical edge cases — see 
      ../qa-execution/references/user-edge-cases.md
      ).
    • Automation Target: 
      E2E
      | 
      Manual-only
      .
    • Automation Status: 
      Existing
      | 
      Missing
      | 
      Blocked
      | 
      N/A
      .
    • Automation Command/Spec: existing spec path or command when known.
    • Automation Notes: why the case should be automated, remain manual, or is blocked.
  4. Write each test case to 
    <qa-output-path>/qa/test-cases/<TC-ID>.md
    .
  5. When generating test cases interactively, execute 
    scripts/generate_test_cases.sh <qa-output-path>/test-cases
    .
Step 5: Build Journey-Driven Regression Suites
  1. STOP. Read 
    references/regression_testing.md
    in full before classifying tiers, prioritizing, or defining pass/fail criteria.     Tier definitions, prioritization rubric, automation-tagging rules, execution-order contract, and 
    PASS
    / 
    FAIL
    / 
    CONDITIONAL
    thresholds live there.
  2. Suite tiers are journey-driven, not test-case-driven. Each tier picks N journeys, then derives the test cases from those journeys:
    SuiteDurationFrequencyJourney count
    Smoke15-30 minDaily/per-build2-4 P0 journeys
    Targeted30-60 minPer changeJourneys touching the changed surface
    Full2-4 hoursWeekly/ReleaseAll P0 + P1 journeys, every persona
    Sanity10-15 minAfter hotfixThe single journey affected by the hotfix
  3. Prioritize journeys using the user-impact lens:
    • P0: journeys whose failure causes 
      Blocks-Completion
      or 
      Data-Loss
      for paying users.
    • P1: journeys whose failure causes 
      Trust-Damage
      or repeated 
      Friction
      for any persona.
    • P2: secondary journeys, edge personas, lower-traffic surfaces.
  4. Mark automation candidates explicitly:
    • Tag changed or regression-critical P0/P1 public journeys as 
      Automation Target: E2E
      when the repository already has an E2E harness.
    • Tag bug-driven public regressions as 
      Automation Status: Missing
      until 
      qa-execution
      confirms the spec was added or updated.
    • Tag exploratory, visual-judgment, or unsupported flows as 
      Manual-only
      or 
      Blocked
      with a reason.
  5. Define execution order: Smoke first (fail-fast) → P0 journeys → P1 journeys → P2 journeys → exploratory charters.
  6. Define pass/fail criteria framed by user impact:
    • PASS: every P0 journey reaches its goal; zero 
      Blocks-Completion
      / 
      Data-Loss
      open.
    • FAIL: any P0 journey fails to reach goal; any 
      Blocks-Completion
      or 
      Data-Loss
      discovered.
    • CONDITIONAL: P1 journeys with documented workarounds; 
      Friction
      / 
      Trust-Damage
      findings with fix plan in place.
  7. Write the suite document to 
    <qa-output-path>/qa/test-plans/<suite-name>-regression.md
    .
Step 6: Validate Against Figma Designs
Skip this step if Figma MCP is not configured.
  1. STOP. Read 
    references/figma_validation.md
    in full before issuing any Figma MCP query.     Spec→inspect→document workflow, MCP query catalog, responsive checks at 1280/768/375, common-discrepancies catalog.
  2. Extract design specifications from Figma using MCP queries: dimensions, colors (exact hex), typography, spacing, border radius/shadows, interactive states.
  3. Generate UI test cases (TC-UI-*) that compare each property against the implementation.
  4. Test responsive behavior at the standard viewports: 375 / 768 / 1280.
  5. When validation reveals discrepancies, generate a bug report following Step 7. Most Figma-fidelity gaps are 
    Cosmetic
    or 
    Trust-Damage
    — promote to 
    Friction
    only when the gap blocks comprehension.
  6. Use 
    agent-browser
    (the 
    qa-execution
    companion skill) when browser-based verification is needed.
Step 7: Create Bug Reports
  1. STOP. Read 
    references/bug_report_templates.md
    in full before filing any bug.     Standard, UI/Visual, and User-Friction variants with required-field sets. 
    assets/issue-template.md
    is the minimum-viable shared subset.
  2. STOP. Read 
    ../qa-execution/references/bug-severity-by-user-impact.md
    in full before classifying impact.     The five-tier user-impact rubric (Blocks-Completion / Data-Loss / Trust-Damage / Friction / Cosmetic) and the mapping to legacy Severity/Priority live there.
  3. Assign a bug ID with the 
    BUG-
    prefix (e.g., 
    BUG-001
    ).
  4. Every bug report must include:
    • Impact (user-side): Blocks-Completion | Data-Loss | Trust-Damage | Friction | Cosmetic.
    • Severity: Critical | High | Medium | Low (mapped from impact).
    • Priority: P0 | P1 | P2 | P3 (mapped from impact).
    • Status: 
      pending
      | 
      resolved
      | 
      invalid
      .
    • Persona Affected: the persona whose session surfaced the bug.
    • Journey Step: J-NN journey name + step number.
    • Environment: build, OS, browser, viewport, network, locale, URL.
    • Reproduction: charter (CH-NN), tour name, plain-language steps.
    • Expected vs Actual: clear user-side descriptions.
    • Impact: users affected, frequency, workaround, trust cost.
    • Related: TC-ID if discovered during a test case, Figma URL if UI bug, related journeys/charters.
  5. Write each bug report to 
    <qa-output-path>/qa/issues/<BUG-ID>.md
    .
  6. When creating bug reports interactively, execute 
    scripts/create_bug_report.sh <qa-output-path>/issues
    .
Step 8: Validate Completeness
  1. Verify every test case has an expected user-observable result for each step.
  2. Verify every bug report has reproducible user-language steps.
  3. Verify traceability: test cases cite the persona and journey; bugs cite the test case and charter when applicable.
  4. Verify every persona has at least one test case.
  5. Verify every journey has at least one test case.
  6. Verify every CFR category planned for the change has at least one TC-CFR-*.
  7. Verify every planned critical flow has an explicit automation annotation and that 
    Missing
    or 
    Blocked
    states include a reason.
  8. Cross-reference against 
    ../qa-execution/references/checklist.md
    for coverage gaps before handing off to execution.
步骤1：确定输出目录
  1. 若用户提供了
    qa-output-path
    参数，则使用该路径。
  2. 否则，默认使用当前工作目录。
  3. 在确定的路径下创建
    qa/
    子目录，然后依次创建
    qa/test-plans/
    、
    qa/test-plans/charters/
    、
    qa/test-cases/
    、
    qa/issues/
    、
    qa/screenshots/
    。
步骤2：识别交付物类型
解析用户请求，确定要生成的交付物类型：
请求模式交付物输出路径
"为……定义用户角色"用户角色文档
test-plans/personas.md
"为……绘制旅程图"旅程图
test-plans/<journey-slug>-map.md
"为……规划探索性测试会话"测试章程草稿
test-plans/charters/CH-<NN>-<slug>.md
"为……创建测试计划"测试计划（以旅程为核心）
test-plans/<feature-slug>-test-plan.md
"为……生成测试用例"测试用例（TC-FUNC / TC-UI / TC-REG / SMOKE / TC-PERSONA / TC-JOURNEY / TC-TOUR / TC-CFR）
test-cases/
"构建回归测试套件……"基于旅程的回归测试套件
test-plans/<suite-name>-regression.md
"与Figma对比……"Figma还原度测试用例
test-cases/TC-UI-*.md
"记录Bug……"Bug报告（以用户影响为框架）
issues/BUG-*.md
步骤3：生成测试计划（以旅程为核心）
  1. 暂停。在起草计划前完整阅读
    references/journey_test_plans.md
    。     该文件定义了章节结构、自动化元数据块，以及基于用户影响的进入/退出标准。
  2. 生成包含以下必填章节的测试计划文档：
    • 执行摘要：说明变更带来的用户价值及旅程层面的风险。
    • 覆盖的用户角色（引用
      ../qa-execution/references/user-personas.md
      中的内容）。
    • 绘制的旅程图（引用
      ../qa-execution/references/journey-maps.md
      中的内容；包含用户放弃路径）。
    • 规划的测试章程（每个章程的任务目标+用户角色+引导流程+时间限制）。
    • CFR范围（变更影响的CFR类别）。
    • 测试策略与方法。
    • 自动化策略——哪些旅程应转为E2E自动化，哪些保留手动测试，哪些被阻塞。
    • 进入标准（执行开始前必须满足所有条件）：
      • 在生产级环境中可访问构建版本。
      • CI gate已单独运行且结果为绿色（本工具不执行CI gate——请使用
        agent-output-audit
        ）。
      • 测试数据和前置环境状态与旅程前置条件匹配。
      • 用户角色、旅程图和测试章程已完成文档记录。
    • 退出标准（执行结束前必须满足所有条件）：
      • 每个P0旅程都达成了可观测的目标。
      • P0旅程中不存在
        Blocks-Completion
        或
        Data-Loss
        类型的未解决Bug。
      • 至少在2个旅程上完成CFR测试且无未解决的关键问题。
      • 每个标记为
        Missing
        或
        Blocked
        的自动化项都已登记后续跟进任务。
    • 回归测试与重测的区别：
      • 重测——重新验证特定已报告缺陷的修复效果。范围仅限于该Bug及其窄范围复现场景。
      • 回归测试——验证变更未破坏无关旅程。范围为基于旅程的测试套件。
    • 风险评估表（风险、概率、用户影响、缓解措施）。
    • 时间线和交付物清单。
  3. 将计划写入
    <qa-output-path>/qa/test-plans/<feature-slug>-test-plan.md
    。
步骤4：生成测试用例
  1. 暂停。在编写任何测试用例前完整阅读
    references/test_case_templates.md
    。     该文件定义了测试用例变体选择（功能/UI/回归/冒烟/角色/旅程/章程/引导流程/CFR）及各变体的必填字段。
  2. 按照以下命名规则为每个测试用例分配ID：
    类型前缀示例
    功能测试TC-FUNC-TC-FUNC-001
    UI/视觉测试TC-UI-TC-UI-045
    回归测试TC-REG-TC-REG-089
    冒烟测试SMOKE-SMOKE-001
    基于用户角色的测试TC-PERSONA-TC-PERSONA-012
    基于旅程的测试TC-JOURNEY-TC-JOURNEY-007
    测试章程（规划产物）TC-CHARTER-TC-CHARTER-003
    基于引导流程的测试（非脚本化）TC-TOUR-TC-TOUR-014
    CFR测试（可用性/可访问性/性能感知/兼容性/可恢复性）TC-CFR-TC-CFR-008
  3. 每个测试用例必须包含：
    • 优先级: P0（关键）| P1（高）| P2（中）| P3（低）。
    • 用户角色: 执行操作的用户角色（来自
      ../qa-execution/references/user-personas.md
      ）。
    • 目标: 从用户视角出发，说明要验证的内容。
    • 前置条件: 环境设置要求、测试数据、运行环境。
    • 真实用户条件: 网络配置、设备、浏览器、区域设置、时区、自动填充状态。（替代技术层面的
      外部依赖
      字段。）
    • 测试步骤: 以用户语言描述的编号操作，每个步骤对应
      **预期结果:**
      可观测内容。
    • 边缘场景: 用户行为边界（非技术边缘场景——请参考
      ../qa-execution/references/user-edge-cases.md
      ）。
    • 自动化目标: 
      E2E
      | 
      仅手动
      。
    • 自动化状态: 
      已存在
      | 
      缺失
      | 
      阻塞
      | 
      不适用
      。
    • 自动化命令/规范: 已知的现有规范路径或命令。
    • 自动化说明: 说明该用例应自动化、保留手动或被阻塞的原因。
  4. 将每个测试用例写入
    <qa-output-path>/qa/test-cases/<TC-ID>.md
    。
  5. 交互式生成测试用例时，执行
    scripts/generate_test_cases.sh <qa-output-path>/test-cases
    。
步骤5：构建基于旅程的回归测试套件
  1. 暂停。在划分层级、确定优先级或定义通过/失败标准前，完整阅读
    references/regression_testing.md
    。     该文件定义了层级划分、优先级评估规则、自动化标记规则、执行顺序约定，以及
    PASS
    /
    FAIL
    /
    CONDITIONAL
    阈值。
  2. 测试套件层级是以旅程为核心，而非以测试用例为核心。每个层级选取N个旅程，再从这些旅程衍生测试用例：
    套件时长执行频率旅程数量
    冒烟测试15-30分钟每日/每次构建2-4个P0旅程
    定向测试30-60分钟每次变更后涉及变更界面的旅程
    完整测试2-4小时每周/发布前所有P0+P1旅程，覆盖所有用户角色
    Sanity测试10-15分钟热修复后受热修复影响的单个旅程
  3. 从用户影响角度确定旅程优先级：
    • P0: 失败会导致付费用户
      Blocks-Completion
      或
      Data-Loss
      的旅程。
    • P1: 失败会导致任何用户角色
      Trust-Damage
      或反复
      Friction
      的旅程。
    • P2: 次要旅程、边缘用户角色、低流量界面。
  4. 明确标记自动化候选对象：
    • 若仓库已有E2E测试框架，将变更或回归关键的P0/P1公开旅程标记为
      自动化目标: E2E
      。
    • 将Bug驱动的公开回归用例标记为
      自动化状态: 缺失
      ，直到qa-execution确认规范已添加或更新。
    • 将探索性、需视觉判断或不支持的流程标记为
      仅手动
      或
      阻塞
      并说明原因。
  5. 定义执行顺序：先执行冒烟测试（快速失败）→ P0旅程→ P1旅程→ P2旅程→ 探索性测试章程。
  6. 基于用户影响定义通过/失败标准：
    • 通过: 每个P0旅程都达成目标；无未解决的
      Blocks-Completion
      /
      Data-Loss
      类问题。
    • 失败: 任何P0旅程未达成目标；发现任何
      Blocks-Completion
      或
      Data-Loss
      类问题。
    • 条件通过: P1旅程存在有文档记录的解决方案；
      Friction
      /
      Trust-Damage
      类问题已有修复计划。
  7. 将套件文档写入
    <qa-output-path>/qa/test-plans/<suite-name>-regression.md
    。
步骤6：基于Figma设计验证
若未配置Figma MCP，则跳过此步骤。
  1. 暂停。在发起任何Figma MCP查询前，完整阅读
    references/figma_validation.md
    。     该文件定义了规范→检查→记录流程、MCP查询目录、1280/768/375分辨率下的响应式检查，以及常见差异目录。
  2. 使用MCP查询从Figma提取设计规范：尺寸、颜色（精确十六进制值）、排版、间距、边框圆角/阴影、交互状态。
  3. 生成UI测试用例（TC-UI-*），将每个属性与实现效果对比。
  4. 在标准视口（375/768/1280）下测试响应式表现。
  5. 若验证发现差异，按照步骤7生成Bug报告。大多数Figma还原度差异属于
    Cosmetic
    或
    Trust-Damage
    类——仅当差异阻碍用户理解时，才升级为
    Friction
    类。
  6. 若需基于浏览器的验证，使用
    agent-browser
    （qa-execution的配套工具）。
步骤7：创建Bug报告
  1. 暂停。在提交任何Bug前，完整阅读
    references/bug_report_templates.md
    。     该文件包含标准、UI/视觉、用户摩擦类Bug的变体模板及必填字段集合。
    assets/issue-template.md
    是精简版共享模板。
  2. 暂停。在分类影响前，完整阅读
    ../qa-execution/references/bug-severity-by-user-impact.md
    。     该文件定义了五级用户影响评估标准（Blocks-Completion / Data-Loss / Trust-Damage / Friction / Cosmetic），以及与传统严重程度/优先级的映射关系。
  3. 为Bug分配以
    BUG-
    为前缀的ID（例如
    BUG-001
    ）。
  4. 每个Bug报告必须包含：
    • 用户侧影响: Blocks-Completion | Data-Loss | Trust-Damage | Friction | Cosmetic。
    • 严重程度: Critical | High | Medium | Low（由用户侧影响映射得出）。
    • 优先级: P0 | P1 | P2 | P3（由用户侧影响映射得出）。
    • 状态: 
      pending
      | 
      resolved
      | 
      invalid
      。
    • 受影响用户角色: 发现该Bug的用户角色。
    • 旅程步骤: J-NN旅程名称+步骤编号。
    • 环境: 构建版本、操作系统、浏览器、视口、网络、区域设置、URL。
    • 复现步骤: 测试章程（CH-NN）、引导流程名称、用户语言描述的步骤。
    • 预期与实际结果: 清晰的用户侧描述。
    • 影响范围: 受影响用户数量、发生频率、解决方案、信任成本。
    • 关联内容: 若在测试用例中发现，关联TC-ID；若为UI Bug，关联Figma URL；关联相关旅程/测试章程。
  5. 将每个Bug报告写入
    <qa-output-path>/qa/issues/<BUG-ID>.md
    。
  6. 交互式创建Bug报告时，执行
    scripts/create_bug_report.sh <qa-output-path>/issues
    。
步骤8：验证完整性
  1. 验证每个测试用例的每个步骤都有可观测的用户侧预期结果。
  2. 验证每个Bug报告都有用户语言描述的可复现步骤。
  3. 验证可追溯性：测试用例关联用户角色和旅程；Bug报告在适用时关联测试用例和测试章程。
  4. 验证每个用户角色至少对应一个测试用例。
  5. 验证每个旅程至少对应一个测试用例。
  6. 验证为变更规划的每个CFR类别至少对应一个TC-CFR-*测试用例。
  7. 验证每个规划的关键流程都有明确的自动化标记，且
    缺失
    或
    阻塞
    状态包含原因说明。
  8. 在交付给执行环节前，对照
    ../qa-execution/references/checklist.md
    检查覆盖缺口。

Companion Skills

配套工具

  • qa-execution — Executes the deliverables this skill plans. Reads personas, journeys, charters, test cases from 
    <qa-output-path>/qa/
    ; writes verification report and bugs back.
  • agent-output-audit — Audits AI-implemented work / Compozy task slugs / CI gate / flaky test triage. Use for AI test-hygiene scans (RF-1..RF-6), task-status reconciliation, and quality gates — those concerns are explicitly out of scope for this skill.
  • agent-browser (curated) — Web UI driver invoked by 
    qa-execution
    during Step 6 Figma validation when browser-based verification is needed.
  • qa-execution — 执行本工具规划的交付物。从
    <qa-output-path>/qa/
    读取用户角色、旅程图、测试章程、测试用例；写入验证报告和Bug。
  • agent-output-audit — 审计AI实现的工作/Compozy任务标识/CI gate/不稳定测试分类。适用于AI测试卫生扫描（RF-1..RF-6）、任务状态核对和质量门禁——此类场景明确不属于本工具的范围。
  • agent-browser（精选）—— 当步骤6的Figma验证需基于浏览器的验证时，由qa-execution调用的Web UI驱动工具。

Bug Severity vs User Impact

Bug严重程度与用户影响的对应关系

Severity is the engineering-triage view. Impact is the user-side view. Both must be filled per bug. The full mapping rubric lives in 
../qa-execution/references/bug-severity-by-user-impact.md
:
Impact (user-side)Default SeverityDefault PriorityRelease impact
Blocks-CompletionCriticalP0Blocker on any P0 journey
Data-LossCriticalP0Blocker on any journey
Trust-DamageHighP1Multiple on same journey = blocker
FrictionMediumP2Tracked as redesign signal
CosmeticLowP3Batched into polish follow-up
严重程度是工程分类视角，影响是用户侧视角。每个Bug必须同时填写这两项。完整的映射规则位于
../qa-execution/references/bug-severity-by-user-impact.md
：
用户侧影响默认严重程度默认优先级发布影响
Blocks-CompletionCriticalP0任何P0旅程的阻塞项
Data-LossCriticalP0任何旅程的阻塞项
Trust-DamageHighP1同一旅程出现多个则为阻塞项
FrictionMediumP2作为重设计信号跟踪
CosmeticLowP3批量纳入后续优化任务

Error Handling

错误处理

  • If the 
    qa-output-path
    directory cannot be created, report the error and fall back to the current working directory.
  • If Figma MCP is not configured, skip Figma validation steps and note the gap in the test plan.
  • If 
    agent-browser
    is not available for UI validation, generate test cases as documentation for manual execution and note the limitation.
  • If the repository does not have a known E2E harness, mark affected cases as 
    Manual-only
    or 
    Blocked
    instead of inventing automation commands.
  • If the user provides a feature description that is too vague to generate test cases, ask for specific journeys, personas, or acceptance criteria before proceeding.
  • If a request is for a technical integration / security / performance test case (TC-INT, TC-SEC, TC-PERF, TC-API), explain that those types are out of scope for real-user QA planning. Direct the user to integration tests in code, SAST/DAST tools, and load testing tools respectively. If the user wants to audit AI-implemented work, direct them to 
    agent-output-audit
    .
  • 若无法创建
    qa-output-path
    目录，报告错误并回退到当前工作目录。
  • 若未配置Figma MCP，跳过Figma验证步骤并在测试计划中记录该缺口。
  • 若
    agent-browser
    不可用于UI验证，生成测试用例作为手动执行的文档并记录该限制。
  • 若仓库无已知E2E测试框架，将受影响的用例标记为
    仅手动
    或
    阻塞
    ，而非编造自动化命令。
  • 若用户提供的功能描述过于模糊，无法生成测试用例，在继续前请求提供具体的旅程、用户角色或验收标准。
  • 若请求涉及技术集成/安全/性能测试用例（TC-INT、TC-SEC、TC-PERF、TC-API），说明此类测试不属于真实用户QA规划的范围。引导用户分别使用代码中的集成测试、SAST/DAST工具、负载测试工具。若用户希望审计AI实现的工作，引导其使用
    agent-output-audit
    。