“林子，咱们上次讨论的高效Desk check清单，用起来还挺好的，最近我们组每次Desk check变得顺利多了，Dev也是越来越熟练。”玥玥跟我说。
“真好！我们组感觉也是这样！”
“不过，我听小慧说他们组有人对QA review UT提出了一些concern（质疑），觉得QA review的价值不大，基本都是Dev给讲一遍，QA也提不出来什么反馈…”玥玥补充说道。
“哦！那你们组感觉review的怎么样？”我问玥玥。
“我们组感觉还挺好的，可能是因为我已经review很长时间了，对Dev写的测试也比较了解了，每次过一遍不会太费劲，也能发现一些问题。”
“嗯，QA review测试肯定是有价值的，但是能否体现出价值，取决于是否做的好，这不仅对QA有要求，对Dev也是有要求的。”
QA评审底层测试的价值体现在这几个方面：
- 最重要的是利用QA的测试技能，可以发现Dev所写底层测试可能存在的问题，让测试更有效。
- QA通过review底层测试，能够更好的了解测试覆盖情况，更清楚整体的测试状态。
- QA看Dev写的测试，可以起到督促他们编写测试的作用。
但是，如果没做好，就会变成一种形式，Dev把测试给QA看一遍，QA就是稀里糊涂的过一遍，没有输入也没有反馈……这样的话，当然就没有价值了，而且还会浪费大家的时间。
虽然说的QA评审测试，其实是Dev和QA合作完成的事情，要想做好，对Dev和QA都有不同的要求。
首先，对Dev的要求：
- 自己要能清晰理解所有的测试，比如换人结对后，可能对原来同学写的测试没有搞清楚，当然没办法给QA讲清楚；
- 能清晰的介绍所写测试，包括对应的测试点、哪些点在单元测试覆盖、哪些在集成测试覆盖等；
- 要能系统的给QA去演示，不是直接打开IDE让QA自己去看，也不是东一个西一个想起哪个给演示哪个，把QA搞晕了。
据我的经历来看，不同经验的Dev演示的效果是截然不同的。
当然，对于经验特别丰富的QA来讲，对Dev的要求不一定有这么高，因为QA自己可以系统的去理解。
其次，从QA的角度，要想把测试搞清楚，有下面几个要求：
- 对测试分层等测试策略的理解，需要能够判断出哪些应该写单元测试、哪些写集成测试；
- 对于底层代码结构的理解，了解单元测试和API集成测试的实现形式，倒不一定要自己去实现，只是要做到能看懂能理解。
- 对于测试点的把握，比如对所验收用户故事的测试点要做到心中有数，能够清楚的知道需要有哪些测试来覆盖，帮助发现是否有遗漏的测试。
- 还有就是一些基本测试编写技巧的掌握，比如说测试命名、测试验证点是否正确、测试是否有冗余等。
- 如果QA对于技术实现不是很了解，可以加强与Dev的沟通，让Dev帮忙介绍更多的上下文以帮助更好的理解。因此，对主动性和沟通能力都有要求。
另外，既然是一个合作完成的事情，对于不太理想的评审过程，团队可以一起回顾一下，看看有哪些可以改进的地方。
相信QA评审测试是有价值的，团队一起来想办法找到适合的方式，让这个实践发挥应有的价值。
没有做好评审过程，怀疑存在的价值，一定是双方都有责任。