1. 产品阶段和测试轮次
想象你在桌上展开世界地图，可以通过经纬度快速定位当前的位置。在产品研发和测试进程上，也需要一个能在产品路线图上快速定位当前位置的方法。我觉得定位方法主要有两种：一是通过产品阶段和测试轮次，二是通过版本号。这两种方式都有一个共同的基础，就是配置管理。具体可以参考PMP里关于配置管理的说明。
先说阶段和轮次。
打个比方，有个产品定义了四个阶段代号，Alpha专注UI，Beta专注功能，Master专注集成，Release代表发布版，每个阶段两轮测试，通过阶段和轮次就可以定位任意位置，比如Alpha阶段第二轮测试，Master阶段第一轮测试。跟版本号相比，阶段和轮次能让人更直观地了解当前的研发和测试重心是什么。比如在Alpha阶段第二轮测试，经过Alpha一轮后，UI设计和UI框架已经没什么问题，此时会关注更细节的东西，而且不会太在意功能上的缺陷，甚至看到了功能缺陷，也不会提出来。这是测试生命期管理很容易忽略的地方，就是测试轮次既没计划也没重心，胡子眉毛一把抓，拿到东西就动手测。
再说版本号。
版本号的本质，就是把轮次的概念直接反映在代号上，而不再单独描述。跟上面相同的例子，通过版本号描述可能就成了A1，A2，B1，B2，M1，M2，R1，R2等。
2. 传统测试流程
既然讲到测试流程，就不得不提V模型和W模型。
我们在CMI基本上是按V模型在走。如下：
传统流程中测试计划很重要。但是测试计划里的时间点其实不太重要，因为测试计划的时间点是跟随开发计划的。真正重要的是对测试轮次的定义，对准入准出条件，轮次启动和关闭的定义。需要特别指出的是，跟开发计划一样，测试计划是一份动态文件，要根据实际情况调整计划，千万不要试图追赶计划，或者遇到变更后放弃更新计划。
测试memo，是非常棒的实践。可以把它当做测试日报吧，选择性的包含缺陷个数/状态分布图，缺陷个数/模块分布图，缺陷个数/等级分布图，当前轮次覆盖率数据等。当测试轮次启动后，每天一份memo发给相关干系人，不花什么精力，却能给PM和PO非常好的体验和数据支持。
测试轮次的启动和关闭一定要有明确的声明。
3. 敏捷测试
我没参与过敏捷测试，不过很想尝试。下面是一些肤浅的理解。
不一定非要基于敏捷开发，但至少也需要开发生命期的支持。越是偏向瀑布模型的开发生命期就越不适合，比如纯瀑布，生鱼片，子瀑布等。相反像渐进原型，阶段交付，渐进交付，螺旋模型等都比较适合尝试敏捷测试。
用户故事备注，代替测试用例设计和管理。这是我特别希望在工作中实践的点。因为测试用例是个很鸡肋的东西，但是你又需要做测试用例的设计。我们在CMI的做法是用导图做用例设计，而不真正写用例出来。跟故事备注就很相似了，比起传统测试流程，故事备注是动态的，而且是前置的，更有利于减少非一致性成本。
小型里程碑与每日构建。无数次的经验告诉我们，大家常规理解的进度是虚假的。敏捷宣言的原则说，可工作的软件是进度的首要度量标准。这也是我们在项目一部和CMI发现的现象。可工作的软件可以通过一些方法来保证，比如持续集成，每日构建，小型里程碑，敏捷测试等。
关于自动化。似乎谈到敏捷就要谈自动化，我的观点是，当手动测试都没有裁剪出一套恰当的方案时，试图做自动化很难有好结果。我们15年左右折腾了一个基于Appium的UI自动化的方法，技术可行性已经验证通过，但是最终都没有放到项目里应用，因为真的不适合。
