测试左移之如何开展需求技术方案评审

随着业务新架构的不断引入，对于软件测试技术的要求也大幅提高。测试的目标也升级成“保持质量稳定，持续提升效能”。

测试工程师在工作中投入过多的精力在开发和交付过程中，反而对需求和设计阶段的方案评审重视程度不够。

本文结合前台搜索团队的实践和经验，从测试工程师的角度，介绍如何开展需求技术方案评审，给大家分享一些经验。

在落地需求技术方案评审前，我们需要在团队内部达成共识，使得整个团队目标统一。

上图是恪守的迭代交付流程图，这里不做过多说明。测试工程师在开发阶段、测试阶段和发布阶段参与，在需求阶段和设计阶段并没有过多投入。

观察SDLC模型，需求阶段在测试阶段的左侧，由于测试阶段处于相对滞后的位置，当面对需求和开发上的变更调整时，测试工作会变得被动。由于发版日期的临近，这些变更带来的不确定性会反作用到整个团队。

测试左移是将测试提前到需求阶段、设计阶段和开发阶段来进行，由于这三个阶段在测试阶段的左侧，所以称为测试左移。采用测试左移带来的好处是，测试工程师更加主动，有助于更早的发现问题，培养敏捷团队成员的质量意识，有更多的时间做提升效能的工作。

需求技术方案评审包括对PRD的评审和对技术方案的评审，好处是提升产品质量的上限。

测试人员不仅要去评估需求的质量，分析需求的合理性以及完整性，也要参与技术方案的设计，了解开发的实现方式。

测试工程师在每个迭代版本中“确保质量不变，增加交付需求，化解时间压力”。“确保质量不变”代表测试人员的职业底线，“增加交付需求”代表测试人员的职业能力，“化解时间压力”代表测试人员的价值观体现。

实际影响质量的因素有很多，一般包括需求评审充分性、技术方案合理性、测试用例颗粒度、测试手段完备性、开发质量、团队能力熟练度和跨团队配合等等。

通过回顾会上的总结，可以分析得出“痛点”多集中在需求是否清晰明确、测试/联调数据准备是否充分和面对紧急情况是否有应急预案。

在实际工作中，团队通过在需求评审会议中，重点加强对需求技术方案的评审，对需求的准入准出做到更加合理、可控和可预期。

首先，确定了评审标的为产品需求文档和研发技术方案，评审目的是对文档中有关需求描述、需求依赖、需求影响范围、非功能性需求及安全风险等方面进行评审，以提高方案的正确性和合理性。

其次，团队内的各个角色职责需要划分明确，履行各自的职责。

最后，分别针对功能性需求和非功能性需求梳理出了评审需要注意的公共评审要素。每个模块都有其各自的业务特点和团队氛围，需要发掘出适合自己团队的评审要素。

在团队中采用线下评审会和线上穹天平台需求分析相结合的方式，跟踪每个迭代中的分析结果。按照上述方式，在经过几个迭代的试运行后，取得了不错的效果。

首先，团队明确了在评审会中“评审什么”、“如何评审”和“评审通过的条件是什么”等实际问题。

其次，对照“公共评审要素”中的各项进行梳理，对需求的进度管理和提测质量的提升起到了正向作用。

最后，整个团队处于责任明确，需求数量和质量成螺旋状提升的趋势。

在实际落地过程中，也发现一些不足，需要后续进行优化提升，比如对于落地方案的打磨，评审要素中个别要点不适用某些业务需求场景，如何上下游紧密合作打破壁垒等等。相信随着时间的推移，这套需求技术方案评审方案可以更加完善，从评审开始做好质量保障。

展望未来，测试人员在保障产线质量稳定的基础上，还要承担引领和协调所在团队中各个角色共同承担产品质量的工作。随着用户对购物体验的预期不断提升，业务需求数量和上线频率的增多，测试工程师如何在如此快节奏下保障质量是个职业课题。测试左移是个前沿概念，需求技术评审方案是结合目前环境给出的方法论，不论是概念还是方法论，目标都是保证产品质量而进行不断探索和尝试的过程，最终形成适合业务需要的测试流程。测试人员是要做“一专多能”的“T型人才”，还是“增值创新”的“十字型人才”，未来三到五年的软件行业自会给出答案。

希望本文给大家带来一些思考和启示。