Back to Details

qa-execution

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Real-User QA Execution

真实用户QA执行

QA the way a real person would experience the product: assigned a persona, walking a journey, exercising charters bound to specific tours, probing the edges users actually hit, and validating CFRs that no single feature owns.
以真实用户体验产品的方式开展QA：为测试分配Persona、走查Journey、执行绑定特定Test Tour的Exploratory Charter、探测真实用户会遇到的边缘场景，并验证无单一功能负责的CFR（跨职能需求）。

Required Reading Router

必读文档指引

Match your task to the row. Read the listed files in full before producing output. They are not appendices — they are load-bearing. Inline content in this SKILL.md is a pointer, not a substitute.
TaskMUST read
Assigning personas to sessions (Step 2)
references/user-personas.md
Selecting high-value journeys (Step 2)
references/journey-maps.md
Writing exploratory charters and picking tours (Step 3)
references/exploratory-charters.md
+ 
references/test-tours.md
Executing browser flows (Step 4)
references/web-ui-qa.md
Probing off-script user edge cases (Step 5)
references/test-tours.md
+ 
references/user-edge-cases.md
Running the Cross-Functional Requirement pass (Step 6)
references/cfr-checks.md
Classifying bug severity by user impact (Step 7)
references/bug-severity-by-user-impact.md
Building the QA scope checklist
references/checklist.md
将你的任务与对应行匹配。在生成输出前完整阅读列出的文档，它们不是附录，而是核心内容。本SKILL.md中的内联内容仅作为指引，不能替代必读文档。
任务必须阅读
为会话分配Persona（步骤2）
references/user-personas.md
选择高价值Journey（步骤2）
references/journey-maps.md
编写Exploratory Charter并选择Test Tour（步骤3）
references/exploratory-charters.md
+ 
references/test-tours.md
执行浏览器流程（步骤4）
references/web-ui-qa.md
探测非脚本化用户边缘用例（步骤5）
references/test-tours.md
+ 
references/user-edge-cases.md
执行CFR检查（步骤6）
references/cfr-checks.md
按用户影响程度分类Bug严重等级（步骤7）
references/bug-severity-by-user-impact.md
构建QA范围检查清单
references/checklist.md

Reference Index

参考文档索引

  • references/user-personas.md
    — Canonical persona set (New User / Power User / Casual User / Mobile User / Accessibility-Reliant / Recovering User), attributes, and assignment rules.
  • references/journey-maps.md
    — Journey anatomy (entry → actions → goal → exit + abandonment), high-value journey selection, mapping template.
  • references/exploratory-charters.md
    — Charter format (mission + persona + surface + tour + time-box), charter modes (freestyle / strategy-based / scenario-based / collaborative / charter-with-tour), worked examples, debrief format.
  • references/test-tours.md
    — Canonical tour catalog: Feature, Money, Garbage, Back-Button, Multi-Tab, Network, Locale, Paste, Autofill, Interrupt. One tour per charter.
  • references/user-edge-cases.md
    — Catalog of non-technical edge cases real users hit (navigation, form, session, network, device, locale, accessibility, interrupt, trust/recovery).
  • references/cfr-checks.md
    — 45-minute CFR pass: usability (Nielsen short list), accessibility (WCAG AA quick check), perceived performance, compatibility, error recoverability, production parity.
  • references/bug-severity-by-user-impact.md
    — User-impact rubric (Blocks-Completion / Data-Loss / Trust-Damage / Friction / Cosmetic) with mapping to legacy severity/priority.
  • references/web-ui-qa.md
    — 
    agent-browser
    command set, snapshot/interact/verify loop, auth flows, viewport testing, anti-smoke guardrails.
  • references/checklist.md
    — Real-user QA checklist by category: persona coverage, journey coverage, charter coverage, off-script & edge case coverage, CFR coverage, bug filing, browser evidence, final report.
  • references/user-personas.md
    — 标准Persona集合（新用户/高级用户/普通用户/移动用户/依赖无障碍功能用户/恢复用户）、属性及分配规则。
  • references/journey-maps.md
    — Journey结构（入口→操作→目标→退出+放弃路径）、高价值Journey选择标准、旅程映射模板。
  • references/exploratory-charters.md
    — Charter格式（任务+Persona+界面+Test Tour+时间限制）、Charter模式（自由式/策略式/场景式/协作式/绑定Test Tour的Charter）、示例、汇报格式。
  • references/test-tours.md
    — 标准Test Tour目录：功能、支付、垃圾数据、返回按钮、多标签页、网络、区域设置、粘贴、自动填充、中断。每个Charter对应一个Test Tour。
  • references/user-edge-cases.md
    — 真实用户遇到的非技术边缘用例目录（导航、表单、会话、网络、设备、区域设置、无障碍、中断、信任/恢复）。
  • references/cfr-checks.md
    — 45分钟CFR检查：可用性（Nielsen精简列表）、无障碍（WCAG AA快速检查）、感知性能、兼容性、错误恢复能力、类生产环境一致性。
  • references/bug-severity-by-user-impact.md
    — 用户影响评估准则（阻止完成/数据丢失/信任损害/体验摩擦/视觉瑕疵），以及与传统严重等级/优先级的映射关系。
  • references/web-ui-qa.md
    — 
    agent-browser
    命令集、快照/交互/验证循环、认证流程、视口测试、防误操作准则。
  • references/checklist.md
    — 按类别划分的真实用户QA检查清单：Persona覆盖、Journey覆盖、Charter覆盖、非脚本化及边缘用例覆盖、CFR覆盖、Bug提交、浏览器证据、最终报告。

