What
Desk check是敏捷开发实践中的一环，发生在某一feature开发完毕后、进入测试环节之前，主要目的是为了对刚刚开发完成的feature进行初步验收，减少后续返工的风险。方便起见，之后直接使用其简写DC进行替代。
Why
为了突出DC的重要性，我们可以想象一下如果没有DC环节，后续会遇到什么麻烦。
某个feature开发完毕后，直接部署到测试环境由QA进行测试，QA需要在测试环境创建各种测试用例进行测试，中途发现功能存在不合适或者bug的情况，于是把测试不通过的情况反馈给开发人员要求其进行修改，但是此时开发人员已经在做其他的功能了，此时要不打断对方，要不找另一个开发进行修改不过需要给对方重新同步上下文，等到修改完毕后，QA又要再次部署到测试环境并且创造测试用例重新进行测试。由此可见，没有DC环节的话，开发出的feature的验收闭环过于冗长，导致人员的时间和精力浪费，效率低下。
由此可见，DC其实就是软件交付过程中一个提前验收的小动作，目的是缩短feature验收闭环的时间，提高交付的效率。
When
某功能开发完毕之后，QA进行测试之前。
Who
必须参加的人员：开发该功能的Dev，BA和QA；
可选人员：UX
How
DC一般由Dev来进行演示，QA和BA进行引导和补充。由于我的角色是BA，所以就只从BA的角度和职责来写一写DC前、DC时和DC后BA都需要准备和做些什么。
DC前
- 在故事卡开发的过程中就可以先开始准备一些DC要用到的测试用例（虽然测试人员更应该来做这个事情，不过多写一些也可以锻炼BA的逻辑思维）；
- 在故事卡快开发完成的时候，协同测试人员一起创造一些DC要用到的数据，以免DC的时候无法验证某些场景；
- 让开发人员在DC前的半个小时或十五分钟提前通知自己和测试人员，这样大家可以先提前再次熟悉一下准备DC的内容，顺便找出之前准备好的测试用例；
- 提醒开发人员在DC前检查一下测试环境准备就绪。
DC时
- 主要验收内容：功能->跨功能->UI->测试或日志（作为一个小白，项目上只顾着验收功能了，后面的三种情况以后有了更多经验再来好好写写具体内容）；
- DC成功的标准是故事卡中的所有AC必须全部验收成功（测试用例没有通过的情况能不能算成功DC，我也不去清楚，经验多了后来补充吧）。
DC后
- DC成功：提醒开发人员及时拖卡。
- DC失败：不能拖卡，待开发人员修复之后再次进行DC。
其他
后端DC时先熟悉好后端接口work后所代表的业务流程是什么，开发人员演示时注意根据接口文档的内容一一验证参数的请求和返回，并且每演示一个示例后都要和开发人员确认该演示对应的业务流程是什么。
|