# Feature Acceptance > Feature acceptance testing methodology and verification process Use when this capability is needed. - Skill: `tomevault-io/feature-acceptance` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/feature-acceptance` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/feature-acceptance/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/feature-acceptance --- # Feature Acceptance Systematic approach to verifying features meet requirements before release. ## Acceptance Criteria ### SMART Criteria Every acceptance criterion should be: - **Specific** - Clear, unambiguous requirement - **Measurable** - Verifiable pass/fail condition - **Achievable** - Technically feasible - **Relevant** - Tied to user value - **Testable** - Can be validated ### Given-When-Then Format ```gherkin Scenario: User creates a new project Given I am logged in as a user And I am on the dashboard When I click "New Project" And I enter "My Project" as the name And I click "Create" Then I should see "My Project" in my project list And I should be redirected to the project page ``` ## Testing Categories ### Functional Testing Verify the feature works as specified: - [ ] Happy path works correctly - [ ] All specified use cases covered - [ ] Input validation functions properly - [ ] Error handling works as expected - [ ] Edge cases handled appropriately ### Integration Testing Verify the feature works with existing systems: - [ ] API endpoints respond correctly - [ ] Database operations succeed - [ ] Third-party integrations work - [ ] Events/webhooks fire correctly - [ ] Cache invalidation works ### User Experience Testing Verify the feature is usable: - [ ] UI matches designs/mockups - [ ] Loading states are shown - [ ] Error messages are helpful - [ ] Accessibility requirements met - [ ] Responsive on all target devices ### Performance Testing Verify the feature performs acceptably: - [ ] Response times within SLA - [ ] No memory leaks - [ ] Handles expected load - [ ] Graceful degradation under stress ### Security Testing Verify the feature is secure: - [ ] Authentication required where needed - [ ] Authorization enforced - [ ] Input sanitization in place - [ ] No sensitive data exposed - [ ] Audit logging functional ## Acceptance Process ### 1. Pre-Review Developer self-check before review: ``` [ ] Code complete and tested [ ] Unit tests written and passing [ ] Integration tests passing [ ] Documentation updated [ ] No console errors/warnings [ ] Performance acceptable ``` ### 2. Peer Review Code review by team member: ``` [ ] Code quality acceptable [ ] Logic is correct [ ] Tests are comprehensive [ ] No security concerns [ ] Follows team conventions ``` ### 3. QA Review Formal testing by QA: ``` [ ] All acceptance criteria verified [ ] Edge cases tested [ ] Cross-browser/device testing [ ] Regression testing passed [ ] Test cases documented ``` ### 4. Stakeholder Review Product/design verification: ``` [ ] Matches requirements [ ] UX acceptable [ ] No scope creep [ ] Ready for users ``` ## Test Case Template ```markdown **Test Case:** TC-001 **Feature:** User Login **Scenario:** Successful login with valid credentials **Preconditions:** - User account exists - User is not logged in **Test Steps:** 1. Navigate to login page 2. Enter valid email 3. Enter valid password 4. Click "Log In" **Expected Result:** - User is logged in - Redirected to dashboard - Welcome message displayed **Actual Result:** [To be filled during testing] **Status:** [ ] Pass [ ] Fail **Notes:** [Any observations] ``` ## Defect Tracking ### Severity Levels | Level | Definition | Response | |-------|------------|----------| | Critical | System unusable, data loss | Fix immediately | | High | Major feature broken | Fix before release | | Medium | Feature impaired but usable | Fix soon | | Low | Minor issue, workaround exists | Fix when possible | ### Defect Template ```markdown **Title:** Brief description **Severity:** Critical/High/Medium/Low **Environment:** Browser, OS, version **Steps to Reproduce:** 1. Step one 2. Step two 3. Step three **Expected:** What should happen **Actual:** What actually happened **Screenshots:** [Attach if applicable] ``` ## Release Criteria ### Definition of Done Feature is complete when: - [ ] All acceptance criteria pass - [ ] No critical or high defects - [ ] Test coverage meets threshold - [ ] Documentation complete - [ ] Performance requirements met - [ ] Security review passed - [ ] Stakeholder sign-off received ### Go/No-Go Decision | Criterion | Status | Notes | |-----------|--------|-------| | Functional tests | ✅ Pass | All 24 scenarios pass | | Performance | ⚠️ Partial | 95% within SLA | | Security | ✅ Pass | No vulnerabilities | | Documentation | ✅ Pass | Updated | | Stakeholder | ⏳ Pending | Meeting scheduled | **Decision:** [ ] Go [ ] No-Go --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/iannil) — claim your Tome and manage your conversions.