Required Inputs

必填输入

  • qa-output-path (optional): Directory where QA artifacts (issues, screenshots, verification reports) are stored. When provided, create the directory if it does not exist and use it for all QA outputs. When omitted, fall back to repository conventions or 
    /tmp/qa-execution-<slug>
    .
  • qa-output-path（可选）：存储QA工件（问题、截图、验证报告）的目录。若提供该参数，若目录不存在则创建，并将所有QA输出存入其中。若未提供，则遵循仓库约定，或回退至
    /tmp/qa-execution-<slug>
    。

Procedures

执行流程

Step 1: Resolve Output Directory and Read qa-report Artifacts
  1. Resolve the QA artifact directory. If the user provided a 
    qa-output-path
    argument, use it. Otherwise use repository conventions, falling back to 
    /tmp/qa-execution-<slug>
    . Create the 
    qa/
    subdirectory and 
    qa/screenshots/
    , 
    qa/issues/
    under it.
  2. Check whether 
    <qa-output-path>/qa/test-plans/
    , 
    <qa-output-path>/qa/test-cases/
    , and any persona/journey/charter artifacts exist from a prior 
    qa-report
    run. If they do, read them to seed Steps 2-3: persona assignments, journey maps, charter missions, and TC-* test cases prioritized by qa-report.
  3. Confirm the dev server URL or the runtime entry point is reachable in a production-parity build before any test runs. Do not run QA on a build that hasn't passed CI — that's 
    agent-output-audit
    's job, not this skill's. If CI hasn't been confirmed green, surface the gap and stop.
Step 2: Assign Personas and Select Journeys
  1. STOP. Read 
    references/user-personas.md
    in full before picking personas.     The six canonical personas (New User / Power User / Casual User / Mobile User / Accessibility-Reliant / Recovering User) and their attribute schema live there. The persona-of-convenience anti-pattern is the most common QA failure mode.
  2. Pick at least 3 personas for this release-candidate QA pass, covering the product's actual audience. Include at least one Mobile User when a mobile surface exists; include at least one Accessibility-Reliant persona unless explicitly out of scope (record the skip reasoning).
  3. STOP. Read 
    references/journey-maps.md
    in full before selecting journeys.     Journey anatomy (entry → actions → goal → exit + abandonment paths), high-value journey selection criteria, and the journey-map template live there.
  4. Pick 3-7 high-value journeys for this pass. Use these prompts: what generates revenue, what handles sensitive data, what's used most frequently, what's the first impression, what's the recovery path. Include at least one cross-feature journey when the product has them.
  5. For each journey, document at least one abandonment path — the realistic way a real user gives up partway through. Abandonment paths surface the highest-impact bugs.
  6. Record persona × journey assignments in working notes. Each journey gets at least one persona; each persona gets at least one journey.
