測試人力配置策略（Test Staffing Strategy）：5 種測試角色比較與團隊分工指南

測試人力配置策略（Test Staffing Strategy）從待完成的測試工作出發，確認所需能力、承接人員與投入時間。

團隊可依需求不確定性、重複驗證量與產品風險，搭配行為驅動開發分析師、探索式測試人員、通才型專家、依腳本執行的手動測試人員與測試自動化專家，並確認效能、安全等專門技能缺口。

配置時須將學習、測試準備與後續維護納入排程，也要為自動化過渡期間保留驗證人力。先找出下一次交付的一項技能或人力缺口，記錄負責人、支援方式與到位日期，再依實際等待、重工與維護投入調整下一輪安排。

測試人力配置策略（Test Staffing Strategy）的決策範圍

從測試策略連到需要的人員能力

在 Disciplined Agile（DA）中，制定測試策略（Develop Test Strategy）是一項流程目標，協助團隊根據產品風險與品質需求，選擇測試方式，並準備所需的技能、工具、資料與環境。測試人力配置策略則聚焦各項測試活動需要的能力，以及具備這些能力的成員應在何時參與。

以線上購物的結帳功能為例，開發前需要有人和業務人員釐清折扣、運費與退款規則，將預期結果寫成可以檢查的具體範例。

功能進入可操作階段後，需要有人嘗試切換付款方式、返回修改購物車等操作，找出規格未涵蓋的行為與異常。

每次修改程式後，也需要重新確認既有功能是否正常，此時可安排具備自動化能力的成員，把需要反覆執行的檢查寫成測試程式。

每項工作需要的能力與參與時機不同。團隊應先確認要完成哪些測試活動，再決定需要哪些人員能力。例如，負責釐清折扣規則的人會需要在需求討論時就開始參與，若是等到功能完成才加入，就得回頭檢查程式已採用的計算方式。

依測試活動安排責任與投入時間

開發者測試（Developer Testing）也是人力配置時須納入的工作，包含由工程師撰寫與維護的單元測試（Unit Testing），用來檢查個別函式或小範圍程式邏輯。以折扣計算為例，工程師可以在實作時檢查免運門檻前後的金額與例外輸入，並將這些測試的撰寫、執行及修正時間納入開發工作。

品質要在需求釐清、設計與開發過程中建立。將計算規則拆成可獨立檢查的程式邏輯，並及早用測試確認結果，能讓工程師在進入完整結帳驗證前處理計算錯誤。

品質由全體成員共同承擔，相關責任也需要寫進工作安排。假設工程師完成結帳功能後，才發現測試人員正在支援另一項產品，團隊即使具備所需技能，功能仍得排隊等待驗證。排程若只計算撰寫程式的時間，測試工作就會在預定交付日期之前被壓縮。

安排人力時，可依功能的開發順序，確認由誰參與需求討論、由誰設計與執行測試，以及發現問題後由誰協助重現和確認修正結果。

同一位成員可以承接多種活動，例如工程師也能參與測試設計，熟悉業務規則的測試人員也能協助釐清需求。分配工作時，也要確認成員的熟練程度與可投入時間。若成員正在學習撰寫自動測試，排程也要預留練習與請同事協助檢查的時間。

測試人力配置要同時確認誰能做，以及何時能做。團隊在規劃時就應約定需求討論的參與者、功能可供測試的日期，以及負責驗證的人員。若同一位測試人員還要支援多項功能，就需要先協調各項工作的順序，或安排其他具備相應能力的成員承接。

五種測試人力選項與各自的投入條件

行為驅動開發分析師：將需求轉成可執行規格

行為驅動開發（Behavior-Driven Development, BDD）分析師擅長釐清利害關係人的需求，並將預期行為整理成可執行的規格。

這類規格以具體條件與預期結果描述功能，再透過測試程式檢查系統是否符合約定。在開發前備妥驗收測試，工程師就能依據相同範例實作，完成後也能執行測試確認結果。

