在前面中，講述測試主要的幾個階段，單元測試（Unit Testing）、整合測試（Integration Testing）、系統測試（System Testing）、驗收測試（Acceptance Testing）。就由這幾個階段，可以進行不同的顆粒度進行測試，當越前期越接近開發者端，開發者越需要重視，越後面越接近使用者，也就是越接近人的行為，因此 PM 、使用者們會逐漸加入，進行軟體的驗收。QA 團隊在不同階段發揮不同的作用。他們可能會參與單元測試的規劃和建立，協助整合測試和系統測試的自動化，並在驗收測試階段提供支援，確保軟體滿足最終用戶的期望，甚至是參與程式的撰寫。
早期沒有測試工程師時，開發者就會自己進行單元測試，當有測試工程師出現時，就會協助撰寫單元測試。比要常見的模式會是開發者根據需求文件，自行開發單元測試，而 QA 協助單元測試的建立與提供意見；而 QA 則是會進行整合測試、系統測試的程式碼撰寫，並且協助這些進行自動化流程。當然也會有開發者協助後面階段的程式撰寫，畢竟在寫程式的部分，對開發者而言是 piece of a cake。不過到底誰要做什麼事情，就視各團隊的運作方針。
然而在這幾個階段中，QA 也會進行除了功能測試外的檢測，像是安全測試、壓力測試、效能測試、回歸測試等等，這部分就與寫程式測試功能很不一樣了。未來會說明這部分，暫且先賣關子。藉由一些分工，可以讓整體的測試項目與涵蓋範圍變得更廣，適當的分工可以大幅提升產品的品質。
在實務上，這幾個階段並非一關接一關，一定要前面完成後面才能運作，有時我們會導入「Happy path」的概念，或是根據測試的涵蓋程度，提前展開下個階段（可能是準備或是執行），讓運作可以更流暢。
Happy path (可以稱為 happy flow，或快樂路徑)中， 「happy」指的是事情按計劃進行，沒有發生錯誤或異常的情況，讓人覺得很開心。「Path」是說操作路徑，通常指的是正常和預期的路徑，也就是是指一條沒有異常或錯誤情況的操作路徑（或是測試案例）。在測試方面，當通過所指定的 Happy path，表示我們認可這個功能完成低標準的驗收，也就是及格的概念，之後進行更詳細的測試，才能知道真正獲得的分數。因此通過 Happy path 表示這個程式有一定的可信度，這時可以進行下階段的測試，進行更詳細的測試。
由於 Happy path 的建立為 QA 帶領下，大家認同的驗收路徑，因此在開發完畢後，請 QA 進行測試前的動作，有這個動作，開發者可以大聲的跟大家說「我們做完了」（有時候會放在 sprint 結束後的 Demo 呈現），而 QA 團隊也就可以信任的執行下階段測試，不會一下子就遇到問題，卡住而無法測試。
舉個反面的例子說明，曾經遇過我們 app 要進行會員購物的行為測試，當我們拿到 app 時，發生登入功能有問題，造成無法登入，無法登入也就是無法測試會員購物。這時 QA 發現問題後，請 developer 進行修改，儘管任務輪轉很順暢，但，如果在提供給 QA 前就可以檢測到，就可以降低一來一往的時間浪費，可以更有效率。
有區分出測試階段及其任務，再加上 happy path 的導入，在運作中雖然加快，但是仍有不少需要調整，遇到最多都是個團隊之間的協同合作，尤其是現在分工日益清楚下，彼此的隔閡越來越大，這樣的問題實在是很難解。敏捷開發也許是個解決方案，但是其精神和落實仍是一個挑戰。
仍然提醒：這測試階段分類不是絕對的喔！會因為各團隊狀況有所不同。
iThome鐵人賽
看影片追技術