这是《落叶》文集里第 167 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
今天有同学在圈子里问了个问题：一直搞的web，没搞过app，如果站在测试经理的角度，如何编写测试计划以及如何保证产品的质量？换句话说产品从0到1，你怎么一步步的分析加实行才可以保证这款产品呢？
乍一看这就是挺大的问题，设计的环节比较多，圈主老徐让其细分，就提到了如果没有需求，怎么制定测试计划？
从这个细分问题上能反映出，就是在没有流程的环境中，测试如何保证产品质量？
【你问】
IF 流程 = NULL，测试人员如何保证产品质量？
【我答】
先回答一下细分的问题：如果没有需求，怎么制定测试计划？
依照问题里的背景，是说一个从0开始的产品，那如果没有需求，开发是基于什么做架构设计和编写代码的呢？我言下之意就是，开发基于什么去做设计和编码的，测试就可以基于什么去了解范围和评估规模。有没有需求，按我的理解，其实跟我们制定测试计划没有必然的联系，或者说，不是必要的输入产物，特别是在很多初创公司或者是零流程的公司。
对于测试来说，通过需求，主要是想分析测试场景、梳理测试点和设计测试用例，估算工作量主要也是基于测试点和测试用例的。
再说测试计划，我这里说的其实是基于问题中的背景环境，一个没有需求的产品研发流程，我是不是可以理解成零流程呢？
在这种环境下，所谓的测试计划，更多的其实是测试时间计划。假设事先没有任何需求和相关文档，测试在开发提交可测产品之前都没法根据需求点或测试点来评估工作量的花，就可以简单一点，按照开发的工作量评估来估算测试工作量，常规上来估，一般将开发的工作量乘上1.5 或2，基本就属于可控范围的测试工作量了。
然后，再要求开发给出具体的提测时间计划表，你根据这两个东西，就可以去排你的测试执行计划了。
还有一种很常见的现状，开发提测时间和测试计划时间都排好了，但是产品发布时间是在这之前就已经敲定且不可改变的，甚至于到你计划排好了，从开发提测到完成测试，至少需要4周的时间，这时候，突然产品发布时间提前到开发提测后两周的节点，你其实就没有办法按照计划按部就班的执行了。
这时候你需要把握住两个关键的测试策略：
第一、产品里哪些是核心功能和流程，是你必须要保证没有问题的；
第二、非核心功能和流程的测试层级标准是什么，在实际可用测试时间小于计划测试时间时，你就需要有所取舍，例如，只覆盖到 Priority 1 的测试层级；
你要明白，不是所有公司都有流程或者说规范流程的，特别是初创型公司和中小型公司，所以，不要过于依赖于标准流程上的一些输出产物，才知道怎么去开展自己的一些工作，可以灵活变通一些，在你还没法改变环境的时候，你就需要去适应这个环境，且找到合适的方法。
最后再跟你说一下，零流程其实是个很好的机会，因为流程这个东西，要么就是有人直接落地实施，要么就是可以由测试直接倒逼开发和产品，这也取决于你们老大对测试的支持力度。像我们现在，流程虽然也还不完善，产品需求质量也不高，但从需求流程到现网问题的处理流程，包括研发的版本控制，分支管理，开发测试环境独立等流程，都是由我们测试一手倒逼建立的。
《测试路上你问我答》里的Q&A 30，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
