，点击蓝字👆 关注Agilean，获取一手干货
导语
用例评审的作用已经不言而喻，但是在很多组织的实际落地过程中，却收效甚微。研发管理人员常常会发现即使做了用例评审，一些显而易见的问题还是会出现：缺陷逃逸、开发未适配、测试漏测等。
为什么会这样呢？问题大概率出在了用例评审过程中。
笔者在经历过众多用例评审实践后，发现实际评审中常常遭到忽视的两个要素。基于此，尝试以新的视角，为读者们提供用例评审的优化新思路。
在软件研发过程中，用例评审是一个常见的实践活动，实践的形式也多种多样，比如：
同行评审：测试内部的同行评审，由更熟悉资深的测试人员评审新手测试人员；
管理者评审：只有开发对测试用例进行的评审，由开发小队长评审小队内测试人员的测试用例是否符合标准；
业务评审：只有产品经理对测试用例进行的评审，目的是评审用例是否覆盖了需求所描述的所有业务功能；
......
出于不同的目的而进行的不同的评审方式各有其适用场景。
本文讲述的用例评审是指：由测试人员主导开展，开发人员、产品经理共同参与的用例评审会议。其他形式的用例评审不在本文讨论范围内。
这种形式的用例评审，主要是为了帮助产品经理、开发、测试三方对齐需求，达成的一致理解。从而消减缺陷在测试环节缺陷逃逸的隐患，避免测试的遗漏、返工与产能浪费。最终达到保障产品质量、提升研发交付效率的目标。
你还在这样做用例评审吗？
以下是一个常见的用例评审过程：
迭代开始的第四天，测试负责人人员小张提前会议邀约测试、产品、开发人员进行用例评审会议。
会议期间，小张熟练的打开脑图，对着自己负责的用户故事，逐字念着用例描述。在念完一个故事的用例中途，询问开发、产品对此需求的用例是否有建议和补充。
参会的产品、开发按部就班回答有或者没有，或在中途发现有疑问的时候发言提问。
小张发言完毕后，接着下一位测试人员对着他负责的用户故事进行发言。
整个过程就这样持续下去，直到过完所有用户故事的测试用例。
这样一个用例评审过程，事实上有很多可以改善的点，例如：
应该提前将评审材料发给参会人员，便于参会人员提前熟悉材料；
注意评审时长，如果用例众多，建议拆分多次评审，每次评审时间尽量不超过1小时；
指定评审过程记录员，便于讲解过程顺畅，问题记录没有遗漏；
测试内部预先评审，避免一些明显问题带到评审会，影响评审效率；
统一规范用例格式标准，便于评审
……
除了以上谈及的常规注意点，在我们实际咨询辅导的过程中发现，以下两点也是影响用例评审效果的重要因素。
用例评审需要聚焦到恰当的靶子上
围绕「测试设计思路」开展
测试用例是为执行软件系统测试而设计和编写出的一组文档，主要内容包括用例标题、前置条件、测试步骤、预期结果等。
其初衷是用于指导测试人员执行测试，因此包含了很多系统层面的操作细节，一个复杂的需求的测试用例规模有些情况下可达上百个。
拿着这些测试用例的细节去做评审，一方面会造成评审陷于的系统操作层面细枝末节，容易失去对原始需求的业务场景关注。
另一方面如果测试人员主持不好评审过程的话，评审者需要在一堆测试用例的细节中，耗费精力猜想测试人员的用例设计意图，这样往往就把评审者拒之门外了。
举个例子，我们将「客户投诉流程」这个业务需求以脑图的形式，编写了测试用例部分片段（如下图所示）。
不难看出，左右两边是两种编写策略，适用于不同的阅读对象。
左侧的编写与呈现纯粹是适用于测试内部的，充满了各种执行步骤与实施细节。
想象一下，评审者要从这些信息中了解测试人员的测试设计意图不亚于做一篇阅读理解。何况，在有些情况下，产品经理和开发人员对一些系统的操作流程并不熟悉，就更看不懂了。
反之，右侧的用例呈现，则以用户场景为切入口，将测试用例组织起来。
测试场景通常都是用户逻辑的语言，开发、产品经理都熟悉，容易理解。这样一来，参与用例评审的不同角色都能迅速了解测试用例的意图。
在测试场景这一层把测试人员的测试设计意图展现给评审者看，这样的方式要比左侧的方式更为直观，用例评审活动也能更为高效地进行。
看到这里，可能测试同学要有意见了——“这不是增加工作量吗？有时候测试用例都没时间写，还要写测试场景？”
其实不然，作为测试人员，其工作流程中，本来就会先进行需求分析——从需求描述的相关业务场景出发提取相关的测试要点，再进一步细化为测试用例。只是有时候并没有把这个思考的过程写出来，而是记在脑子里。
笔者认为，「从分析需求业务场景到提取测试要点」是非常关键的过程，需要记录下来，以防止测试人员遗漏了重要的测试要点内容。在时间不充裕的情况下，测试用例的实施细节反而是次要的。
当然这里并不是说测试用例就不需要写了。测试用例还是需要的，特别是在大型组织中，测试用例可以帮助更好的评估测试的工作，沉淀测试用例资产用于回归测试，可预见的测试执行进度，避免人员变动情况下测试工作无法衔接等问题。
测试设计思路的表现形式并不只有上图这一种方式，流程图、判定表都是可取的。使用这些方式是为了便于评审者快速理解测试人员的测试设计思路，促进团队中不同角色成员对需求的一致理解，从而提高研发的质量。
开展用例评审的合适时间点
开始需求的开发编码工作到未完成开发之间
如果经常遇到在用例评审会上开发基本都没有什么反馈，但是在需求测试阶段又发现开发移交的需求内容有很多和测试理解的不一致，那么测试人员就需要思考一下了——为什么用例评审会没有起作用？
除了上面提到的评审对象以外，评审开展的时间点也是一个影响因素。
迭代中一个开发人员可能负责多个系统功能的开发，开发人员会优先开始高优先级的任务。大致会经历需求分析、阅读现有代码、进行开发设计和编码，这样一个过程。
随着需求研发的推进，开发人员对系统功能的实现也越明确，对需求内容及代码改动可能影响的范围理解也更深刻。这显然需要时间。
如果在开发人员开始需求分析之前我们进行用例评审会怎么样？
开发人员对需求的印象可能还停留在前几天的需求评审，甚至记不清需求的内容。这种情况下，进行用例评审，很难想象能够给出有用的反馈。
因此，用例评审不能太早开始。
那如果在开发人员已经完成编码，移交需求给测试人员之后，才进行用例评审会怎么样？
这时候开发人员可能已经开始下一个系统功能的开发任务了，虽然还记得上一个系统功能的需求内容，但是编码工作已经完成了。如果此时评审发现之前对需求的理解存在偏差，就得返工了。虽然这时评审也起到了对齐需求的作用，但是太晚了，开发编码、返工的成本大。
所以对一个需求来说，用例评审的最佳时间是在开发已经着手开始工作，到需求移交测试这段时间，最晚在需求移交测试之前就要完成需求的用例评审。
在实际操作过程中，常见的是一个迭代中只做一次集中的用例评审，这就往往会导致很多用例太晚评审，效果不佳。
然而，要对每个需求都单独做一次用例评审也很难落地。因为协调成本会很高：不好约时间、不好约会议地点......
所以，较为可行的方式是分批次做用例评审。
因为迭代过程中开发人员也是分批次移交需求给测试的，所以可以顺势对待移交测试的这批次需求做需求评审。一个迭代内通常2-3个批次，是一个比较可接受的频次。
小结
以上两点是在实际开展用例评审过程中，比较容易被忽视的因素。如果能在实践过程中多加注意，会对团队开展用例评审对效果带来明显的改善。
当然，影响用例评审的高效开展有很多因素。
从质量保障角度来说，确保迭代过程中各项质量活动的高效开展是保证产品质量的一大内容。
因此，研发团队可以定期回顾迭代过程中各活动的执行效果，努力探索顺畅、高效的开展方式，保证活动的开展质量。逐步发挥对研发效率和质量的积极影响。
本文作者｜周小宁
Agilean高级技术顾问
Agilean 最新直播资讯：
05.11 本周四晚 20:30 「产品创新，AI时代下的变与不变」
05.18 下周四晚 19:30 「研发效能数据治理」
感兴趣的伙伴们快快约起来吧！👇👇👇
分享👇 收藏👇 点赞👇在看👇
