首先理一下正常的测试流程：
1、自家/外部拿出需求/策划案，开发，产品，测试至少这三方成员进行需求评审。
2、当需求敲定以后，测试人员对需求进行分析设计测试用例。（负责人拟定测试计划）
3、对测试用例进行评审。可以进行些思维碰撞扩展用例，调整其中不完美的地方
4、执行测试
5、编写测试报告
……
不正规的流程：
1、没有原型文档/策划案
2、不进行需求评审，给了就要测
3、没有时间设计测试用例/测试点
4、测试环境不稳定。一天十八更
……
以上不正规流程，在没有大佬力挽狂澜，而你的谏言并没有什么用的情况下。基本上都一定的程度的客观存在过（笔者还在水深火热中艰难度日）
针对没有原型文档。建议直接进行探索性测试，进行一个功能点梳理（作者自己用的xmind）牺牲一段时间进行下功能熟悉。具体细分逻辑有疑问就及时提问开发或者产品。
有需求，不评审。对需求进行分析，并且对不合理的地方进行备注。实时反馈你发现的问题，这个时候提出你的疑问怎么解决看产品，但是一定要提前把疑问都说出来。而不是蒙着头测试，测完以后一股脑的说，或者按着不说。
没有时间设计测试用例。这个时候时间紧迫，策划案也才给你。你只能一遍测试一遍比照策划案。但是提议还是先梳理下策划案，分清级别。然后在进行测试
测试环境不稳定。你有没有测试过程中，提一个bug，开发改好了跟你说去拉代码吧。这个时候可以针对优先级别来决定更不更新代码。如果不是致死性影响流程的，建议大家还是暂时不要去刷新当前的环境了。