Validate feature qa

Validate Feature QA

Outcome

Produce a comprehensive QA validation package for a feature implementation, including:

• End-to-end test execution evidence (Playwright MCP)
• WCAG 2.2 accessibility verification results
• Visual analysis findings with screenshots
• Bug records with reproducible steps and severity
• A final QA report with readiness verdict

When to Use

• User asks to run QA on a feature
• User asks to validate implementation completeness
• User asks to verify behavior against PRD, tech spec, and tasks

Do Not Use

• Performing code review
• Implementing fixes or patching defects
• Executing task implementation work

Required Inputs

• Feature name or target area
• PRD path/content
• Tech spec path/content
• Task artifacts (tasks.md and relevant task files)
• Test environment URL or run instructions
• Optional accounts/test data and browser/device constraints

Workflow

1) Resolve Scope and Acceptance Baseline

Extract what must be validated from PRD, tech spec, and tasks.

Capture:

• Functional requirements (FR-*) and constraints
• Non-functional expectations (NFR-*)
• Task acceptance criteria and definition of done
• Explicit out-of-scope boundaries

Decision points:

• If any core artifact is missing (PRD, tech spec, or tasks), stop and request it.
• If artifacts conflict, log ambiguity and request clarification before final verdict.

2) Build QA Coverage Matrix

Create a traceable checklist mapping requirements to tests.

Include:

• Requirement ID -> test scenario(s)
• Task ID -> validation status
• NFR checks -> evidence method

Decision points:

• If requirements cannot be mapped to executable checks, raise testability gap.
• If tasks include incomplete dependencies, flag risk before running full suite.

3) Prepare Test Session

Prepare deterministic test preconditions.

Prepare:

• Environment health/smoke check
• Test accounts and seed data
• Browser coverage targets (minimum agreed set)
• Screenshot output location

Decision points:

• If environment is unstable, record as blocker and continue only with partial validation if feasible.
• If required data is unavailable, log blocked scenarios explicitly.

4) Run E2E Validation with Playwright MCP

Execute core user workflows and edge cases using Playwright MCP.

Run:

• Happy-path scenarios
• Negative and edge scenarios
• Regression-critical paths touched by feature changes

Evidence rules:

• Capture screenshots for failed checks and notable visual issues.
• Record exact scenario name, step, and observed vs expected behavior.

5) Perform Accessibility Verification (WCAG 2.2)

Validate accessibility conformance for impacted screens and flows.

Check at minimum:

• Keyboard navigation and focus order
• Focus visibility and logical tab sequence
• Form labels, names, roles, values
• Color contrast and non-text contrast
• Error identification and messaging
• Reduced motion and interaction clarity where applicable

Decision points:

• If severe accessibility blockers are found, mark feature as not ready.
• If checks are partially blocked by environment limits, document the gap and residual risk.

6) Perform Visual Analysis

Verify visual correctness and consistency across target states.

Check:

• Layout integrity and responsive behavior
• Content overlap, clipping, or truncation
• State-specific UI correctness (loading, empty, error, success)
• Cross-browser visual anomalies (if in scope)

Evidence rules:

• Attach screenshot evidence for each visual defect.
• Tag each issue with impacted viewport/browser context.

7) Document Bugs with Evidence

Create bug entries using Bug report template.

For each bug capture:

• Severity (Blocker, Critical, Major, Minor)
• Requirement/task traceability
• Reproduction steps
• Expected vs actual behavior
• Screenshot path(s)

8) Generate Comprehensive QA Report

Create final report using QA report template.

Report must include:

• Coverage matrix summary
• Pass/fail status by requirement and task
• Accessibility and visual findings
• Bug summary by severity
• Readiness verdict (Pass, Pass with Known Issues, Fail, Blocked)

Quality Check Before Finalizing

QA validation is complete only if:

• Every in-scope requirement/task has a mapped validation status.
• All discovered bugs are documented with reproducible steps.
• Every bug includes screenshot evidence where applicable.
• Accessibility checks explicitly reference WCAG 2.2 criteria.
• Residual risks and blocked checks are clearly listed.
• Final readiness verdict is justified by evidence.

Output Contract

Return a structured QA report in chat and optionally save markdown artifacts for the QA report and bug list using:

• QA report template
• Bug report template