快速小迭代试错业务测试如何把控质量

深度介入需求和技术方案

快速迭代的过程中时间都比较赶，很容易进入的一个误区是为了缩短工时对需求和技术方案了解不深，测试用例侧重主流程分析，细节问题在前期没进行深挖。随着迭代的进行，对项目的整体结构了解会越来越混乱，在不断并快速的有新的需求提出时，无法将需求点对应在系统中的改动点get到，只根据需求文档过一遍需求流程，纯黑盒的考虑测试，迭代的越久对质量的把控就会越低。
个人认为测试可以在各个阶段做比较深的介入

1、需求阶段

迭代中的现状不断地有需求过来的时候，一些小的需求会只有一句话描述，可能只是对原始需求的一个表述。这样的需求，测试要根据需求做深入的思考，明确需求的内容以及想要达到的目的。对于需求的实现方式可以提出自己的方案，对于需求的整体链路流转需要非常清楚。

2、 技术方案

参与技术方案的讨论，在快速迭代中，技术方案因为时间关系会比较粗糙，测试需要提高警惕，结合需求阶段已理得很明确的需求，对技术方案做深入的挖掘，明确每个数据库流转的点，每个业务逻辑的技术实现。同事在快节奏下开发考虑技术在前期很可能只考虑了常规流程的情况，一般坑比较大的都是复杂情况以及异常情况，测试在这部分需要跳出开发给的思维，更广的去考虑问题，看技术方案是否给出对应的技术解决方法。

3、参与需求筛选

在大量需求提交过来的时候，除了产品去筛选需求，测试也可以参与到需求优先级的讨论中。
例如可以根据之前的需求实现以及使用情况来看，可以发现需求方提交的一些某些方面的需求上线后使用率比较低，那么后续对这方面的需求可以进行着