QA Discovery Interview

QA Discovery Interview

Purpose

QA-adapted discovery interview that transforms vague project context into a structured QA brief through iterative, category-driven questioning. Works in two modes:

• Standalone: User directly starts an interview for a new project or feature
• Embedded: Other skills auto-delegate here when their input is insufficient (<3 sentences or missing critical context)

Trigger Phrases

• "Start QA discovery interview"
• "Interview me about the project"
• "I need to set up QA for a new project"
• "Help me define testing scope"
• "QA brief for [project/feature]"
• "What should we test?"
• "New project QA setup"

Dual-Use Pattern

Embedding Pattern for Other Skills

When another skill detects insufficient input:

1. Notify user: "Not enough context for quality output."
2. Offer: "I can run a QA discovery interview, or you can provide more details manually."
3. If interview chosen → run interview → feed QA Brief output back into the calling skill.

Skills that auto-trigger this interview:

• qa-requirements-generator (from-description mode with <3 sentences)
• qa-spec-writer (ambiguous requirements or incomplete acceptance criteria)
• qa-plan-creator (no requirements, no codebase, no prior docs)
• qa-test-strategy (first run on a project with no existing docs)
• qa-orchestrator (full-cycle pipeline with no existing QA documentation)

Interview Phases

Workflow

Phase 1: Initial QA Orientation (2-3 questions)

Start with broad orientation to establish context:

1. "What product/feature are we testing? Give me a brief overview."
2. "Is this a new project, an existing one, or a migration? What's the current state?"
3. "Who are the key stakeholders, and what are their quality expectations?"

Based on answers, determine which of the 8 categories need deepest exploration.

Phase 2: Category Deep Dive

Work through 8 QA categories adaptively. Skip or abbreviate categories where context is already clear. Spend more time on gaps and risk areas.

See references/qa-categories.md for full question sets per category.

Category summary:

Adaptive behavior:

• Ask 2-4 questions per category (not all at once — batch by relevance)
• After each answer, decide: go deeper, move to next category, or trigger research loop
• When answer reveals uncertainty: pause, research (read code, docs, URLs), return with informed follow-up

Phase 3: Research Loops

When the interviewee mentions something that requires verification:

1. Read codebase (project structure, API routes, test files, configs)
2. Navigate URLs via Playwright MCP (if a live app exists)
3. Read documentation files in the project
4. Return with specific, informed follow-up questions

Phase 4: Conflict Resolution

Identify and resolve conflicts in stated requirements:

• Scope vs timeline conflicts ("we want full coverage in 2 days")
• Priority misalignment (everything is "critical")
• Unrealistic automation expectations
• Missing infrastructure for stated testing types

See references/conflict-patterns.md for common patterns and resolution strategies.

Phase 5: Completeness Check

Before generating the brief, verify all critical areas are covered. See references/completeness-checklist.md.

Phase 6: QA Brief Generation

Generate the structured QA Discovery Brief using templates/qa-brief-template.md.

Output

QA Discovery Brief (markdown) — the primary handoff document. Contains:

• Project/product overview
• Testing scope and objectives
• Critical user flows and scenarios
• Technical constraints and environment
• Risk assessment and priorities
• Compliance requirements
• Recommended testing types and approach
• Team and infrastructure summary

This brief feeds directly into: qa-requirements-generator, qa-spec-writer, qa-plan-creator, qa-test-strategy.

MCP Tools Used

• Sequential Thinking MCP: Structured reasoning during deep dive and conflict resolution
• Playwright MCP: Research loops — navigate live app to verify answers
• Filesystem MCP: Research loops — read codebase, docs, configs
• Memory MCP: Persist interview state for multi-session interviews

Scope

Can do (autonomous):

• Conduct full discovery interview through all 6 phases
• Adapt question depth based on answers
• Research codebase and live app during interview
• Generate structured QA Discovery Brief
• Serve as embedded service for other skills

Cannot do (requires confirmation):

• Make scope decisions on behalf of stakeholders
• Set final priorities without stakeholder input
• Skip categories the user explicitly wants to discuss

Will not do (out of scope):

• Write test code or create test cases (hand off to downstream skills)
• Modify production systems
• Make business decisions about product direction

Quality Checklist

• All 8 QA categories addressed (or explicitly marked N/A with rationale)
• Critical user flows identified and documented
• Risk areas ranked by business impact
• Technical stack and constraints captured
• Testing type recommendations align with project context
• Compliance requirements identified (or confirmed none apply)
• No ambiguous or conflicting statements in final brief
• Brief is sufficient for downstream skills to operate without additional input

Troubleshooting