解決“測試流程”問題的底層邏輯

你好，我是剛哥。
這周技術羣有3個討論激烈的問題，①進到一個完全沒有規則流程的新公司，怎麼接手安排讓自己儘可能舒服點？②需求一個接一個，測都測不過來，哪還有時間寫用例？③如果一個需求開發測試1天內進行，你還有其他測試任務，會怎麼安排？
這3個問題本質上都是測試流程問題，解決的底層邏輯是建立自己的流程並靈活調整。
我們先來分析下問題的關鍵點是什麼？缺少時間。然後看看是爲什麼沒有時間？第1個問題是因爲公司要搶佔市場，還沒有時間來建設流程。第2個問題是需求任務太多，纔沒有時間寫用例。第3個問題是多個測試任務並行，沒時間走測試流程。
部分觀點是，在小公司哪管得了那麼多，快速交付，搶佔市場，能活下來纔是最重要的。這個觀點沒有問題，這是我們無法改變的客觀事實，要想推動建設公司流程，很難。但我們希望能找到一種方式，能夠讓“自己”的工作更順暢點。
聚焦到自己的工作，建立自己的流程，形成閉環。測試流程最核心的4個節點是用例設計、測試執行、缺陷管理、測試報告。按照這4個核心節點去順序執行測試流程。一定要順序執行，並靈活調整形式。
比如說，研發提測了，時間還夠就用XMind設計用例，時間不夠就用文本寫測試點，完全沒時間，你自己也要先分析要測哪些內容，怎麼測。把用例設計這一步做完以後，再去做測試執行。缺陷管理沒有平臺就聊天交流，你本地還是要做好記錄，有哪些缺陷，哪些解決了，哪些沒解決，寫清楚。最後測完了要上線了，有時間就寫份測試報告發個郵件，沒時間也要評估上線風險，定測試結論，同步遺留問題。
認知提升以後，針對第2個問題，就不會提出“哪還有時間寫用例”這種經典問題了，因爲用例設計這一步我是花時間做了的，只是形式可能不同，如果需要某種特定產物，就可以說“我現在只簡單列了測試點，還沒寫成XMind用例”，這是可以理解的。
按照測試流程有序進行工作，有助於構建軟件測試知識體系。