CRM 上线 UAT 检查清单

UAT 之前

大多数出问题的 UAT 都出在这一阶段：范围不清、脚本没人审核、测试人员没有可用的账户。

范围

• 商定哪些流程和用户故事纳入 UAT，并写明哪些不纳入。
• 为每个流程指定一名来自业务部门的负责人：即负责签核的人。
• 在记录第一个问题之前，商定 Critical、High、Medium 和 Low 的含义。

测试用例

• 每个业务场景写一个测试用例，用测试人员自己的话来写。
• 为每个步骤写明操作和预期结果，必要时附上测试数据。
• 将每个测试用例标记为 Must、Should 或 Could，以便先测试重要的用例。
• 加入异常路径：错误的值、缺失的字段、没有正确角色的用户。
• 检查范围内的每个用户故事都至少有一个测试用例。
• 在测试日之前，请业务部门的一名关键用户审核脚本。

测试人员

• 从使用该系统的每个团队中，挑选每天从事这项工作的人作为测试人员。
• 为每位测试人员分配一个分组和各自的脚本。
• 在他们的日历中预留测试日，并让他们脱离日常工作。
• 用半小时向他们说明：如何记录结果，以及如何记录问题。

环境和测试数据

• 准备一个与生产环境一致的测试环境：配置、集成和数据。
• 为每个角色创建测试账户，并检查每个账户都能登录。
• 加载测试数据：客户、产品、价目表和未完成的记录。
• 尽可能使用测试数据，而不是客户数据。
• 商定测试日期间何时将修复部署到测试环境。

日程

• 按时间段规划测试日，每天固定一个时间进行分诊。
• 为修复之后的复测轮次预留时间。
• 确定 go/no-go 会议的日期，并立即邀请指导委员会。
• 查看 Salesforce 或 Dynamics 365 的版本发布日历：在 UAT 期间发生的平台版本发布会改变您测试的内容。

准入标准

• 系统测试已完成，且其中没有仍未解决的 Critical 缺陷。
• 测试环境、测试账户和测试数据已准备就绪。
• 业务部门已审核测试用例。
• 每位测试人员都已收到邀请，并至少登录过一次。

UAT 期间

让每天的节奏紧凑，信息集中在一处，使问题在同一天内被发现、决定和修复。

每日站会

• 每天以十五分钟开始：测了什么，什么受阻，今天计划做什么。
• 将每个分组的进度与计划进行对比，并把测试人员调配到需要的地方。

记录问题

• 每个问题单独记录一条，写明步骤、预期结果以及实际发生的情况。
• 附上截图和记录链接。
• 先查找是否已有相同的问题，避免重复记录。
• 确保每个失败的步骤都有对应的问题，或者说明没有的原因。

分诊

• 每天与业务部门和开发团队一起进行分诊。
• 为每个新问题确定严重程度、优先级和负责修复的人。
• 对每个问题做出决定：修复、拒绝，或转为变更请求。
• 将变更请求放入待办列表，而不是纳入本次发布。

复测

• 修复部署后，由发现该问题的测试人员进行复测。
• 记录每次复测所基于的版本和构建。
• 在较大的修复之后开始新的测试轮次，并重新测试与修复相关的流程。

结束 UAT

UAT 以一个决定结束。依据事实做出决定，并记录谁决定了什么。

退出标准

• 每个 Must 测试用例都已通过。
• 没有未解决的 Critical 问题。
• 每个未解决的 High 问题都有业务部门接受的变通方案或修复日期。
• 范围内的每个测试用例都有结果。

签核

• 请每个流程的负责人签核：接受、有条件接受或拒绝。
• 记录每个条件，以及由谁负责、何时完成。

Go/no-go

• 召开 go/no-go 会议时把数据展示在屏幕上，而不是凭记忆。
• 记录决定、条件以及做出决定的人。

报告

• 说明哪些在范围内，哪些没有测试。
• 按分组和优先级展示结果，以及所测试的版本和构建。
• 按严重程度列出未解决的问题，并附上对每个问题的决定。
• 附上各项签核及其条件。
• 列出上线后最初几周的已知风险和变通方案。

上线之后

• 保留测试用例：它们就是下一次 CRM 版本发布的回归测试。
• 趁记忆犹新，记下下一次 UAT 中要改进的地方。