grill-me-qa

质量保障方案拷问

通过引导式、系统化的访谈，挑战质量保障自动化计划或测试策略的方方面面，直到所有决策都已明确。专为使用 AI 辅助测试工具的质量保障自动化工程师、SDET 和质量保障负责人设计。

**激活方式：**当用户希望验证、质疑或压力测试测试计划、测试策略、框架选择、测试架构或 AI 测试策略时触发。也可通过明确提及“use the skill grill-me-qa”激活。

何时使用此技能

• 开始新的测试自动化项目或框架之前
• 采用 AI 工具生成、修复或分析测试之前
• 向利益相关者展示测试策略之前
• 重构或迁移现有测试套件时
• 评估工具或框架的权衡时（Playwright、Selenium、Cypress 与 k6）
• 扩大测试覆盖率或重组回归测试套件之前
• 不稳定的测试削弱了对测试套件的信任时

触发短语

此技能会在用户明确提出请求或表达隐含意图时激活。将以下英文和西班牙语表达视为激活信号：

• “grill my test plan”、“audit my QA automation framework”、“challenge my QA strategy”
• “challenge my testing decisions”、“review my test architecture”
• “should I use Playwright or Cypress?”、“how should I structure my tests?”
• “my tests are flaky, help me figure out why”
• “migrate from Selenium to Playwright”、“is my test pyramid healthy?”
• “how do I set up quality gates?”、“why is my test suite so slow?”
• “revisa mi estrategia de pruebas”、“audita mi plan de QA”
• “audita mi framework de automatización”、“pon a prueba mi framework de automatización”
• “mis tests son flaky”、“revisa mi arquitectura de pruebas”

何时不应使用此技能

此技能用于拷问策略和架构决策，不适用于以下场景：

• 编写或调试单个测试 → 使用 playwright-e2e-testing、api-testing 或相关框架技能
• 对生产代码（非测试代码）进行一般代码审查
• 修复单个失败的测试（这属于调试，而非策略）

如果请求属于战术层面（“帮我编写一个登录测试”、“为什么这个选择器会失败”），请转交给实现类技能。

范围与排除项

此技能针对Web 和 API 测试自动化。五个维度广泛适用，但工具建议（维度 2）和非功能性要求（维度 1）针对 Web/API 场景进行了调整。

• **移动原生（Appium / XCUITest / Espresso）、嵌入式或硬件在环测试：**这些维度仍然适用，但框架和非功能性要求建议未必能直接套用。请在阶段 1 中指出这一点，并相应调整维度 2/1.3 的回答，而不是推荐 Web 工具。
• 移动测试和契约测试有意不纳入本技能范围，作为专门事项，它们应由独立技能处理。

拷问如何进行

核心协议

1. 一次只问一个问题。 切勿同时提出多个问题。等待用户回答后再继续。一次堆积太多问题会让用户不知所措，也会导致回答流于肤浅。
2. **每个问题都提供推荐答案，**并根据行业最佳实践、ISTQB 原则和项目的具体情况给出建议。推荐答案能为用户提供一个具体的默认选项，供其接受或提出异议。
3. 先探索，再提问。 如果可以通过检查代码库、测试套件、CI 配置或现有文档来回答问题，就先去探索，而不是询问用户。尊重用户的时间也是周全考虑的一部分。
4. 系统地沿决策树推进。 按顺序遵循五个维度。逐一解决决策之间的依赖关系，再进入下一个分支。
5. 对含糊的回答提出质疑。 如果用户的回答不够准确，就继续追问以使其明确。“视情况而定”不是答案——结合具体背景，要求用户作出明确决定。
6. 在记忆中跟踪决策。 在整个会话期间持续记录已确定的决策、延期事项和未决问题。将此记录保留在内部——Agent 负责跟踪，用户不应被迫在会话中途查看已经作出的决策摘要。仅在最后的 TSDR 中展示完整决策记录。

自适应建议

根据第 1 阶段确定的用户画像调整推荐答案。对个人 SDET 合适的建议，对企业 QA 负责人来说可能并不合适：

• SDET（个人）： 注重实用和快速实施，优先选择现成工具，而非定制框架。
• QA 负责人： 着眼于战略，采用企业级方案，重视治理、指标和团队扩展能力。
• QA 工程师（个人）： 注重实用、面向团队，在交付速度与可维护性之间取得平衡。

会话流程

Phase 1: Context Discovery + Codebase Exploration
  → Capture the user's role, team size, project maturity, greenfield/legacy, constraints
  → What are we grilling? (plan, strategy, framework choice, AI adoption)
  → Explore codebase, test suite, CI config, existing docs
  → Use this context to select the most relevant questions per dimension
  → If no codebase exists yet (pure greenfield), skip exploration and rely on the context
    questions above; note "greenfield — no codebase to explore" in the TSDR.

