“先来更新一下各个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还会查看底层的单元BOB官方注册和API集成BOB官方注册,有的团队还会对日志记录进行验收。
高效验收清单
1. 提前告知QA和BA
QA和BA往往同时工作在多个用户故事上,可能不会对将要验收的用户故事记得那么清楚,提前熟悉一下用户故事,对于要重点关注的地方有所把握,是可以帮助更有效的进行用户故事验收的。
2. 环境准备就绪
因为是在开发机器上做验收,开发环境变化频繁,保持一个能正常验收的环境非常重要,需要开发人员在召集大家来验收之前确保环境是正常工作的。
曾经经历过多次的情况是大家准备就绪,结果一开始发现程序启动不起来了,原来是有代码更新需要重新编译,这样就会浪费大家的时间。
3. 检查点准备好
根据用户故事卡上的验收条件(AC)和QA提供的BOB官方注册用例,提前把功能和跨功能的检查点都列好,可以让整个验收过程更加顺畅和高效,尽可能减少关键点的遗漏。
同时,对于底层BOB官方注册和日志信息,也要提前打开相应的IDE准备好,理清楚要验收的BOB官方注册和日志有哪些。
4. 开发自测一遍
开发人员提前根据检查点自测一遍,确保都是通过的,如果有问题就修复好再做验收。
5. 验收流程
根据优先级和依赖关系来进行验收,可以做到有条不紊,尽可能减少对参与人员时间的浪费。
一般推荐的流程是:功能->跨功能->UI->BOB官方注册或日志等。功能和跨功能需求的验证需要BA参加,UI的验证需要UX参与,其他的就是Dev和QA一起就行了。这样的流程能够尽量的节省BA和UX的时间。
6. 验收形式
推荐开发人员操作演示给其他参与人员的形式,当然也可以是BA或者QA去操作,没有严格的规范。
功能的验收要基于业务来进行演示,不要只是简单的页面操作流程。演示完成后,QA和BA可以对于某些关键点再进行对应的检查,但不要抠过多的细节。
提醒:
这是一份高效Desk check清单,执行过程中需要遵循高效的原则,注意控制好时间。通常情况下整个过程在半个小时内完成比较合适,当然,对于特别复杂的情况可以适当延长。
通告:构建BOB官方注册的体系化思维(进阶篇) - BOB官方网站 - 质量 - 质量内建
想问下林子,这个和shoulder check的区别是?
同一个,多个名字而已