References: Gojko Adzic, Specification by Example; Dan North, BDD; Cucumber/Gherkin; ISTQB Foundation.
Applicable Scenarios
- Feature development is complete and business-side acceptance is needed
- UAT（User Acceptance Testing）
- Pre-launch sign-off
- Dry run before a customer demo
- Contract / SLA acceptance
Core Principles
1. 验收 = 业务方签字
不是"QA 测过"，是"PM/业务/客户认为达标"
-
Given-When-Then as a common language The business side can understand it, developers can implement it, and QA can verify it
-
One scenario, one story Do not have "one acceptance cover 5 flows"
-
Acceptance criteria come from the PRD They are not added ad hoc by QA; they are defined during the requirements phase
-
All P0 / P1 bugs closed before acceptance Do not bring bugs into the acceptance meeting
## Given-When-Then 标准格式
```gherkin
功能：订单退款
场景：用户对已支付订单发起全额退款
Given 用户 user_a 有一个订单 ORD-123
And 订单状态为 paid
And 订单金额为 100 USD
When 用户在订单详情页点击 "申请全额退款"
And 选择退款原因 "商品有质量问题"
And 点击 "确认退款"
Then 订单状态变为 refunded
And 用户余额增加 100 USD
And 用户收到退款成功的邮件通知
And 系统记录退款审计日志
Acceptance Criteria vs Test Cases
| Dimension | Acceptance Criteria | Test Cases |
|---|---|---|
| Audience | Business side / PM / customer | Development / QA |
| Language | Business language | Technical language |
| Quantity | Few (covering business rules) | Many (covering technical details) |
| Phase | Defined during the requirements phase | Written during the testing phase |
| Pass Criteria | "The business considers it up to standard" | "Meets expectations" |
→ Acceptance criteria are the "constitution" of test cases; each acceptance criterion has at least 1 P0 test case
ATDD（Acceptance Test-Driven Development）
1. PRD 定义验收标准（PM + QA + Dev 共同评审）
↓
2. 验收标准转 Given-When-Then
↓
3. 开发按验收标准写代码 + 自动化验收测试
↓
4. 自动化验收测试通过 = 功能完成
↓
5. UAT 阶段业务方再验收一次（端到端）
Acceptance Types
Alpha Acceptance
- Internal team acceptance
- Usually immediately after development is complete
- Scope: correctness of core functionality
Beta Acceptance
- Real users participate (small scale)
- Scope: usability, user experience, edge scenarios
UAT（User Acceptance Test）
- Business side / customer participation
- Scope: business process completeness, compliance
Contract Acceptance
- Customer signs for confirmation
- Scope: all items listed in the contract / SLA
Acceptance Execution Process
1. 准备阶段（验收前 2~5 天）
□ 所有功能已开发完
□ 所有 P0 / P1 Bug 已关闭
□ Sanity 套件 100% 通过
□ 验收环境数据准备
□ 验收账号准备
□ 验收会议安排
↓
2. 验收会议（30 分钟 ~ 2 小时）
□ PM 介绍变更范围
□ QA 演示主路径
□ 业务方按 Given-When-Then 走查
□ 业务方提问 / 提改进建议
↓
3. 验收结论
□ 通过：可上线
□ 有条件通过：列出限制 / 后续改进
□ 不通过：返工
↓
4. 记录
□ 验收会议纪要
□ 改进项跟踪
□ 业务方签字确认
↓
5. 上线
Acceptance Meeting Minutes Template
# UAT 会议纪要
## 基本信息
- 日期：
- 主持：
- 参与：[PM, QA, 业务方代表]
- 验收范围：[功能清单]
## 验收清单（按 PRD 验收标准）
| # | 验收标准 | 状态 | 备注 |
|---|---------|------|------|
| AC1 | 用户能成功创建订单 | ✅ | |
| AC2 | 库存不足时给出明确提示 | ✅ | |
| AC3 | 支持微信 / 支付宝两种支付方式 | ⚠️ | 支付宝需要补充 |
## 业务方反馈
- [改进建议 1]
- [改进建议 2]
## 已知问题（业务方知悉，不阻塞上线）
- [问题 + 影响 + 计划修复时间]
## 验收结论
- [ ] 通过
- [ ] 有条件通过（条件：...）
- [ ] 不通过（原因：...）
## 签字
- 业务方：
- PM：
- 日期：
Acceptance Data Preparation
真实数据：
- 真实用户场景模拟
- 涵盖典型业务规模
- 包含各种状态（新 / 老 / 异常）
边界数据：
- 最大订单
- 最小订单
- 跨年订单
- 多币种订单
环境：
- 与生产相似（数据规模 / 配置 / 第三方）
- 但隔离（不污染生产）
"Business Traps" During Acceptance
1. PRD 没写但"理所当然"
- 业务方会临时提出"这个不是应该 XXX 吗"
- 应对：UAT 前再核对一遍 PRD
2. 边缘业务场景
- 业务方知道但没写进 PRD
- 应对：让业务方写"业务异常清单"
3. 性能 / 体验感受
- "感觉慢" / "操作不顺"
- 应对：定量化（X 秒内 / Y 步内）
4. 合规 / 审计要求
- 业务方知道但开发不知道
- 应对：PRD 中加 "合规要求" 章节
Quality Self-Check
□ 每条 PRD 验收标准都有 Given-When-Then
□ 验收标准 PM/QA/Dev 共同评审过
□ 验收前所有 P0 / P1 Bug 关闭
□ Sanity 套件通过
□ 验收数据准备充分
□ 验收账号准备好
□ 验收会议有纪要
□ 业务方签字确认
□ 已知问题列表清晰
□ 改进项跟踪到位
Common Pitfalls
- Acceptance = test it again——No, acceptance is the business side "signing off"
- Vague acceptance criteria——"easy to use / friendly / efficient" cannot be verified
- PM does not participate in defining acceptance criteria——QA writes them alone, and the business does not accept them
- Bringing P0 bugs into acceptance——Wastes the business side's time
- Raising new requirements on the spot during acceptance——Should go through the change process
- No Given-When-Then——The business side does not understand
- Meeting minutes not signed——No basis for later disputes
- Acceptance data is not real——The business side says "it doesn't work in our real scenarios"
- Not preparing boundary data——Only demonstrating the main path
- Improvements not tracked— forgotten after acceptance
Supporting templates
templates/acceptance-criteria-template.md— acceptance criteria + Given-When-Then scenarios + UAT meeting minutes + sign-off template
Collaboration with other skills
上游：
产品经理工作流（PRD） → 验收标准
test-case-design → 用例覆盖每条验收标准
regression-testing → Sanity 通过
平行：
exploratory-testing → 业务方探索式
下游：
bug-reporting → 验收发现的问题
test-report → 验收结论纳入报告
quality-gate → 验收通过 = 放行条件之一
上线流程