Step 3: Plan Exploratory Charters
  1. STOP. Read 
    references/exploratory-charters.md
    in full before writing any charter.     Charter anatomy (mission + persona + surface + tour + time-box), charter modes, time-box guidance, debrief format. Charters are the single biggest predictor of whether the session finds real bugs.
  2. STOP. Read 
    references/test-tours.md
    in full before picking tours.     The 10-tour catalog (Feature / Money / Garbage / Back-Button / Multi-Tab / Network / Locale / Paste / Autofill / Interrupt) and the surface-to-tour matrix live there.
  3. For each persona × journey × surface, write a charter with: a one-sentence mission, the persona, the entry URL, exactly one tour, and a time-box (30 / 60 / 90 minutes). Save charter drafts to 
    <qa-output-path>/qa/test-plans/charters/
    when applicable.
  4. Mix charter modes deliberately: at least one charter-with-tour for each P0 journey, at least one freestyle for new surfaces, at least one scenario-based for cross-feature journeys.
  5. Order the session list by risk: highest-impact journey × highest-blast-radius tour first. Run the most fragile combinations while tester attention is fresh.
Step 4: Execute Journey Sessions (Web UI primary)
Skip this step's Web UI portion if the project has no Web UI surface — but still run CLI/HTTP journeys against the same persona × journey × charter plan.
  1. STOP. Read 
    references/web-ui-qa.md
    in full before opening a browser.     That file owns the complete 
    agent-browser
    command surface, the snapshot-driven core loop, auth flows, and the viewport testing matrix.
  2. For each charter from Step 3, in the order set there:
    • Stay in persona. If a New User wouldn't know about a feature, don't use it. If a Power User would use a keyboard shortcut, use it.
    • Navigate to the entry URL: 
      agent-browser open <url>
      . Confirm the persona's device profile (viewport, throttle, locale) via 
      --session
      + 
      --viewport
      flags as appropriate.
    • Snapshot interactively: 
      agent-browser snapshot -i
      .
    • Walk the journey verb by verb. After every interaction, re-snapshot and verify the expected observable for that step. Time each step against the journey's time budget.
    • Capture a screenshot at every verification checkpoint: 
      agent-browser screenshot <qa-output-path>/qa/screenshots/<journey-id>-step<N>.png
      .
    • Record observed time-to-feedback for any action that should feel fast (button clicks, form validation).
    • When the journey forks into a branch or an abandonment path, follow it and record outcome.
  3. For CLI / HTTP journeys, drive workflows through the same interfaces real operators or end-users would use, not internal test helpers. Capture exact command, input, and observable result for each scenario.
  4. Close the browser session after all flows complete: 
    agent-browser close
    .
Step 5: Run Off-Script Tours & User Edge Cases
  1. STOP. Read 
    references/test-tours.md
    in full before launching tours.     Each tour names off-script actions specific to its theme — they are not interchangeable.
  2. STOP. Read 
    references/user-edge-cases.md
    in full before probing edges.     That file's catalog (navigation, form, session, network, device, locale, accessibility, interrupt, trust/recovery) is the canonical edge-case list — not unit-level edge cases.
  3. For each charter from Step 3, run the assigned tour against the surface:
    • Stay in persona, stay in time-box.
    • Execute the tour's off-script actions, asking "would this matter for this tour's theme?" at each one.
    • Pick 5-10 relevant entries from 
      user-edge-cases.md
      that match the surface and persona. Don't try every edge case — the time-box governs.
  4. For every finding, capture the persona felt (not just the technical observation): "a mobile user with one hand could not reach the submit button" is more actionable than "button is 8px out of touch target".
  5. Document attempted edge cases in the charter debrief whether they fired or not — confirmed-clean is also evidence.
Step 6: Cross-Functional Requirement Pass
  1. STOP. Read 
    references/cfr-checks.md
    in full before starting the CFR pass.     That file owns the six CFR categories (usability, accessibility, perceived performance, compatibility, error recoverability, production parity) and the 45-minute time-box.
  2. Pick 2 journeys from your charters that exercise the largest surface area. Re-walk them as a CFR audit, not a journey verification.
  3. At each step, ask the six CFR categories. Mark each 
    pass
    , 
    friction
    , or 
    fail
    .
  4. Run the WCAG AA quick check (keyboard, screen reader, visual) on the changed surface. The full conformance audit is out of scope — short check only.
  5. Run the compatibility smoke (latest Chrome + Safari + Firefox + iOS Safari + Android Chrome) on any surface that touched layout or forms.
  6. Validate production parity: not in incognito, cookies enabled, realistic extension set, real auth path, realistic worst-case network.
  7. File one bug per CFR finding using the severity rubric in 
    references/bug-severity-by-user-impact.md
    . Most CFR findings are 
    Friction
    or 
    Trust-Damage
    ; promote to 
    Blocks-Completion
    only when the failure abandons the user.
