开发完成后才编写的验收标准并不是验收标准。它们只是查看结果时形成的意见，无法解决任何问题。
在开发之前编写标准
验收标准描述了你将如何判断一项功能已经完成，而且必须在功能开发之前就存在，原因有两个：开发人员需要知道开发目标是什么，客户也需要一套不受结果影响的标准。
可用的标准应当具体且可测试：
- 较弱：“搜索应该运行良好。”
- 可用：“按客户姓名搜索时，应在两秒内返回匹配记录，支持部分姓名匹配，并且不区分大小写。”
任何人都可以测试第二条。第一条根本无法测试。
执行能够发现真实问题的 UAT
以“看一看并告诉我们你的想法”为方式进行的用户验收测试，只能发现外观问题，却会遗漏真正重要的问题。建立结构能极大改善测试效果。
- 按工作流程测试，而不是按屏幕测试。 从头到尾走完真实用户执行的完整任务。缺陷往往存在于屏幕之间的衔接处，而不是屏幕本身。
- 使用真实的数据。 包括较长的姓名、带重音符号的字符、空的可选字段、大数量值，以及处于月份和年份边界的日期。干净的测试数据会掩盖大多数输入处理问题。
- 有意测试失败路径。 连续提交表单两次。连续五次输入错误密码。在操作进行到一半时断开连接。这些路径正是实际用户会遇到的情况，也是测试很少覆盖的地方。
- 让实际用户进行测试。 每天使用系统的人能发现项目发起人永远发现不了的问题，因为他们了解实际工作究竟涉及什么。
- 将每一项发现记录在同一个地方，并附上复现步骤和截图。无法复现的发现就无法修复。
缺陷还是变更
每次 UAT 都会产生一些并非缺陷的问题，公平地对它们进行分类，才能避免流程变成对立局面。
缺陷是已达成一致的内容与实际开发结果之间的差异。由开发人员承担修复成本。
变更是功能按照约定运行，但已经不符合客户当前需求的情况。需单独报价。
客户经常会将第二种情况视为缺陷，因为软件的行为出乎他们的预期。诚实的应对方式不是争论标签，而是指出双方已同意的标准，然后询问这项变更是否值得实施。很多变更最终并不值得。
严重程度：决定哪些问题会阻碍上线
并非每个缺陷都必须在正式上线前修复，将所有缺陷都视为上线阻碍，只会无益地延迟上线。可以预先约定一个简单的三级分类：
- 阻断级 — 核心工作流程无法完成、数据丢失或损坏，或存在安全问题。必须在上线前修复。
- 重大 — 功能运行不正确，但存在替代方案。如果时间允许，应在上线前修复；否则安排日期后再处理。
- 轻微 — 外观问题、措辞问题或小的不一致。集中到上线后的版本中处理。
在 UAT 开始前就同意这一分类，可以将关于紧迫性的争论转变为共同评估。
签字确认意味着双方承担什么
签字确认应当具有明确含义：已满足约定的标准，未完成的轻微事项已列明并注明日期，同时释放付款里程碑。签字确认会启动质保期，在此期间发现的缺陷将免费修复。
这并不意味着客户以后永远不能再次报告问题，而暗示这一点的合同是不合理的。质保期所覆盖的，正是合理的 UAT 本应无法发现的缺陷。
应预留的时间
UAT 的计划时间始终不足。对于小型项目，应预留一到两周——这足以让实际用户结合日常工作进行测试、修复发现的问题，并完成重新测试。
将其压缩到两天，只会产生毫无意义的签字确认；问题反而会在正式使用的第一周暴露出来，届时修复成本更高，也更加显眼。
相关 Manboo 服务
- Flutter 应用开发，适用于 iOS 和 Android MVP。
- 业务软件开发，适用于 CRM、预订、库存和工作流系统。
- 管理后台开发，适用于运营仪表板和后端管理。
- AI API 集成，适用于产品准备加入智能搜索、聊天或自动化功能的情况。
- 申请范围评审和项目报价，适用于准备规划第一个版本的情况。