例如，業務人員提出「消費滿千免運」，分析師需要確認門檻是依折扣前或折扣後的金額計算。若約定採用折扣後金額，就可以寫出「商品總額 1,100 元，折扣 200 元，仍需收取運費」的範例，和折扣後恰好 1,000 元的情境。

在開發前把預期結果說清楚，驗收測試就能同時用來界定需求與檢查成果。

這項工作需要需求分析、範例設計與細節追蹤的能力。分析師需要找出規則之間的矛盾，也要在需求變更時確認相關範例是否仍然成立。

配置這類人員時，應預留與業務人員、工程師共同討論的時間，並確認誰負責將範例接上測試程式，讓書面規格成為可以執行的測試。

探索式測試人員：找出預先未想到的行為

探索式測試人員（Exploratory Testers）在操作產品時觀察結果，並依發現的線索調整後續測試方向。他們需要理解產品的使用情境，從異常反應中辨識需要追查的線索，找出需求討論時未想到的行為。

以結帳功能為例，測試人員切換付款方式後，發現畫面上的折扣金額沒有更新，便可進一步嘗試返回購物車、修改商品數量，再進入結帳頁面，確認問題出現的條件。追查時也會檢查相關功能正確性，例如畫面顯示的金額與最後建立的訂單金額是否一致。這些操作有助於在交付前找出原先未列入檢查範圍的問題。

探索能力需要透過產品經驗與反覆練習培養，操作、觀察及追查也都需要人員投入時間。安排工作時，要預留記錄操作過程、重現問題與討論結果的時間。

確認問題的觸發條件與預期結果後，就可以評估將它轉成計測試用例（Test Cases）或是自動化檢查，例如每次切換付款方式後，自動比對折扣與訂單金額。

通才型專家：以專長為基礎承接相鄰工作

通才型專家（Generalizing Specialist）具備主要專長，也了解相關工作與業務領域，並願意學習其他技能。例如，一位擅長測試自動化的成員，同時理解軟體開發流程與電商的促銷規則，就能參與需求討論，協助確認哪些情境需要測試。

這類成員可依工作需求承接相鄰領域的任務。當折扣規則尚未釐清時，他可以和業務人員整理範例，規則確認後，再將範例寫成自動測試。

熟悉不同工作的限制，也有助於與同事釐清問題，例如發現某個測試需要難以準備的資料時，能與工程師一起調整測試設計。成員可承接的工作範圍擴大，也能探索其他職涯發展方向。

培養通才型專家需要安排學習與共同工作的時間，也要尊重成員希望深入專長或拓展技能的意願。跨領域工作的分配，應以成員已具備的能力與可獲得的支援為依據。例如，熟悉功能測試的人員剛開始學習自動化時，可以先和有經驗的同事共同完成一個測試，再依完成情況安排後續任務。

依腳本執行的手動測試人員：支援有明確步驟的驗證

依腳本執行的手動測試人員（Manual Testers from Scripts）依需求設計測試用例，寫下操作步驟與預期結果，再逐項執行並記錄實際行為。這裡的腳本指的是供人遵循的操作步驟，例如選取商品、輸入折扣碼、確認運費與送出訂單。

這種做法適合支援流程明確的使用者驗收測試（User Acceptance Testing, UAT）。例如，測試人員可事先準備訂單資料與操作步驟，讓業務人員依照流程確認折扣、付款及退款結果。每個步驟都附上預期結果，參與者便能記錄哪個環節符合需求、哪個環節需要重新確認。

手動執行的時間會隨檢查項目與重複次數增加。假設每輪驗證需要半天，一週修改三次功能，光是重跑同一批檢查就需要一天半，還要另外安排問題重現與修正後的確認。

當團隊頻繁交付小幅變更，重複檢查就可能占滿測試人員的工作時間，使其他驗證排隊。因此，配置時需要估計每輪測試的工作量，並確認哪些重複檢查值得轉為自動化。

測試自動化專家：建立可重複執行的檢查

測試自動化專家（Test Automation Specialists）能將預期行為寫成可重複執行的測試與檢查。這些檢查可用於回歸測試（Regression Testing），也就是修改程式後，再次確認既有功能是否仍然正常。例如，團隊調整折扣規則後，可以執行同一批測試，檢查不同購物金額、折扣與運費組合的計算結果。

