需求环节测试是否应该介入

因小程序上一个版本测试时，问题百出

理想状态下的测试流程，在小程序里完全不见踪影

理想状态是什么样子的：

测试参与需求评审+测试和开发对于产品的认知始终在一个水平线+需求不可随意改动+原型和需求说明书要准确，用例以此为参照来编写+进行用例评审+送测前自测通过主业务线

然而，在上一版的小程序里，一项都没做到，真的

小程序的测试过程是什么样子的，把以上的标准流程分别取反就可以了

 

由于在上一版的测试中，我是从送测开始介入

前期不清楚的东西太多，也梳理不过来，测试工作是最紧急的，而追根溯源是重要而非紧急的事

所以就先测完当前版本，完成测试交付，下一个版本再尽可能的改进

 

现在，下一个版本要来了

第三季度，研发的工作目标就是，1.大幅优化后台（包括UI和业务逻辑）；2.新增“数据智能分析”功能，以获得产品优化的思路

那么，测试优化也可以开展了

这个版本，我想实现的是：

测试前置，进行需求评审+测试过程中需求不可随意改动，如有改动必须讨论决定，用例也跟着一起改动+原型和需求说明书准确无误，测试用例按照它们编写+进行用例评审+送测前，编写好主业务线的用例，开发自测通过后送测

 

以上是我之前从书里了解到的，测试、开发和产品需要做的事情

经过上一个版本的测试，我也确实体会到了需要规范一些事情

再加上问过我们部门的几个资深测试，都是这么说

因此，这个版本就这么干

 

surprise：

上周在需求评审没叫我们参加的情况下，而且是产品和开发已经有了需求说明书定稿的情况下，我和测试同事拿着定稿，发现了1个流程上的问题

跟产品讨论之后，最终他修改了需求说明书

这已经能够说明测试前置的重要性了

 

转载于:https://www.cnblogs.com/jitipaper/p/11226113.html