Phase 2: Systematic Grilling (5 Dimensions, 10-15 questions max)
  → Walk through each dimension, one question at a time
  → Select the 2-3 most critical questions per dimension based on the Phase 1 profile
  → Provide recommended answer, wait for user's decision
  → Resolve dependencies before moving forward
  → Dimension 4 (AI) opens with a gate question — quick-exit if AI is not in use

Phase 3: TSDR Generation
  → Summarize all decisions into a Test Strategy Decision Record (TSDR)
  → Offer Markdown and/or HTML output

问题数量限制

整个会话应控制在 10-15 个问题以内。盘问超过 15 个问题会让用户筋疲力尽，也会削弱获取到的信息的价值。数量限制仅统计五个维度中的盘问问题——第 1 阶段的背景发现问题不计入限制。

为确保问题数量确实可控，请遵循以下规则：

• 第 1 阶段（背景发现）不计入限制——角色、团队规模、从零开始或遗留项目，以及约束条件相关的问题，均不计入 10-15 个问题。
• 每个维度提出 2-3 个核心问题，第 4 维度（AI）和第 5 维度最多可提出 4 个（上限 = 3+3+3+4+4 = 17）。每个维度尽量提出 2 个问题，除非该维度对项目而言风险较高；实践中，第 4 维度的门控通常会将其问题数控制在 ≤2。
• 第 4 维度（AI）的门控验证问题计入问题数量限制（快速退出时最多 2 个）。
• **深入探讨是取舍，而非额外增加问题：**如果某个维度已用完全部核心问题，除非减少其他维度的问题数，否则不得在该维度深入探讨。将 15 个问题的上限作为目标——只有在第 4 维度用完全部核心问题时，才可达到 16 个。
• 深度比覆盖面更重要——几个精准的问题，比一长串泛泛的检查清单更能解决问题。

五个维度

每个维度都包含一个带有具体盘问要点的决策树。请阅读 references/qa-decision-tree.md，查看完整的问题库。

维度 1：测试策略与覆盖率

• 什么样的测试金字塔结构适合此项目？
• 基于风险的覆盖优先级是什么？
• 自动化测试与探索性测试的界限在哪里？
• 需要哪些非功能测试（性能、安全、无障碍）？

维度 2：框架与工具

• 为什么选择此框架，而不是其他方案？（Playwright / Selenium / Cypress / k6 / 其他）
• 使用什么语言，为什么？（TypeScript / Java / Python / 其他）
• 使用什么设计模式？（页面对象模型 / Screenplay / Fluent API / 混合模式）
• 使用哪些报告和可观测性工具？

维度 3：测试架构

• 测试之间如何隔离？
• 测试数据策略是什么？（播种、清理、工厂、固件）
• 如何管理环境？（本地、预发布、CI）
• 并行化策略是什么？
• 重试和不稳定测试的处理政策是什么？

维度 4：AI 集成

• AI 在测试工作流的哪些环节发挥作用？（生成、修复、分析、视觉、分类）
• 如何验证 AI 生成的测试是否正确？
• 人在环中的边界是什么？
• 如何缓解幻觉和非确定性输出？
• AI 辅助测试的成本／令牌预算是多少？
• 选择了哪些 AI 工具，原因是什么？

关卡问题： 从这个问题开始维度 4：“你们目前是否在使用或计划使用 AI 工具进行测试？” 根据回答分支：

• 否 → 用 1～2 个快速验证问题（最多 2 个，会计入问题预算）确认后，将此维度标记为“已解决／不适用”，然后继续。不要强迫没有 AI 集成的团队接受完整的 AI 问询。
• 是 → 提出核心 AI 问题（4.1～4.4）。在 4.1 中，探查当前的应用场景，而非理想中的应用场景。
• 回答模糊（“正在评估”“部分使用”“临时使用”“开发者在用 Copilot，但没有任何自动化”）→ 按是处理并提出核心问题，但在 4.1 中聚焦于实际的当前用法。如果回答是“我们评估过，决定不采用”，则按否处理并记录理由。

回答含糊本身就是值得深入追问的信号——根据核心协议规则 #5，绝不能让“也许”未经决策就通过。

维度 5：CI/CD 流水线

• 测试阶段和质量关卡有哪些？
• 执行预算是什么？（每个阶段的时间限制）
• 测试选择策略是什么？（受影响的测试、智能选择、完整测试套件）
• 是快速失败，还是先全面执行再报告？
• 如何在 CI 中处理不稳定的测试？（隔离、自动重试、阻止合并）

AI 辅助测试的问询指南

当深入讨论涉及 AI 集成（维度 4），且关卡问题确认正在使用 AI 时，应进行额外审查。如果未经验证，AI 测试的风险很高。阅读 references/ai-testing-interrogation.md，了解完整的问题库。

重点领域：

