“林子，咱们上次讨论的高效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一起来做测试评审，详细执行方式是这样的：
- Desk Check先完成该用户故事的功能、非功能需求的验证；
- 第一部分结束之后留下QA跟Dev一起来评审测试，通常由Dev给QA演示，而QA主要关注测试的有效性，包括测试覆盖情况、分层是否合适、是否有冗余的或者遗漏的测试、测试命名、测试是否验证了需要验证的内容等。
QA评审底层测试的价值
体现在这几个方面：
- 最重要的是利用QA的测试技能，可以发现Dev所写底层测试可能存在的问题，让测试更有效。
- QA通过review底层测试，能够更好的了解测试覆盖情况，更清楚整体的测试状态。
- QA看Dev写的测试，可以起到督促他们编写测试的作用。
但是，如果没做好，就会变成一种形式，Dev把测试给QA看一遍，QA就是稀里糊涂的过一遍，没有输入也没有反馈……这样的话，当然就没有价值了，而且还会浪费大家的时间。
虽然说的QA评审测试，其实是Dev和QA合作完成的事情，要想做好，对Dev和QA都有不同的要求。
测试评审对Dev的要求
首先，对Dev的要求有以下几个方面：
- 自己要能清晰理解所有的测试，比如换人结对后，可能对原来同学写的测试没有搞清楚，当然没办法给QA讲清楚；
- 能清晰的介绍所写测试，包括对应的测试点、哪些点在单元测试覆盖、哪些在集成测试覆盖等；
- 要能系统的给QA去演示，不是直接打开IDE让QA自己去看，也不是东一个西一个想起哪个给演示哪个，把QA搞晕了。
据我的经历来看，不同经验的Dev演示的效果是截然不同的。
当然，对于经验特别丰富的QA来讲，对Dev的要求不一定有这么高，因为QA自己可以系统的去理解。
测试评审对QA的要求
其次，从QA的角度，要想把测试搞清楚，有下面几个要求：
- 对测试分层等测试策略的理解，需要能够判断出哪些应该写单元测试、哪些写集成测试；
- 对于底层代码结构的理解，了解单元测试和API集成测试的实现形式，倒不一定要自己去实现，只是要做到能看懂能理解。
- 对于测试点的把握，比如对所验收用户故事的测试点要做到心中有数，能够清楚的知道需要有哪些测试来覆盖，帮助发现是否有遗漏的测试。
- 还有就是一些基本测试编写技巧的掌握，比如说测试命名、测试验证点是否正确、测试是否有冗余等。
- 如果QA对于技术实现不是很了解，可以加强与Dev的沟通，让Dev帮忙介绍更多的上下文以帮助更好的理解。因此，对主动性和沟通能力都有要求。
另外，既然是一个合作完成的事情，对于不太理想的评审过程，团队可以一起回顾一下，看看有哪些可以改进的地方。
相信QA评审测试是有价值的，团队一起来想办法找到适合的方式，让这个实践发挥应有的价值。
没有做好评审过程，怀疑存在的价值，一定是双方都有责任。