记得在学习项目快速入手时，有个步骤叫项目调研，包含了开发阶段，技术和业务优先级，其中技术优先级又涉及了开发人员是老员工还是新员工，开发时，模块是否是重新开发的。这次自以为是，忽略了这个问题，导致后面测试不断给自己挖坑。不由感叹：测试流程上，越是靠前的步骤，即便是一句话的事情，你没有去做，都是有很大隐患的。

那天技术部开会，突然分配给一个测试任务：

是PC的网页产品，而且又是一个开发了多次的老功能，心里不免放松了。

拿到需求看了一下：

• 首先需求是半成品，只描述了部分的修改，其它需求和设计稿都在开发过程中不断临时追加。给人感觉很随意，而且大多都是提示文字的整体改动，多两个选框……
• 其次开发是老员工，对这块功能也是非常熟的……
• 最后PC端确实并不受重视

于是我采用了最快速的策略

• 第一天看完需求稿和设计稿，直接对照着测试产品
• 提完bug感觉很轻松
• 但是开发的一句话给我惊醒：这个功能我写了快一个月了

一个月？对于我们的团队来说那是大投入了！

• 第二天我立马重新看需求，跟产品进一步交流，与开发交流改动的概况
• 抱着对开发的过度信任，没有写测点，继续凭感觉跑了一遍异常和正常的全功能。
• 搞出了一堆bug
• 心里松了一口气，这时开发又说了：这块功能是全部重写的

重写的？！

• 第三天，随着测试的深入，开始补充测漏的逻辑，同时也意识到发布还是个公共模块，还需要补充牵扯的其它功能测试。
• 就这么一个布满了输入框和选择框，只有一次提交的页面，又是一堆bug，这时我感觉对于开发来说，这样的bug量应该差不多了。开发也觉得测的逻辑、页面要素和功能业务的bug都差不多了。
• 仍然没有意识到没写测点或用例的严重性！
• 第三天的晚上，赶着上线，跑出更深入的一些bug……

这时，开发说：要不我们到下周再上线？

• 运营总监已经催了好几遍了，产品经理说必须上线。
• 技术总监说线上测试环境要尽快上线，腾出测试环境给其它进度。
• 开发说，感觉有几个地方还有问题，上线感觉有风险。
• 作为测试，我已经把所有bug看了一遍，心里已经有谱，虽然之前测试被坑几次，也不敢说没问题了，但是根据bug的分布，和几天来不断深入和扩展开的测试内容的构成，我对开发说：这些bug修复后，可以达到上线质量了。
• 不管出于什么，最后产品开发都很被动地签字上线。幸好，一切顺利。

虽然最后赢了，但自己知道是输了。总结这次测试流程的不足如下：

1. 需求没有提前分析，文档获取不及时，并且对测试计划认识不足，导致不重视，为整个测试埋下大隐患。
2. 与开发沟通不及时，没能对新开发模块设计充分的用例。
3. 没有按部就班先分析范围，设计用例，而直接进行快速测试，导致随着测试深入，不断爆bug。整个测试节奏倒挂，直接结果是与开发一起加班到深夜修复bug。
4. 该需求的编写人员已经离职，处于没有产品人员推动和管理的状态下，测试应该更早更主动的介入，补充开发周期里缺失的角色职责。