安排測試分工時，可先盤點開發者已有的單元測試（Unit Testing）。當單元測試涵蓋重要規則與邊界條件，執行穩定且能指出失敗位置，就能減少自動化專家與手動測試人員反覆發現、重現及追查基礎邏輯錯誤的工作。

例如，折扣公式的各種金額組合由單元測試檢查後，自動化專家可將投入集中在付款與訂單的整合測試（Integration Test），手動測試人員則可多安排時間探索操作流程與確認業務情境。跨功能資料傳遞與完整交易結果也須驗證，測試範圍應依風險共同確認。

建立自動化需要先投入時間準備測試資料、撰寫檢查邏輯，並確認執行結果可信。對缺乏既有測試的系統，也要先釐清現有功能的預期行為，才能決定要檢查什麼。

配置人力時，可以從一組規則明確且反覆驗證的情境開始，例如折扣後金額低於、等於及高於免運門檻時的運費計算，再估計擴充其他情境需要多少時間。

自動化的人力安排需要涵蓋測試建立與後續維護。促銷規則改變時，測試中的預期結果也要跟著確認。測試執行失敗時，還需要有人判斷是產品出錯、測試資料有問題，或測試程式需要調整。安排自動化工作時，團隊應指定維護者，並預留處理這些失敗結果的時間。

依產品情境決定人力組合

需求不確定性與未知行為的比例

當產品正在試行新的促銷規則，團隊需要先確認哪些行為已有明確約定，哪些仍待討論。

例如，會員折扣能否與優惠券併用、部分退款後是否保留免運資格，都需要業務人員做出決定。這些規則尚未確認時，可以安排具備行為驅動開發（Behavior-Driven Development, BDD）分析能力的成員參與討論，將不同組合寫成具體範例，協助業務人員確認預期結果。

規則已經寫清楚的部分，也可能在實際操作時出現未預期的行為。假設顧客在付款失敗後重新套用優惠券，系統就需要正確處理優惠券的使用狀態。團隊可以安排探索式測試人員（Exploratory Testers）嘗試中斷、重試與返回前一步等操作，並將發現帶回需求討論。

系統行為若缺少對應的業務規則，就要請負責該規則的人確認，再決定如何修改與驗證。

人力組合可以隨待釐清的需求與待探索的行為調整。本次變更若集中在促銷條件，便可多安排需求分析的投入。規則確認後，若又新增跨頁面或跨付款方式的操作流程，就需要預留探索時間。

兩類工作可以由不同成員分擔，也可以交由具備相應能力的同一人承接，排程時仍要分別估計所需時間。

重複驗證頻率與既有系統的投入成本

若結帳功能每週更新，每次都要重新檢查付款、折扣與退款，團隊可以先記錄一輪驗證需要多少時間，以及其中有多少項目會反覆執行。

對預期結果明確、每輪都要檢查的項目，可以安排測試自動化專家（Test Automation Specialists）評估建立自動測試所需的工作。某項驗證若僅用於單次活動，且準備自動化需要大量時間，也可以先安排人員依明確步驟完成。

安排投入時，可用測試金字塔（Test Pyramid）決定各層測試的比重：以大量單元測試（Unit Test）檢查程式邏輯，搭配應用程式介面（API）層級的測試確認服務行為，並保留較少的使用者介面（UI）與端對端測試（End-to-End Test, E2E）驗證關鍵流程。

透過畫面驗證完整交易時，測試會依賴頁面元素、網路、測試資料與多個服務，畫面改版或環境不穩都可能讓測試失敗，需要人員追查原因、更新腳本或重建資料。

自動化人力應優先投入可在單元與介面層確認的規則，再為關鍵交易保留完整流程驗證。例如，由開發者維護折扣計算的單元測試，自動化專家與工程師共同補足付款介面的檢查，再保留少量從購物車到付款完成的端對端測試，並依產品風險調整範圍。

