今日洞见

文章作者来自ThoughtWorks：曲正平。图片来源于网络。

本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。

在推广敏捷的过程中，虽然ThoughtWorks有过很多应用的经验，但是当我们把一个实践介绍给其他人，总会遇到为什么要这样做的问题。在带领大家做之前，口头上的介绍和说服工作是必不可少的，毕竟这是给团队成员打消疑虑，树立信心，建立目标的一个过程。做到团队的每个成员都理解了这个实践的意义，对实践的执行就能很容易的达到要求。否则，团队执行的人很难心悦诚服的执行，结果就是这一环节会很快被大家无视，慢慢消亡了。

说起来deskcheck是一个非常简单的事情，但是越简单的东西，越难以引起团队成员的重视。下面我会通过之前参与过的一个项目的总结，来分析一下我们没有做desk check的时候产生的浪费，以及各参与角色在一个标准的desk check中的职责。

我们先来看看在没有这个环节的情况下，一个issue从这里启程进入下一阶段会产生多大的破坏力和消耗团队多少生产力。

Developer在完成开发工作后，测试打包包含这个issue的应用，Smoke test需要一定时间，因为smoke test主要包含以往功能的主干测试，也许包含你刚开发的功能，但是基于你的理解可能也是错误的测试，所以这个测试运行完肯定是通过的。（我们的产品打包和运行完smoke test需要至少15分钟。）

Issue随部署进入测试阶段。（我们通过pipeline部署需要30分钟。）

测试人员需要准备测试环境（OS，Test data，很多时候测试数据在使用之后就不能再用了，除非有完善的脚本。有时候有些功能跟时间或者日期相关，半个小时或者第二天就会失效，比如一些scheduled jobs，下次也需要重新创建。）

然后测试人员执行测试：Scenario 1,2,3,4,5,6。我们在执行到Scenario 5的时候发现了这个issue，之后停止测试将issue提交bug track system。

Issue需要被PM或者PO等Stakeholder分析，排定优先级之后，返回开发团队。此时之前工作在包含此issue的功能的那对developer已经工作在其他的任务上了，不管是等待当事人来修复还是找空闲的人员来修复，都需要一定的等待时间或者了解上下文的时间。

当此issue成功被修复之后，测试人员仍然需要准备测试数据，重复测试Scenario 1,2,3,4,5,6。这样才能确保这个功能在所有的情景下满足需求，而不可能从上次出问题的scenario开始。

如果有desk check，这个流程会变成什么样子呢？

我们不需要跑Pipeline进行部署, 发现的问题不需要提交到bug track system，所以也不需要后期的bug triage。

如果同样的issue在Desk Check的过程中被发现，developer会马上开始修复这个漏洞并为之创建test，保证此问题不会再次发生。

所以，标准的Desk Check该怎么做？

开发人员在完成需求之后，快速在本地开发环境建立功能验证条件。

开发人员要做的具体工作是：需要测试数据的，建立mock data；然后对照Acceptance Criteria给团队的BA、QA展示完成的功能。这里需要注意的是，开发人员最好自己先完成一遍测试。自测能够发现一些问题，提高deskcheck的成功率，也吻合越早发现问题修复的代价越小的原理，否则不但耽误了自己的时间也耽误了BA和QA的时间。

BA的职责是：验证开发之前提出的需求是否实现，是否有跟开发人员理解不一致的地方，是否有遗漏的需求。

QA的职责是：从测试人员的视角评估这个功能有没有“ready for testing”，并且做一个快速的测试，验证是否有Sad Path没有考虑周全。

不管怎么说Desk Check还是处于developing的阶段，在这个阶段矫正一下需求，修复一些快速的defects，这样才能让功能ready进入下一个阶段：测试环境的测试。

之前一直错误地理解Desk Check是我们开发流程的一部分，是流程上的一个要求。但是结合最近项目的实践和敏捷宣言的理论，意识到Desk Check实际上是践行了宣言的第一条：个体之间的合作，而且合作比流程更重要。Desk Check同时也体现了反馈在敏捷开发中的作用，及时的反馈能够尽早的纠正工作的偏差，让我们一直向正确的方向前进。