Step 7: File Bugs by User Impact
  1. STOP. Read 
    references/bug-severity-by-user-impact.md
    in full before classifying any bug.     The five-tier user-impact rubric and the mapping to legacy Severity/Priority live there.
  2. Use 
    assets/issue-template.md
    to write issue files under 
    <qa-output-path>/qa/issues/
    . Name each 
    BUG-<NNN>.md
    .
  3. For every bug, fill: 
    • Impact (user-side):
      — Blocks-Completion / Data-Loss / Trust-Damage / Friction / Cosmetic.
    • Severity:
      and 
      Priority:
      — via the mapping rubric.
    • Persona Affected:
      — the persona whose session surfaced the bug.
    • Journey Step:
      — the J-NN journey name and the step number where it fired.
    • Cite the charter (CH-NN) and tour in 
      Reproduction:
      .
  4. When a bug ties to a 
    qa-report
    test case, include the TC-ID in 
    Related
    . The 
    Automation Follow-up:
    block (audit-only) does not apply to this skill — leave it out.
  5. Reproduce each failure consistently before proposing a fix. For bounded root-cause fixes inside the QA scope, apply the fix, re-run the impacted journey, and update the bug to 
    resolved
    . For larger features, file and move on; do not silently pass.
Step 8: Write the Verification Report
  1. Re-run the most critical journeys from Step 4 after any code change made during the QA pass.
  2. Summarize evidence using 
    assets/verification-report-template.md
    and write the report to 
    <qa-output-path>/qa/verification-report.md
    .
  3. Mandatory sections (per the template):
    • PERSONA COVERAGE — every persona × charter combination.
    • JOURNEY EXECUTION LOG — per-step verdicts, screenshot paths, abandonment paths covered.
    • CHARTER LOG — mission, tour, time-box, debrief, suggested-next per charter.
    • OFF-SCRIPT FINDINGS — edge cases attempted and outcomes.
    • CFR FINDINGS — pass/friction/fail per CFR category per journey.
    • BROWSER EVIDENCE — dev server, flows, viewports, auth, blocked flows.
    • ISSUES FILED — totals by user impact tier and by legacy severity.
  4. Disclose blocked sessions, missing credentials, or environment gaps explicitly with the exact prerequisite that stopped execution.
  5. Do not claim PASS without fresh evidence from the current state of the build. The verification report is the contract — if a section is empty, that's a coverage gap, not a green light.
步骤1：确定输出目录并读取qa-report工件
  1. 确定QA工件目录。若用户提供了
    qa-output-path
    参数，则使用该目录；否则遵循仓库约定，回退至
    /tmp/qa-execution-<slug>
    。在该目录下创建
    qa/
    子目录，以及
    qa/screenshots/
    和
    qa/issues/
    子目录。
  2. 检查
    <qa-output-path>/qa/test-plans/
    、
    <qa-output-path>/qa/test-cases/
    以及是否存在之前
    qa-report
    运行生成的Persona/Journey/Charter工件。若存在，读取这些内容以初始化步骤2-3：Persona分配、Journey映射、Charter任务以及qa-report优先排序的TC-*测试用例。
  3. 在开始任何测试前，确认开发服务器URL或运行时入口点在类生产环境构建中可访问。请勿在未通过CI的构建上运行QA — 这是
    agent-output-audit
    的职责，而非本技能的工作。若CI未确认通过，需指出该问题并停止执行。
步骤2：分配Persona并选择Journey
  1. 停止操作。在选择Persona前完整阅读
    references/user-personas.md
    。文档中包含6个标准Persona（新用户/高级用户/普通用户/移动用户/依赖无障碍功能用户/恢复用户）及其属性规范。随意选择Persona是QA最常见的失败模式。
  2. 为本次发布候选版本QA选择至少3个Persona，覆盖产品的实际受众。若产品有移动端界面，至少包含一个移动用户Persona；除非明确排除范围，否则至少包含一个依赖无障碍功能的Persona（需记录跳过理由）。
  3. 停止操作。在选择Journey前完整阅读
    references/journey-maps.md
    。文档中包含Journey结构（入口→操作→目标→退出+放弃路径）、高价值Journey选择标准以及Journey映射模板。
  4. 为本次测试选择3-7个高价值Journey。可参考以下问题：哪些功能产生收入？哪些功能处理敏感数据？哪些功能使用频率最高？哪些是用户第一印象？哪些是恢复路径？若产品有多功能交叉场景，至少包含一个跨功能Journey。
  5. 为每个Journey记录至少一条放弃路径 — 即真实用户中途放弃的合理场景。放弃路径能发现影响最大的Bug。
  6. 在工作笔记中记录Persona × Journey的分配情况。每个Journey至少对应一个Persona；每个Persona至少对应一个Journey。