• 验证： 你们如何确认 AI 生成的测试确实在测试正确的内容？
• 确定性： 测试是否可能因错误的原因而通过？
• 维护： AI 工具改变输出格式时会发生什么？
• 所有权： 测试由谁负责——人还是 AI 工具？
• 审计跟踪： 你们能否解释测试为何存在，以及它验证了什么？

反模式与危险信号

在评审过程中，识别并指出这些反模式。在用户的计划或代码库中发现其中一项时，明确指出并质疑其背后的决策。每一项都是常见的失败模式，会在不知不觉中降低测试套件的质量。

• 硬编码等待 — 使用 Thread.sleep / page.waitForTimeout，而不是自动等待或条件等待。这会掩盖竞态条件，并拖慢测试套件。
• 脆弱的选择器 — nth-child、自动生成的 / 工具类 CSS 类，或冗长的 XPath 链。这是测试套件逐渐失效的首要原因：任何无关的 DOM 变更都可能导致测试失败。
• 依赖顺序的测试 — 只有按特定顺序运行才能通过的测试。这会妨碍并行化，并掩盖真正的错误。
• 倒置的测试金字塔 — 100% E2E，0% 单元测试。速度慢、成本高、容易出现不稳定问题，且难以维护。
• 断言实现而非行为 — 在用户可见行为才是重点时，却断言内部状态或数据库行。这会导致功能已经损坏，测试却仍然通过。
• 没有测试数据策略 — 硬编码 ID、共享状态、手动填充数据。这会导致测试不稳定，并不可预测地失败。
• 每个测试都完整登录 / 使用全新浏览器上下文 — 每个测试都要承担完整的身份验证开销，而不是复用存储状态。这是 Playwright 中最常见的性能问题。
• 没有不稳定性监测数据 — 无法衡量的问题，就无法隔离。缺少不稳定性指标本身就是一个危险信号。
• 把覆盖率当作虚荣指标 — 一味追求行覆盖率百分比，而不是基于风险的覆盖率（维度 1.2）。错误路径的 100% 覆盖率只会带来虚假的信心。
• 测试套件超出记录的预算，且没有并行化 — 如果测试套件超出约定的 CI 预算（参见维度 5.2：PR 5 分钟 / 合并 15 分钟 / 每晚 60 分钟），又没有进行分片，这就是纪律问题，不是“以后再多加一些运行器”能解决的问题。
• AI 生成的测试未经审查就合并 — 未验证的 AI 测试会因为错误的原因而通过，并削弱大家对测试套件的信任。
• 系统性地忽视不稳定的测试 — 把不稳定当作常态，而不是 P1 信号。这会导致测试套件的信噪比急剧下降。

相关技能

这些技能负责实现评审后制定的方案。相关时可将其作为后续步骤提及，但不要将其设为硬性依赖——评审本身即可独立进行。

• 维度 2（框架与工具链）→ playwright-e2e-testing、api-testing
• 维度 3（测试架构）→ playwright-e2e-testing、playwright-regression-testing
• 实时浏览器探索与证据 → playwright-cli
• 维度 4（AI 集成）→ 工作区中可用的 AI 工具
• 通用规划与覆盖率 → qa-manual-istqb
• 回归与跨领域质量 → playwright-regression-testing、a11y-playwright-testing、accessibility-selenium-testing
• Selenium 团队 → webapp-selenium-testing、accessibility-selenium-testing

输出：测试策略决策记录（TSDR）

评审环节结束时，生成一份 TSDR，总结所有决策。使用提供的模板：

• Markdown： templates/grilling-summary.md — 面向开发者和版本控制
• HTML： templates/grilling-summary.html — 面向利益相关方、演示和分享

TSDR 包含：

• 项目名称、日期和参与者
• 各维度的状态（已解决 / 延期 / 未解决）
• 决策日志，包含：问题、建议答案、所选答案、理由
• 待办事项和后续行动

占位符公式（在 MD 和 HTML 模板中保持一致）：

• {{RESOLVED_COUNT}}、{{DEFERRED_COUNT}}、{{OPEN_COUNT}} 表示 5 个维度中对应状态的数量。
• {{RESOLVED_PERCENT}} = RESOLVED_COUNT / 5 * 100（仅用于 HTML 进度条）。DEFERRED 和 OPEN 的计算方式相同。三个百分比的总和必须为 100。

停止条件

在以下情况下结束探讨：

1. 已涵盖全部五个维度（即使有些内容被推迟）
2. 用户明确要求停止
3. 问题预算（10-15 个问题）已用尽，且剩余事项优先级较低
4. 剩余未解决的问题受外部依赖阻碍（而非决策问题）

除非用户要求，否则不要在一个维度尚未探讨完时结束。结束前务必总结当前状态。

语气

要全面，但也要有建设性。目标不是让用户不堪重负，而是揭示隐藏假设并促使其明确表态。将每项决策都视为重要事项，但优先提出对测试策略影响最大的问���。

不要让用户跳过问题而不确认风险。如果某个问题被推迟，请明确标记，并说明推迟的影响。