acceptance-testing
Skill1 starsChanged 53 days agoMITView on GitHub
Use when validating a feature against business needs before release — user acceptance testing (UAT), alpha/beta programs, acceptance criteria, sign-off, contract/operational acceptance, and "is this ready for the customer?" decisions.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Abdox-menara/guard-skillstheir own version, first seen Aug 24, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Abdox-menara/guard-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository98 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- 42crunch-api-security-testingSkill
- a-b-testingSkill
- accessibility-testingSkill
- ai-agent-evaluationSkill
- ai-code-securitySkill
- ai-ml-testingSkill
- analytics-tracking-testingSkill
- api-testingSkill
- authn-authz-testingSkill
- autonomous-qa-orchestrationSkill
- bdd-gherkin-testingSkill
- blockchain-smart-contract-testingSkill
- bug-reportingSkill
- chaos-resilience-testingSkill
- chatbot-voice-agent-testingSkill
- cicd-testingSkill
- cli-testingSkill
- cloud-infrastructure-testingSkill
- code-coverage-analysisSkill
- compatibility-testingSkill
- compliance-testingSkill
- concurrency-race-condition-testingSkill
- configuration-feature-flag-testingSkill
- contract-testingSkill
- cross-browser-testingSkill
- database-testingSkill
- data-migration-testingSkill
- data-pipeline-etl-testingSkill
- date-time-timezone-testingSkill
- desktop-app-testingSkill
- disaster-recovery-backup-testingSkill
- e2e-testingSkill
- email-notification-testingSkill
- event-driven-messaging-testingSkill
- exploratory-testingSkill
- flaky-test-managementSkill
- functional-testingSkill
- fuzz-testingSkill
- game-testingSkill
- graphql-testingSkill
- iac-container-security-testingSkill
- installation-upgrade-testingSkill
- integration-testingSkill
- iot-embedded-testingSkill
- llm-security-auditSkill
- llm-testingSkill
- localization-testingSkill
- manual-testingSkill
- mcp-testingSkill
- memory-leak-resource-testingSkill
- microservices-testingSkill
- mobile-testingSkill
- mutation-testingSkill
- observability-testingSkill
- payment-ecommerce-testingSkill
- performance-testingSkill
- production-monitoring-synthetic-testingSkill
- property-based-testingSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Use: pre-release sign-off, contract milestones, regulated releases, customer pilots, beta programs.
- Very specific: line 17
Don't use it to find low-level bugs — that is unit/integration/system testing.
- Distinctive: line 35
Exit / sign-off: all Must criteria pass, zero open Sev1/Sev2, agreed workarounds documented for Sev3, formal sign-off recorded (name, date, …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Acceptance Testing (UAT, OAT, Alpha/Beta)
Acceptance testing answers one question: does the system let the business/user do the job they bought it for? Verification ("built right") is done by then; this is validation ("built the right thing").
When to use / not use
- Use: pre-release sign-off, contract milestones, regulated releases, customer pilots, beta programs.
- Don't use it to find low-level bugs — that is unit/integration/system testing. A UAT that finds 50 crashes means earlier levels failed.
The five acceptance types
| Type | Who | Question |
| UAT | Business users / product owner | Does it support real workflows? |
| OAT / Operational | Ops, SRE | Can we deploy, monitor, back up, restore, upgrade it? |
| Contractual | Customer + legal | Are the contract's acceptance criteria met? |
| Regulatory | Compliance | Does it satisfy the applicable regulation/standard? |
| Alpha / Beta | Internal / external early users | Does it survive real usage & real data? |
Workflow
- Collect acceptance criteria from stories/contracts. Rewrite each as a testable statement (Given/When/Then, measurable threshold). Reject vague ones ("fast", "user-friendly") and ask for numbers.
- Define entry criteria: system test passed, no open Sev1/Sev2, test data + UAT environment ready, testers trained.
- Build the UAT scenario set from real end-to-end business processes — not from the UI screens. One scenario = one user goal, start to finish, with realistic data.
- Trace: map every acceptance criterion → ≥1 scenario (see
test-planning-documentationfor RTM). - Execute with business users, time-boxed. Capture evidence (screenshots, recordings, data before/after).
- Triage defects live: defect vs change request vs misunderstanding (training gap). Only defects block sign-off.
- Exit / sign-off: all Must criteria pass, zero open Sev1/Sev2, agreed workarounds documented for Sev3, formal sign-off recorded (name, date, version/build).
Scenario template
ID: UAT-014 Priority: Must Criterion: AC-7 (refund within 5 min)
Persona: Support agent, EU region
Pre-state: Order #A-991 paid, shipped, within 30-day window
Steps: 1) Open order 2) Issue partial refund 40% 3) Confirm customer email
Expected: Ledger shows -40%; email sent < 5 min; audit log has agent ID
Evidence: recording + ledger export Result: PASS / FAIL / BLOCKEDBeta program checklist
- Feature flag + kill switch; % rollout (1 → 5 → 25 → 100).
- Feedback channel in-product; telemetry for errors, funnels, latency.
- Explicit exit metrics (crash-free sessions ≥ 99.5%, task success ≥ 90%, NPS trend).
Pitfalls
- Testers who were never trained → false failures. Run a 30-min walkthrough first.
- Testing on synthetic/empty data → misses real-world volume and edge data. Use masked production-like data (
test-data-engineering). - Sign-off by someone with no authority. Record the accountable approver up front.
- Scope creep: new asks discovered in UAT go to the backlog, not the release gate.
Related skills
bdd-gherkin-testing, test-planning-documentation, release-readiness-testing, usability-testing, system-testing
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

