QA参与技术评审的重要性及工作内容

对于一些比较工作流程比较成熟的公司而言，在软件开发的过程中，需求评审、技术评审是在进入开发阶段之前，必经、也是必须的流程。

它保证了项目或需求初始的质量下限。

但对于一些初创公司，或规模较小、工作流程还不完善的公司来说，对需求和技术评审的重视程度可能相对比较低，甚至——没有。

需求评审如果缺失，在阅读文档了解需求期间，如果发现某些不合理的设计，尚且还有挽回的余地，因为开发此时可能还没有开始。

通过小范围的当面、或一对一的沟通，尚能及时做出改进。

但不可避免地，仍可能存在在需求开发完了之后，甚至上线之后，才发现需求有遗漏或者逻辑缺陷的地方。

甚至线上爆了雷才发现。

我想，需求评审的重要性，对于一个专业的软件行业从业人员来说，已无须强调其重要性。

想着重讲的，是测试人员（QA）与技术评审之间的联系，及参与技术评审的重要性。

涉及到某些系统核心逻辑的需求，理论上技术评审是必不可少的。

但可能因为某些原因，客观的也好，人为的也罢，导致技术评审没有开展。甚至开发前，开发（RD）组内部根本就没有什么技术设计的讨论。

那么，长此以往，这种项目或者需求上线后，百分之百会爆雷。

是的，100%！

只是或早或晚，或大或小。

没有一个人可以考虑问题滴水不漏。那样的话，就不会存在QA这个岗位，也不会动辄一个项目上百个bug。

其中甚至不乏很多会造成巨大损失的bug。比如支付系统等。

这些年的测试工作中，这基本已是一条铁律：

无论什么系统，支付相关的模块都是重中之重。如果出问题，很大概率造成损失，甚至巨大损失。做软件是干嘛的？至少不是搞慈善发钱、薅羊毛的吧。

没有代码技术评审，那么就需要RD有相当高的个人专业能力，和责任心，二者缺一不可。

而现实中，这几乎是不可能同时存在的。

有个人能力的原因，有项目周期及资源等客观原因，也有责任心的原因。

提到责任心，以上观点不必曲解。大多数都仅仅是打工的，是为了挣钱，别扯上什么理想，也轮不到你摊上那种跨越阶级的机会。至少工作总不是努力奋斗，为了让老板开着劳儿住别野的吧？

那么在此前提下，对QA的要求相对就变得更高了。

测试是兜底的，兜不兜得住，主要决定因素就在个人能力上了。那么兜不住的风险也相对增加了。

有些情况，因组织者不懂管理、思维短浅，或盲目自信（也有可能是自卑）。技术评审没有或不许QA参与，都是绝对不规范的开发流程，一定会存在潜在风险。

当然，前提是QA要有一定的技术能力，最好也运用过相关技术做过开发。那么叫上QA就是很有必要的。对于一些经验尚且不足的QA，也是一个很好的成长的过程。

说到技术评审，就不得不提QA应该在测试左移工作中，应该做的事情。

1.测试用例的设计。

根据需求文档，结合技术方案，设计有效、简洁的测试用例，这个不多说。

2.评审技术方案的合理性，提供备选方案。

QA了解并参与讨论RD提出的技术方案，或提供一种或几种技术实现方案供RD选择，一起评估可行性、实现难度、稳定性、可维护性、成本等。

3.评估测试可行性，易测性。

基于技术方案，评估测试可行性。是否可以测试、容易测试，有哪些需要提前准备或协助的地方。例如，动态短信验证码请求，预设一个固定字符串123456用作测试；测试数据准备，是否需要RD协助或是QA编写脚本准备；部分业务场景的测试，是否需要准备挡板；一些时间点、时间段相关配置的测试，需要RD配合修改配置以便更容易进行测试等。

4.添加日志，监控。

核心功能必要的需要增加日志和监控的地方，QA应给出提醒。例如，打印某些重要数据的计算过程；用户支付失败后的代码过程；监控某些重要接口失败频率及某些数据同步；与三方系统交互的数据等。便于测试，确保业务稳定性和发生问题后快速定位。

5.评估影响范围。

代码改动对相关功能的影响，不同的设计方案影响范围及测试范围的区别。切记不要盲目相信RD提供的影响范围，结合业务理解合理圈定回归范围。

以上就是目前大概能想起来的，测试左移常见的工作内容。你还会质疑QA参与技术评审的重要性吗？

不要等到进入测试过程中才发现技术方案的问题，甚至有一些存在隐蔽问题的方案通过了测试，在线上暴雷。

虽然没有人可以完全保证，QA参与了评审，就一定不会出问题，但的的确确可以大大降低故障的发生。在测试阶段前，越早发现问题，解决成本也就越低。

最后说两句，

因为测试门槛低，总被约等于“点点点”，但门槛低，不代表门槛水平永不被淘汰。

国内的QA地位、待遇普遍较低，跟在座的每一位QA都有关系。