“先来更新一下各个team近一周发生的事情吧。”又到了每周的QA catch up时间，今天是轮到玥玥主持会议。

“我先说吧，我们这一周刚完成一件大事！”我忍不住抢先说。

“什么大事？”大家都很好奇。

“就是上次说过的新增一种工单类型的feature，昨天刚刚完成了story的desk check（用户故事验收）。”

“听说那个影响到了整个企业系统？”

“差不多吧。desk check就做了两个小时。”我说。

“是看到你们做了好久！上次我们有个story做了快一个小时，我都快要崩溃了！你们竟然更久……”小慧之前就给我们说过她那次痛苦的Desk Check经历。

“我们这次时间虽久，但是感觉做的挺好的，已经很高效了。时间长是因为实在是太复杂了。这次Dev很给力，准备工作做的很好，整个desk check过程也很有条理，非常顺畅。”我解释道。

“这种情况可能比较少见。正好今天没有特别的分享话题，咱们先更新完各个组的情况，林子你再给我们详细分享一下昨天的Desk check，咱们还可以可以讨论一下如何能让Desk check做的更好。”玥玥说。

“这个主意不错！”大家都表示同意。于是，结合我的分享和大家的补充，有了如下内容。

关于Desk Check

Desk Check是Dev在开发完用户故事之后，流到下一个环节之前对于价值、方案和AC（验收条件）等的一个快速确认。

一般都是在开发人员的座位上利用开发机器来完成，这也是名字为Desk check的原因。

参与Desk Check的人员有BA（业务分析师）、Dev（开发）和QA，有时候也会有UX（用户体验设计师）。

Desk check的内容包括功能、性能、安全、UI布局等，QA还会查看底层的单元测试和API集成测试，有的团队还会对日志记录进行验收。

高效验收清单

1. 提前告知QA和BA

QA和BA往往同时工作在多个用户故事上，可能不会对将要验收的用户故事记得那么清楚，提前熟悉一下用户故事，对于要重点关注的地方有所把握，是可以帮助更有效的进行用户故事验收的。

2. 环境准备就绪

因为是在开发机器上做验收，开发环境变化频繁，保持一个能正常验收的环境非常重要，需要开发人员在召集大家来验收之前确保环境是正常工作的。

曾经经历过多次的情况是大家准备就绪，结果一开始发现程序启动不起来了，原来是有代码更新需要重新编译，这样就会浪费大家的时间。

3. 检查点准备好

根据用户故事卡上的验收条件（AC）和QA提供的测试用例，提前把功能和跨功能的检查点都列好，可以让整个验收过程更加顺畅和高效，尽可能减少关键点的遗漏。

同时，对于底层测试和日志信息，也要提前打开相应的IDE准备好，理清楚要验收的测试和日志有哪些。

4. 开发自测一遍

开发人员提前根据检查点自测一遍，确保都是通过的，如果有问题就修复好再做验收。

5. 验收流程

根据优先级和依赖关系来进行验收，可以做到有条不紊，尽可能减少对参与人员时间的浪费。

一般推荐的流程是：功能->跨功能->UI->测试或日志等。功能和跨功能需求的验证需要BA参加，UI的验证需要UX参与，其他的就是Dev和QA一起就行了。这样的流程能够尽量的节省BA和UX的时间。

6. 验收形式

推荐开发人员操作演示给其他参与人员的形式，当然也可以是BA或者QA去操作，没有严格的规范。

功能的验收要基于业务来进行演示，不要只是简单的页面操作流程。演示完成后，QA和BA可以对于某些关键点再进行对应的检查，但不要抠过多的细节。

提醒：

这是一份高效Desk check清单，执行过程中需要遵循高效的原则，注意控制好时间。通常情况下整个过程在半个小时内完成比较合适，当然，对于特别复杂的情况可以适当延长。