既有系統缺少測試時，導入自動化還需要處理起步階段的工作。例如，測試退款流程前，必須先建立一筆已付款的訂單，而舊系統只能透過人工操作準備這筆資料。自動化人員便需要與熟悉系統的工程師合作，找出可重複準備資料的方法。估計投入時，要把這段準備時間與測試程式的撰寫時間一起計入。

轉入自動化的過渡期間，仍需為當前交付安排驗證人力。團隊可以先選定一組每次發布都要執行的付款檢查，由自動化人員建立並確認結果，同時安排手動測試人員承接尚未涵蓋的退款情境。

確認自動檢查能穩定執行，且有人負責處理失敗結果後，再調整原有的手動工作量，將時間移到新功能或尚未探索的操作上。

專門風險與團隊現有技能的落差

當結帳功能準備支援促銷活動，預期同時下單的人數增加，測試就需要確認系統在大量交易下的反應。這項工作需要效能測試（Performance Testing）的能力，包括設計接近實際使用情境的負載，以及判讀回應時間與失敗情況。

交易資料的保護則涉及安全測試（Security Testing），例如確認顧客能否透過修改請求中的訂單編號，讀取其他人的訂單。兩項工作都需要對應的技術知識與測試經驗。

法規與產業標準也會帶來額外的驗證需求。若產品適用歐盟一般資料保護規則（General Data Protection Regulation, GDPR），就需要依資料處理風險驗證保護措施，並考量定期測試與評估其有效性。

例如，可檢查個人資料的存取權限，以及符合刪除條件時，系統能否依已確認的規則處理資料。涉及信用卡資料的系統，則需確認信用卡產業資料安全標準（Payment Card Industry Data Security Standard, PCI DSS）的適用範圍與驗證要求。GDPR 屬於法規，PCI DSS 屬於產業安全標準，團隊需要分別確認適用條件。

這些驗證工作需要法務或合規人員協助界定要求，再由資安、開發與測試人員將要求轉成可執行的檢查。人力安排也要涵蓋測試證據整理、缺失修正與重新驗證的時間。

例如，權限測試通過後，仍需保留所測版本、帳號權限與執行結果，供後續查核。適用的 PCI DSS 驗證要求若涉及外部弱點掃描或專業評估，也要提前確認所需資格與外部人員的檔期，避免因證據不足或驗證安排過晚而延後交付。

前述五種人力選項可用來討論工作分配，特定風險所需的技能仍要另外確認。擅長撰寫功能自動測試的成員，對負載設計、權限檢查或合規驗證的熟悉程度仍要個別評估。

團隊可以用技能矩陣（Skills Matrix）將待執行的測試工作與成員對照，記錄誰能獨立完成、誰需要協助，以及哪些工作目前無人能承接。盤點時可以請成員說明曾處理的案例與能負責的範圍，避免只依職稱安排工作。

以下以準備交付退款功能的三位虛構成員為例。「可獨立」代表能完成該項工作並判讀結果，「需協助」代表需要有經驗的人指導或檢查，「待培養」代表目前尚未具備可承接的能力。

從表中可見，退款計算與介面檢查已有可承接的人員，效能與安全測試則需要額外支援。安排支援時，要確認專家能參與的日期，並預留自動化人員或開發人員共同執行的時間。

技能矩陣呈現可承接的能力，排程還要另外確認可投入時間。例如，業務測試人員同時負責需求釐清與探索測試，就要分別估計兩項工作的時間，避免把她安排在同一時段處理兩項任務。

近期交付的高風險功能若存在技能缺口，可以安排具備專長的人員加入，並讓現有成員共同參與測試準備與結果分析。

交付前尚有時間準備的工作，則可安排成員在指導下承接一部分。例如，首次進行負載測試時，由有經驗的人員確認測試情境與判讀結果，現有成員負責準備訂單資料和執行測試，並在下一輪前確認哪些工作已能獨立完成。

將配置決策落實到團隊工作安排

從近期交付項目確認技能缺口與到位時間

選定下一個預計交付的功能後，團隊可以沿著需求討論、開發與驗證過程，把需要人員投入的測試工作放進排程。