步骤3：规划Exploratory Charter
  1. 停止操作。在编写任何Charter前完整阅读
    references/exploratory-charters.md
    。文档中包含Charter结构（任务+Persona+界面+Test Tour+时间限制）、Charter模式、时间限制指引、汇报格式。Charter是决定会话能否发现真实Bug的关键因素。
  2. 停止操作。在选择Test Tour前完整阅读
    references/test-tours.md
    。文档中包含10种Test Tour目录（功能、支付、垃圾数据、返回按钮、多标签页、网络、区域设置、粘贴、自动填充、中断）以及界面与Test Tour的对应矩阵。
  3. 为每个Persona × Journey × 界面编写Charter，包含：一句话任务描述、Persona、入口URL、恰好一个Test Tour、时间限制（30/60/90分钟）。若适用，将Charter草稿保存至
    <qa-output-path>/qa/test-plans/charters/
    。
  4. 有意识地混合Charter模式：每个P0级Journey至少对应一个绑定Test Tour的Charter，每个新界面至少对应一个自由式Charter，每个跨功能Journey至少对应一个场景式Charter。
  5. 按风险排序会话列表：影响最大的Journey × 影响范围最广的Test Tour优先执行。在测试人员注意力集中时运行最易出问题的组合。
步骤4：执行Journey会话（以Web UI为主）
若项目无Web UI界面，可跳过此步骤的Web UI部分 — 但仍需按照相同的Persona × Journey × Charter计划执行CLI/HTTP旅程。
  1. 停止操作。在打开浏览器前完整阅读
    references/web-ui-qa.md
    。该文档包含完整的
    agent-browser
    命令集、快照驱动核心循环、认证流程以及视口测试矩阵。
  2. 按照步骤3确定的顺序，执行每个Charter：
    • 保持Persona视角。若新用户不会了解某功能，请勿使用；若高级用户会使用键盘快捷键，则使用该快捷键。
    • 导航至入口URL：
      agent-browser open <url>
      。通过
      --session
      + 
      --viewport
      参数确认Persona对应的设备配置（视口、节流、区域设置）。
    • 交互式快照：
      agent-browser snapshot -i
      。
    • 逐步骤走查Journey。每次交互后，重新快照并验证该步骤的预期可见结果。记录每个步骤是否符合Journey的时间预算。
    • 在每个验证检查点捕获截图：
      agent-browser screenshot <qa-output-path>/qa/screenshots/<journey-id>-step<N>.png
      。
    • 记录任何应快速响应的操作（按钮点击、表单验证）的反馈时间。
    • 当Journey分支或进入放弃路径时，跟进并记录结果。
  3. 对于CLI/HTTP旅程，通过真实操作员或终端用户使用的接口驱动工作流，而非内部测试工具。捕获每个场景的精确命令、输入和可见结果。
  4. 所有流程完成后关闭浏览器会话：
    agent-browser close
    。
步骤5：运行非脚本化Test Tour & 用户边缘用例
  1. 停止操作。在启动Test Tour前完整阅读
    references/test-tours.md
    。每个Test Tour都有其主题对应的非脚本化操作 — 它们不可互换。
  2. 停止操作。在探测边缘用例前完整阅读
    references/user-edge-cases.md
    。该文档的目录（导航、表单、会话、网络、设备、区域设置、无障碍、中断、信任/恢复）是标准边缘用例列表 — 而非单元级边缘用例。
  3. 对步骤3中的每个Charter，针对对应界面运行分配的Test Tour：
    • 保持Persona视角，遵守时间限制。
    • 执行Test Tour的非脚本化操作，每一步都问自己：“这对该Test Tour的主题是否重要？”
    • 从
      user-edge-cases.md
      中选取5-10个与界面和Persona匹配的相关用例。无需尝试所有边缘用例 — 时间限制为首要准则。
  4. 对于每个发现，记录Persona的感受（而非仅技术观察）：“单手操作的移动用户无法触及提交按钮”比“按钮超出触摸目标8px”更具可操作性。
  5. 在Charter汇报中记录尝试过的边缘用例，无论是否发现问题 — 确认无问题也是证据。
