acceptance-testing

This skill acts as a user-focused test engineer to bridge the gap between abstract requirements and functional validation. It focuses on testing user-visible outcomes rather than internal implementation details, ensuring that the software fulfills its intended purpose from the end-user's perspective. It is designed for developers and QA engineers who need to convert user stories, requirement IDs, and release goals into actionable acceptance criteria and test plans. By applying a structured testing approach, it helps maintain high-value test suites that are both reproducible and reliable, preventing regressions in production.

• Derives comprehensive acceptance criteria including positive, negative, and non-functional requirements (e.g., latency, accessibility, error handling).

• Supports both manual UAT and automated E2E testing workflows, adapting to project constraints.

• Standardizes test documentation using formats like Gherkin or plain checklists for clarity.

• Recommends technology-specific automation defaults: Playwright/Cypress for Web/WASM UI, and golden/snapshot testing (e.g., insta) for Rust CLI tools or APIs.

• Provides standardized templates for UAT plans, sign-off checklists, and bug reports to ensure consistency across development cycles.

• Inputs required: User stories or requirement IDs, target interface (UI/CLI/API/Library), available environment details, and current testing toolsets.

• Outputs provided: A runnable test strategy, defined scenarios, environment-specific test data seeds, and a formal sign-off checklist.

• Constraint: Prioritize high-value scenarios to avoid brittle test suites; ensure all failures are reproducible by pinning specific commits and environments.

• Practice: Avoid testing implementation internals; if a tool is already present in the repository, extend it rather than introducing new frameworks without justification.