以新增退款功能為例，開發前要有人確認部分退款的計算規則，開發期間要準備已付款的訂單資料，功能可操作後則需要執行退款、檢查金額，並確認重複送出申請時的處理結果。

每項工作都要對照現有成員的技能，確認可以獨立承接的人選，以及需要協助的部分。

接著將這些工作與成員手上的任務一併檢視。假設退款測試預計週三開始，負責自動化的成員卻要到週五才能完成付款功能的測試，排程就出現了衝突。

團隊需要估計兩項工作的投入時間，再決定調整順序、縮小本次交付範圍，或安排具備相應能力的人員支援。支援者若需要先熟悉退款規則與測試環境，這段準備時間也要算入。

每項測試工作都應記錄負責人、所需支援與最晚到位時間。這些資訊可以直接放在功能的工作項目中，例如註明由誰在週二前備妥測試訂單、由誰從週三開始驗證退款，以及遇到金額差異時要找誰確認。

需求或開發進度改變時，負責人就能依這份安排確認受影響的工作，重新協調測試日期與支援時段。

安排共同工作與測試成果的維護責任

測試發現問題後，可以安排相關成員一起重現與確認。假設測試人員發現顧客在付款畫面沒有回應時再次送出，會造成重複扣款，就可以和工程師一起檢查操作順序、訂單狀態與付款紀錄。

重試的預期行為若尚未約定，也要請熟悉付款規則的人參與，確認系統應如何處理同一筆訂單的再次付款請求。

預期行為確認後，由具備自動化能力的成員將重現條件轉成檢查，並與修正程式的工程師確認測試能否偵測原先的錯誤。

團隊也可以在這項工作中安排結對編程（Pair Programming），讓正在學習自動化的成員與有經驗的同事共同撰寫測試。一人操作時，另一人協助檢查測試資料、判斷條件與執行結果，再交換工作。安排時要預留雙方共同投入的時間，並說清楚學習者這次要練習的範圍。

測試成果留下來之後，還需要有人承接規則變更與執行失敗的處理。團隊可以在相關工作項目中註明測試用例（Test Cases）與自動化檢查的位置，以及負責維護的成員。

當付款重試規則改變時，由負責需求的人確認新結果，再由測試維護者更新步驟與檢查條件。原維護者轉往其他工作時，接手者應先實際執行一次測試，確認能準備資料、讀懂失敗訊息，並找到對應的業務規則。

結語：從一項交付工作檢視測試人力配置策略（Test Staffing Strategy）

選定下一次交付中尚未有人承接的測試工作

測試人力配置策略可以從下一次交付開始落實。拿出一項已經排定的功能，檢查其中是否還有無人承接、缺少所需技能，或負責人沒有時間處理的測試工作。

五種人力選項能協助團隊描述需要的能力，再依產品風險與現有成員的情況決定如何搭配。

例如，退款功能即將交付，卻還沒有人能確認重複申請的處理結果，就可以先將這項缺口帶入團隊討論。現有成員若能承接，便確認投入時間。需要培養技能時，則安排指導者與練習範圍。交付前無法備妥所需能力時，就要協調專業人員支援，或重新安排該功能的交付。

這次討論應留下可追蹤的決定，包括承接人員、支援方式與確認到位的日期，好讓後續的持續改善有所依據。

用實際等待與重工調整下一輪配置

完成一次交付後，團隊可以對照原先的人力安排，檢查測試在哪裡等待、哪些需求反覆確認，以及維護測試實際用了多少時間。退款驗證若因無人能確認計算規則而停了兩天，下一輪就需要提早安排熟悉業務的人參與。測試人員同時承接過多工作時，則要重新協調工作順序與可投入時間。

每次檢視可以先選一項已經造成等待或重工的問題，將調整寫進下一輪安排。例如，已建立的自動化檢查因促銷規則變更後無人更新，遲遲無法使用，就應指定維護者，將更新與確認結果的時間排入工作。下一次交付時，再確認這批檢查是否如期恢復使用，以及負責人是否有足夠時間處理執行失敗的結果。

• 優化團隊（Optimize Team）：人員配置與技能運用的五種選擇
• Agile testing