步骤6：跨职能需求（CFR）检查
  1. 停止操作。在开始CFR检查前完整阅读
    references/cfr-checks.md
    。该文档包含6个CFR类别（可用性、无障碍、感知性能、兼容性、错误恢复能力、类生产环境一致性）以及45分钟的时间限制。
  2. 从Charter中选取2个覆盖界面范围最广的Journey。以CFR审计的方式重新走查，而非Journey验证。
  3. 在每个步骤中，检查6个CFR类别，标记为
    通过
    、
    体验摩擦
    或
    失败
    。
  4. 对变更后的界面运行WCAG AA快速检查（键盘、屏幕阅读器、视觉）。完整合规性审计超出范围 — 仅需快速检查。
  5. 对任何涉及布局或表单的界面运行兼容性冒烟测试（最新版Chrome + Safari + Firefox + iOS Safari + Android Chrome）。
  6. 验证类生产环境一致性：非隐身模式、启用Cookie、真实扩展集、真实认证路径、真实最坏情况网络。
  7. 使用
    references/bug-severity-by-user-impact.md
    中的严重等级准则为每个CFR发现提交Bug。大多数CFR发现属于
    体验摩擦
    或
    信任损害
    ；仅当故障导致用户放弃时才升级为
    阻止完成
    。
步骤7：按用户影响提交Bug
  1. 停止操作。在分类任何Bug前完整阅读
    references/bug-severity-by-user-impact.md
    。文档中包含五级用户影响准则以及与传统严重等级/优先级的映射关系。
  2. 使用
    assets/issue-template.md
    在
    <qa-output-path>/qa/issues/
    下编写问题文件。命名格式为
    BUG-<NNN>.md
    。
  3. 每个Bug需填写： 
    • 用户侧影响：
      — 阻止完成/数据丢失/信任损害/体验摩擦/视觉瑕疵。
    • 严重等级：
      和
      优先级：
      — 通过映射准则确定。
    • 受影响Persona：
      — 发现该Bug的会话对应的Persona。
    • Journey步骤：
      — J-NN格式的Journey名称以及触发Bug的步骤编号。
    • 在
      复现步骤：
      中引用Charter（CH-NN）和Test Tour。
  4. 若Bug与qa-report测试用例相关，在
    关联内容：
    中包含TC-ID。
    自动化跟进：
    区块（仅审计用）不适用于本技能 — 留空即可。
  5. 在提出修复前，需一致复现每个故障。对于QA范围内的有限根因修复，应用修复后重新运行受影响的Journey，并将Bug更新为
    已解决
    。对于较大功能，提交Bug后继续执行；请勿静默忽略。
步骤8：编写验证报告
  1. QA过程中若有代码变更，重新运行步骤4中最关键的Journey。
  2. 使用
    assets/verification-report-template.md
    汇总证据，并将报告写入
    <qa-output-path>/qa/verification-report.md
    。
  3. 模板要求的必填章节：
    • PERSONA覆盖 — 所有Persona × Charter组合。
    • Journey执行日志 — 每一步的 verdict、截图路径、覆盖的放弃路径。
    • Charter日志 — 任务、Test Tour、时间限制、汇报、每个Charter的后续建议。
    • 非脚本化发现 — 尝试的边缘用例及结果。
    • CFR发现 — 每个Journey在各CFR类别的通过/体验摩擦/失败情况。
    • 浏览器证据 — 开发服务器、流程、视口、认证、被阻止的流程。
    • 已提交问题 — 按用户影响等级和传统严重等级统计的总数。
  4. 明确披露被阻止的会话、缺失的凭证或环境问题，并记录导致执行停止的具体前提条件。
  5. 若无当前构建状态的新鲜证据，请勿声称测试通过。验证报告是约定文件 — 若某章节为空，说明存在覆盖缺口，而非测试通过。

Companion Skills

