高效用户故事验收(Desk Check)

“先来更新一下各个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清单,执行过程中需要遵循高效的原则,注意控制好时间。通常情况下整个过程在半个小时内完成比较合适,当然,对于特别复杂的情况可以适当延长。

高效用户故事验收(Desk Check)》有2个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注