以測試視角反轉驅動產品的多樣性
測試，不該只是「測試」
「對於測試不被重視這點很有感觸！」，跟前同事簡單的一句對話，顯示了測試在業界中仍擺脫不了單純人力資源的刻板印象。造成如此根深蒂固的印象，不外乎是因為測試這個職位相比於其他開發職位更容易上手，但其實測試所能發展的空間遠比大家想像中的多且門檻與訓練成本也比想像中的高。
以軟體開發為實例，在許多人眼裡「測試」這個角色就應該是等產品規劃、系統開發完成後，依據開發好的內容進行驗收，不斷在這個流程中循環。在被動接收需求的前提之下，投入的測試資源會與任務的多寡呈現正相關，如果市場需求爆增，測試人力與時間成本亦會大幅上升，既有的流程與測試資源勢必無法負荷。
對企業而言，測試人力的增加是否具有一定品質保證的效果需要被評估，而一旦需求減少的狀況下，測試資源的去留也會是另一個需要被討論的議題。而對測試而言，思考容易被侷限、整體專案的視角無法提高、測試過程繁冗枯燥無法有新的刺激，連帶著個人的能力成長會無法突破，長此以往，對於測試人員的職能發展並不是一件好事。
而上述的現象在 2001 年獲得了轉機，17 位致力於優化開發模式的實踐者於美國猶他州雪鳥滑雪勝地共同宣布「敏捷開發」的模式，而測試領域也依循著開發模式的調整，迭代測試與測試左右移的概念也應運而生。測試的核心價值要貫穿整個軟體開發生命週期，專案中的每個參與者都應有其信念，不能將對產品品質的要求完全依賴於最後上線前的驗收，愈早揭露可能的潛在風險，愈能降低產品後期維護的成本。
調整了開發模式後，因為市場需求爆增而直接導致測試人力與時間成本上升的議題，則變成了必須被解決的問題。透過實際的經驗，其實只要將測試團隊負責的部份劃分成不同領域，將各領域的方案精鍊化並搭配自動化的輔助，在每個迭代進行交付品質的保證後，則可以有效的將人力資源最大化。每位測試都應具備特定領域的知識並歸納該業務測試的 SOP，並試著將其自動化，這樣才能在下次需求變更時，能快速透過自動化檢查基本功能是否無誤，並在特定時間段將資源投入到手動的探索測試中以優化使用者體驗。
需求由上至下 被動提出解決方案
在以往的合作過程中，會有個預期，產品經理應該是最熟悉產品的。但會有這樣的想法是因為產品經理透過了市場調查、競品分析，結合了他們的專業能力想出了一個適合現在市場動向的解決方案，依瀑布式開發進行任務的佈達，但其實這樣的模式可能會有以下的幾個痛點：
- 經驗相對少的產品經理無法聚焦需求且不容易於時程內被完整實踐。
- 解決方案的可複用性不高，對於不理解系統架構的產品經理，需要想出具可複用性的方案是相對費力的。
- 產品經理無法平行處理多個同性質的專案，也就無法搶得市場先機。
透過敏捷開發的中心思想「Divide and Conquer」，將大型的任務先行切分並將資源合理的分配至小任務中，透過不同 Sprint 的迭代將每個任務完成，依賴敏捷開發的推進，讓上述的幾個痛點減緩了痛苦，但問題的根本仍無法被有效解決。
原因在於真正實作或測試方並非在需求方，因此當需求方與實作方產生了衝突，為了讓產品準時上線，需求方只能被迫接受現實，以妥協後的解決方案完成產品。而實作方也因為時程的關係，以補丁的方式快速上線了堪用的解決方案，在系統與架構面上並未使用易擴展、易維護的解法，平台方案淪陷轉變成了支持各業務的系統。一個新的業務配上一個方案，並未將具有共性的解決能力提煉出來，不僅讓後續的開發不易，測試也難上手，一旦形成了負向循環，需求方閹割需求，實作方提供半套的解決方案，在架構設計不足的狀況下，作為測試的我們還能倖免於難嗎？
平台由下至上 主動完善業務能力
「產品與開發對於需求的理解不一致，測試需要花大量的人力溝通」
「線上問題的解決 workaround 跟這次的需求衝突，導致測試的情境需新舊兼容也需要花額外的成本處理線上有問題的數據。」
「外部合作方的需求發散無法限制，測試的案例與驗測時間無法收斂」
……以上是在測試團隊開週會時所提出的問題，不難發現，即便在敏捷開發的流程中，測試雖能透過方法論即早的揭露風險，但是能投入的成本仍然有限，一旦業務呈現發散狀況，資源終有被耗盡的一天。
幸運地是，測試 這個職位先天具有一些優勢 — 兼具產品思維與系統架構的知識地圖，針對產品的規格書能更加細化並協助定義行為；針對系統架構能提出調整建議並提醒開發系統的弱項，因此，由測試作為發起人與開發主動共同討論解決方案的構建，由下至上，反轉需求以驅動產品的多樣性是再好不過的。
舉個簡單的例子，每個專案或業務都會有「白名單」的功能，而白名單的使用時機，會被用在上線前的封測階段。就一般設計而言，專案要上線時發現需要白名單的功能，開發簡單做了一個機制後，會將其操作點分散在系統後台的各個功能點下方。雖說功能是一樣的，但因散落在各個業務域，難以控管也無法統整現在開啟白名單的資訊。測試若意識到這個痛點，直接與開發進行討論，並與產品共同設計出一提供白名單功能的平台，以聚合所有的需求 (e.g. 公司內部的 Dogfooding、特定時間段開啟/關閉、人員變更則自動 Disable、透過算法進行比例開放……)，並讓平台不僅是解決方案而是能力的提供者，進而透過這些能力充實產品的可能性。
再舉個例子，曾經以測試開發的角色參與了數個財務結算抽成的專案，當時跟開發所遇到的痛點是：「產品會時不時透過不同的交易模組與流程，讓不同身份、不同等級的使用者開通對於其較有利的交易模板。」在這樣的前提下，交易流程多變，情境多樣，適配的難度提高，必需有個統一的方案做為切入點，而如何快速支撐通用業務並客製化需求的能力，甚至完善這個平台所提供的能力讓產品部依市場的需求組建成新的商業模式，對客戶體系進行拉新且拉活，進而提高營收與使用者黏著度變成了我們這個方案的終極目標。
如下圖所示，抽出財務結算抽成的共性能力，平台化解決業務的需求，並告知產品目前在結算抽成的能力模組分為不同的領域，而產品能透過平台所提供的基礎能力進行搭建，快速的適配出需要的應用場景。而以測試而言，要有反轉的思維並不困難，只要對該業務域夠熟悉，並在測試的過程中理解每個服務與系統的能力，能在「需求確認階段」提醒產品在功能設計的先後順序，並告知現行系統所支援的能力；能在「系統設計階段」則告知開發能夠優化的方向，並與開發一同將組件化的能力培養起來，讓測試的工能事半功倍。
測試，不該只是「測試」
在軟體業界對於測試的培養與職涯的規劃課程並不多，因此有很多身陷其中的測試不明白自身的定位，日復一日重複著無趣且枯燥的功能驗證。但是其實測試這個職位不應該是這樣的，對於每個新的產品，測試是第一線的接觸者，由構思、規劃、設計、驗測、釋出、回饋，在驗證與優化整個產品的過程中應該是新奇且有趣的！不妨靜下心來試著想想看，如何讓測試的過程不再這麼乏味，如何能讓測試的效率提升不再是一直被追著跑，如何能讓測試的角色成為產品構建中不可或缺的一份子。
因為測試，不該只是「測試」！
Howard Chiang
2022.01.27
