QA评审底层测试的价值

“林子,咱们上次讨论的高效Desk check清单,用起来还挺好的,最近我们组每次Desk check变得顺利多了,Dev也是越来越熟练。”玥玥跟我说。

“真好!我们组感觉也是这样!”

“不过,我听小慧说他们组有人对QA review UT提出了一些concern(质疑),觉得QA review的价值不大,基本都是Dev给讲一遍,QA也提不出来什么反馈…”玥玥补充说道。

“哦!那你们组感觉review的怎么样?”我问玥玥。

“我们组感觉还挺好的,可能是因为我已经review很长时间了,对Dev写的测试也比较了解了,每次过一遍不会太费劲,也能发现一些问题。”

“嗯,QA review测试肯定是有价值的,但是能否体现出价值,取决于是否做的好,这不仅对QA有要求,对Dev也是有要求的。”

关于底层测试及其评审

看到前面的对话,可能有朋友会问什么是底层测试,以及底层测试又是如何评审的。因此,我先来介绍这两个内容。

底层测试

测试分层理论根据测试所覆盖范围的大小,将测试分成不同的层:端到端功能测试、API集成测试、单元测试等,常见的测试分层实例有测试金字塔

位于金字塔下面的API测试和单元测试,通常称为底层测试,一般都由Dev实现。

评审流程

由于底层测试一般都是Dev实现,为了保证这些测试的质量,我们在敏捷实践里提倡在做Desk Check的时候,QA跟Dev一起来做测试评审,详细执行方式是这样的:

  1. Desk Check先完成该用户故事的功能、非功能需求的验证;
  2. 第一部分结束之后留下QA跟Dev一起来评审测试,通常由Dev给QA演示,而QA主要关注测试的有效性,包括测试覆盖情况、分层是否合适、是否有冗余的或者遗漏的测试、测试命名、测试是否验证了需要验证的内容等。

QA评审底层测试的价值

体现在这几个方面:

  1. 最重要的是利用QA的测试技能,可以发现Dev所写底层测试可能存在的问题,让测试更有效。
  2. QA通过review底层测试,能够更好的了解测试覆盖情况,更清楚整体的测试状态。
  3. QA看Dev写的测试,可以起到督促他们编写测试的作用。

但是,如果没做好,就会变成一种形式,Dev把测试给QA看一遍,QA就是稀里糊涂的过一遍,没有输入也没有反馈……这样的话,当然就没有价值了,而且还会浪费大家的时间。

虽然说的QA评审测试,其实是Dev和QA合作完成的事情,要想做好,对Dev和QA都有不同的要求。

测试评审对Dev的要求

首先,对Dev的要求有以下几个方面:

  1. 自己要能清晰理解所有的测试,比如换人结对后,可能对原来同学写的测试没有搞清楚,当然没办法给QA讲清楚;
  2. 能清晰的介绍所写测试,包括对应的测试点、哪些点在单元测试覆盖、哪些在集成测试覆盖等;
  3. 要能系统的给QA去演示,不是直接打开IDE让QA自己去看,也不是东一个西一个想起哪个给演示哪个,把QA搞晕了。

据我的经历来看,不同经验的Dev演示的效果是截然不同的。

当然,对于经验特别丰富的QA来讲,对Dev的要求不一定有这么高,因为QA自己可以系统的去理解。

测试评审对QA的要求

其次,从QA的角度,要想把测试搞清楚,有下面几个要求:

  1. 对测试分层等测试策略的理解,需要能够判断出哪些应该写单元测试、哪些写集成测试;
  2. 对于底层代码结构的理解,了解单元测试和API集成测试的实现形式,倒不一定要自己去实现,只是要做到能看懂能理解。
  3. 对于测试点的把握,比如对所验收用户故事的测试点要做到心中有数,能够清楚的知道需要有哪些测试来覆盖,帮助发现是否有遗漏的测试。
  4. 还有就是一些基本测试编写技巧的掌握,比如说测试命名、测试验证点是否正确、测试是否有冗余等。
  5. 如果QA对于技术实现不是很了解,可以加强与Dev的沟通,让Dev帮忙介绍更多的上下文以帮助更好的理解。因此,对主动性和沟通能力都有要求。

另外,既然是一个合作完成的事情,对于不太理想的评审过程,团队可以一起回顾一下,看看有哪些可以改进的地方。

相信QA评审测试是有价值的,团队一起来想办法找到适合的方式,让这个实践发挥应有的价值。

没有做好评审过程,怀疑存在的价值,一定是双方都有责任。