首先理一下正常的測試流程：

1、自家/外部拿出需求/策劃案，開發，產品，測試至少這三方成員進行需求評審。

2、當需求敲定以後，測試人員對需求進行分析設計測試用例。（負責人擬定測試計劃）

3、對測試用例進行評審。可以進行些思維碰撞擴充套件用例，調整其中不完美的地方

4、執行測試

5、編寫測試報告

……

不正規的流程：

1、沒有原型文件/策劃案

2、不進行需求評審，給了就要測

3、沒有時間設計測試用例/測試點

4、測試環境不穩定。一天十八更

……

以上不正規流程，在沒有大佬力挽狂瀾，而你的諫言並沒有什麼用的情況下。基本上都一定的程度的客觀存在過（筆者還在水深火熱中艱難度日）

針對沒有原型文件。建議直接進行探索性測試，進行一個功能點梳理（作者自己用的xmind）犧牲一段時間進行下功能熟悉。具體細分邏輯有疑問就及時提問開發或者產品。

有需求，不評審。對需求進行分析，並且對不合理的地方進行備註。實時反饋你發現的問題，這個時候提出你的疑問怎麼解決看產品，但是一定要提前把疑問都說出來。而不是蒙著頭測試，測完以後一股腦的說，或者按著不說。

沒有時間設計測試用例。這個時候時間緊迫，策劃案也才給你。你只能一遍測試一遍比照策劃案。但是提議還是先梳理下策劃案，分清級別。然後在進行測試

測試環境不穩定。你有沒有測試過程中，提一個bug，開發改好了跟你說去拉程式碼吧。這個時候可以針對優先級別來決定更不更新程式碼。如果不是致死性影響流程的，建議大家還是暫時不要去重新整理當前的環境了。