配套技能

  • qa-report — Plans the deliverables this skill consumes: personas, journey maps, charters, test cases, regression suites, Figma fidelity validation. The shared output directory 
    <qa-output-path>/qa/
    is the contract between them.
  • agent-output-audit — Audits AI-implemented work / Compozy task slugs. Owns the CI verification gate, AI test-hygiene scans (RF-1..RF-6), the independent evaluator protocol, flaky-test triage, task-status reconciliation, and quality gates. Do not duplicate that work here; if a real-user QA session uncovers AI-implementation concerns, file the bug and recommend running 
    agent-output-audit
    separately.
  • agent-browser (curated) — Web UI driver used in Step 4 and Step 5. The command set is documented in 
    references/web-ui-qa.md
    .
  • qa-report — 规划本技能所需的交付物：Persona、Journey Map、Charter、测试用例、回归套件、Figma保真度验证。共享输出目录
    <qa-output-path>/qa/
    是两者之间的约定。
  • agent-output-audit — 审计AI实现的工作/Compozy任务标识。负责CI验证网关、AI测试卫生扫描（RF-1..RF-6）、独立评估协议、不稳定测试分类、任务状态核对和质量网关。请勿在此重复该工作；若真实用户QA会话发现AI实施相关问题，请提交Bug并建议单独运行
    agent-output-audit
    。
  • agent-browser（精选版） — 步骤4和步骤5中使用的Web UI驱动工具。命令集记录在
    references/web-ui-qa.md
    中。

Error Handling

错误处理

  • If the build is not reachable in a production-parity environment, stop and surface the gap. Do not test against local mocks or a CI-only artifact — the QA result will not generalize.
  • If the dev server fails to start or 
    agent-browser
    is unavailable, skip Web UI flows, document the blocker in the verification report, and continue with CLI/HTTP journeys when applicable.
  • If a browser flow hangs or times out, close the session with 
    agent-browser close
    , record the failure, and attempt the flow once more from a clean session before marking it as blocked.
  • If credentials, test data, or environment access are missing for a planned journey, classify it as 
    blocked
    , document the exact prerequisite, and proceed with the remaining journeys.
  • If the persona × journey × charter list exceeds the available QA window, prioritize by user-impact risk (Blocks-Completion candidates first, then Data-Loss, then Trust-Damage). Defer lower-impact journeys to a follow-up pass and record the deferral.
  • If a session uncovers something out of scope for real-user QA (CI failure, test code looking suspicious, task status mismatched, flaky test in an automated suite), file the bug, name the right gate (
    agent-output-audit
    or the CI pipeline), and do not pivot mid-session.
  • If a CFR pass exceeds the 45-minute box, stop and file a follow-up CFR charter. Tester fatigue at hour 2 produces false positives.
  • If the dev server requires real third-party services (payment, email, SSO) and they are unavailable, validate every reachable boundary and record the live-step blockers explicitly. Do not substitute mocks for the final user proof.
  • 若类生产环境构建不可访问，停止执行并指出该问题。请勿针对本地模拟或仅CI可用的工件进行测试 — QA结果不具备通用性。
  • 若开发服务器无法启动或
    agent-browser
    不可用，跳过Web UI流程，在验证报告中记录该阻塞问题，若适用则继续执行CLI/HTTP旅程。
  • 若浏览器流程挂起或超时，使用
    agent-browser close
    关闭会话，记录故障，从干净会话重新尝试一次后再标记为阻塞。
  • 若计划的Journey缺失凭证、测试数据或环境权限，将其标记为
    阻塞
    ，记录具体前提条件，继续执行剩余Journey。
  • 若Persona × Journey × Charter列表超出可用QA时间窗口，按用户影响风险排序（优先处理可能导致阻止完成的场景，其次是数据丢失，然后是信任损害）。将低影响Journey推迟至后续测试，并记录推迟原因。
  • 若会话发现超出真实用户QA范围的问题（CI失败、测试代码可疑、任务状态不匹配、自动化套件中的不稳定测试），提交Bug，指明对应的负责网关（
    agent-output-audit
    或CI流水线），请勿中途切换任务。
  • 若CFR检查超出45分钟时间限制，停止执行并提交后续CFR Charter。测试人员在第2小时会疲劳，易产生误报。
  • 若开发服务器依赖真实第三方服务（支付、邮件、SSO）且这些服务不可用，验证所有可访问的边界，明确记录实时步骤的阻塞问题。请勿使用模拟替代最终用户验证。