「老闆，為因應多國語系，以及多平台的支援，我要增加 QA 團隊的編制到對應的國家數與平台數。」這是我聽前輩轉述的歷史，也是一個 QA 被團滅的故事。之前有提過，許多工程師習慣性的依賴 QA ，將程式品質的把關，全交由 QA 在發佈前進行驗証。嚴格說來，這屬於 QC (Quality Control)。這樣惡性循環的發展，當組織與產品隨時間變得愈來愈複雜時，QC 的編制也必須愈來愈大。這可能嗎？

讓我們回歸系統層面來思考，應該如何善用團隊中珍貴的 QA 資源。

QA 與規畫系統

回顧之前的開發系統流程圖，在圖中兩個時間點，有 QA 的投入，對規畫活動會帶來最大的幫助。在 Refinement 中， 厲害的 QA 可以根據 Spec 分別對設計師與工程師提出建議。例如：

• 某個流程是否會造成使用者體驗不佳
• 某個 UI 在過往類似的經驗中，工程師容易忽略對多重點擊 (Multi-touch) 的保護
• 各種前端、後端的錯誤處理

假設產品經理，設計師，工程師的合作，能把規畫做到 80 分，而 QA 的投入，我認為可以補足到 95 分。為什麼不是 100 分呢？我認為在敏捷中，重要的是在交付價值，而不是追求完美，在規畫階段執著那最後那 5 分，實際邊際效益可能不會太高。

在 Planning 之後， QA 可以再針對要交付的項目，做一次 Test Review ，目的是在與開發團隊同步在該 Sprint 中的實作項目，要注意的相依性問題、QA 會加強測試的流程與元件，協助埋首開發的 RD 可以產出高品質的交付。

交棒 QA 的時機

一個最理想的狀況是，團隊與 QA 有高度的合作默契，在 Sprint 的結尾可以如期交付。但實際的經驗中，在團隊轉型期，QA 最容易是承擔高度張力的工作。我們來看一下 Sprint 行事曆，如下圖。 QA 通常是在 Sprint 的最後幾天，才會拿到 RD 提供的測試版本。如果 RD 沒顧好自己的產出品質，那麼 QA 的工作時間會進一步的被壓縮。

這個系統問題，需要主管做一些判斷。團隊不會一天就改善到定位，不管是持續的教育會換血，老闆在乎的商業價值永遠是第一順位。我採用過的變型方式，是讓開發系統和 QA 系統獨立開來，如下圖：

這是為了舒緩系統張力，曾經使用過的一種方法。一旦團隊的調整逐漸到位，我還是建議回歸原本的節奏。

團隊系統的 QA

之前的文章有提過，我把團隊系統當作一個產品，如果在設計系統的同時，有 QA 加入，對各個訊息結點、產出、Retro 進行品質審查，我認為可以會有更好的效果。目前的團隊中，我就嘗試與 QA 進行跳脫產品生產的維度，來看組織面的品質。其實，我認識不少 QA 出生的高階主管，對風險控管與量化的思維，對我有更多的指導。

不厭其煩的再提醒，不要把 QA 當 QC ，如果認同規畫系統的價值，就更該讓 QA 在其中發揮專業，品質的提升不應只專注在交付，從規畫時就該注意喔！