1 需求評審
我覺得不管是自研產品還是其他產品，測試人員都要參加需求評審的會議，一方面，便於了解需求進而更好地開展之后的測試工作，另一方面測試人員往往是從用戶考慮居多，更加能夠從客戶的角度提出符合實際的建議
2 制定測試計划
待需求最終確定下來，則可以開始制定評測方案，
確認測試目標，測試范圍，測試方法，測試策略，資源安排，風險評估等
3 測試用例設計
待測試計划擬定以后，可開始進行用例設計，一般先使用思維導圖整理大概框架，在使用測試用例管理工具，按照功能模塊，使用場景進行設計
4 測試用例評審
因為一個人的思想是有局限性的，待用例設計好之后，最好項目組的所有人員都參與用例評審，以便查漏補缺，盡可能使用例覆蓋更全面
5 冒煙測試：
待研發人員提交版本后，測試人員便可以進行冒煙測試，當然，冒煙測試的用例要提前選好
6 一輪測試
待冒煙測試通過。則可以開始執行度一輪的測試，發現的bug使用缺陷管理工具（如jira、resmine、禪道等）記錄下來
7 N輪測試：
如果有必要，可以進行第二輪，第三輪，第N輪的測試
8 回歸測試：
待研發人員吧本次序修復的bug都修復完成后，即可進行回歸測試，主要驗證缺陷是否真的修復，知否會影響現有系統的使用
9 之后就可以開始撰寫測試報告、用戶手冊等相關文檔，測試報告會反應本次測試的目標，范圍，對象，執行過程即結論和風險分析
總結了一下，大概流程就是這樣的：
需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求確定(出一份確定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>制定測試計划，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本（可能測試的代碼 通過冒煙測試的代碼）－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員的確定（嚴重級別的，或突然發現的在測試用例范圍之外的，難以重現的），有些可以直接寫到TD（Test Director 相當於禪道））－>開發人員修改（可以在測試過程中快速的修改）－>回歸測試（可能又會發現新問題，再按流程開始跑）。