QA 的工作內容落差很大，要求的條件落差也很大。有的公司 QA 是獨立部門，有的是掛在 R&D 底下，有的則是掛在 PM 底下。

20230523 更新：本文內容部分收錄在 共同著作《軟體測試實務》 第一冊 第一章之中，歡迎大家彭場指導。

三種

第一種：獨立的 QA 部門

組織上他會與 R&D 平行，直接面對產品長、總經理、CEO，甚至有 CQO, Chief Quality Officer 的層級。

規模大一點的，除了公司自己產品的 QC 負責 IQC/OQC，另外還會有自己的實驗室、有完整的知識體系 (像是 Issue Tracking 在企業裡的價值 - KM)、認證中心、制定認證的團隊，甚至是專門執行認證與稽核的業務，更大的就是獨立成一種獲利模式的公司、專門蓋章用、具備權威性，像是 ISO XXXX …

這種 QA 單位，技術、與領域知識並重，是完整的營運單位。

缺點：

1. 容易形成穀倉 (Silo)
2. 溝通成本較高

第二種：掛在 R&D 底下的 QA

通常是以技術導向的，也是最常見的類型，第二常見的是掛在 PM 底下的。這類的 QA 要懂技術，會寫 Code，懂得自動化工具。依照不同產品性質，需要條件如下：

• 產品本身就是技術性產品，例如網路設備、專業音樂編輯軟體，通常這類的 QA 需要具備一定程度的領域知識與專業能力，知道很多實際的使用情境。
• 產品本身是消費性的，例如電商網站、人資系統，大部分 QA 不需要具備專業知識，就可以入門。

如果要做自動化相關，不管哪一個領域，都要一定程度 QA 才行。

在這樣單位底下，通常大主管 (R&D Head) 會用 技術導向 來看 QA 這件事情，而看不到 程序問題，我說通常。

這種單位的用人，習慣性的會問用什麼 automation tools、什麼程式語言，而不是問 QA 在整個開發流程扮演怎樣的角色、SDLC 該怎麼調整、怎麼有效回報問題、怎麼溝通、組織與分析問題、測試方法、測試管理 (Test Management) … 。

• 類似概念整理在： Software QA 的職能條件、協同合作系統建制與導入 - 以 Redmine 為例

常見問題：

1. QA 放在 R&D 底下，從組織職權來看，很容易變成相對弱勢，換言之，無法發揮把關的功能
2. 因為不是獨立運作，系統配置，像是 Resource Provisioning、Deploy 都仰賴 R&D，QA 無法獨立運作
   • 很多 Developer 不知道 Config 是需要設計的 (DI / IoC / SOLID 原則都白學了)
   • 很多 QA 不知道 Config 是要被驗證的, 不知道自己測的東西是怎麼來的 …
3. 很容易變成附屬單位，或者是裁員的第一坡名單
4. 現象：大部分 Startup 都是這種的，或者第三種。
5. 通常大主管 (R&D Head) 覺得自己懂品質
6. 以為品質應該是 立竿見影。。。恩，我覺得吸毒才是立竿見影。有空用系統思維的 Archetype 來說明品質這件事。

解法：

1. 導入 持續部署 (Continuous Deployment)，相關概念：
   • 導入 CI/CD 的第一步, 怎樣的 CI/CD 才夠 Quality?
   • Artifacts Management, 聊聊軟體交付的濫觴 談產出物管理
   • 軟體交付的四大支柱
2. 測試環境有持續部署，才有辦法在內部形成溝通循環，減少溝通成本，然後 持續交付 (Delivery) 才有品質
3. 讓 QA 團隊可以獨立運作，包含學習瞭解系統架構、環境建置、配置管理。相關文章：
   • Resource Provisioning and DevOps
   • Version Control
   • Artifacts Management, 聊聊軟體交付的濫觴 談產出物管理
   • Config Management
   • QA 團隊無法做到上述的條件，只能說是 QC，定位就是附屬單位了。
4. 不要以為手動測試不重要，手動跟自動是相輔相成，這比例問題，不是 0 / 1 問題，理想是 2:8，能做到 6:4 就很棒了。
   • 如果一級主管都不知道產品怎麼用，那這產品不會好到哪去。
   • 主管會怎麼用？手動啊，難道還自動啊 XD
   • 手動的重要性在於：客戶的真實行為、感受、體驗
5. 基本上溝通要時間，描述問題要時間。講過的東西會忘，寫下來的不會，所以與其花很多時間溝通，不如花時間訓練同仁如何寫文件。參閱：
   • 如何有效的回報問題
   • 為什麼寫文件？
   • 溝通 = 成本
6. 使用 Issue Tracking 平台，標準化溝通方式。相關文章：
   • Issue Tracking in Redmine
   • 寫在介紹 Redmine 之前
   • 協同合作系統建制與導入 - 以 Redmine 為例
7. 導入 Test Management
   • 這我都還沒時間寫，不過推薦的就是 Testrail，或者 VSTS 也有整合，但要另外付費。

第三種：附屬在 PM 底下

掛在 PM 底下的 QA，其實應該叫 QC，很多時候是 PM 兼著做，因為 PM 要測了才知道產品長怎樣。

工作以產品內容的商業邏輯確認為主、專注的不是技術，需要很清楚產品的內容、需求規格、流程等。

技術性質的工作則會倚賴 R&D 單位。

常見問題：

1. 容易以成本考量，QA 專業會直接被忽略
2. 外行領導內行，忽略職能的專業

解法：

1. 職能拆分，聘請專業的 QA 團隊，如果是軟體產品，建議找懂 Agile / Scrum 的人加入
2. 讓部分 PM 專職做 QA，讓 QA 專職做 PM

結論

整理職場路上曾經遇過的幾種 QA 團隊、組織、權責的分類，這三種我都遇到了。QA 的定位，跟組織定義、產品方向，很有直接關係，定位不清楚的，不只影響公司的發展，也影響這些人的職涯。

最後這張圖是我擔任 SQA Manager 時開的 Job Description，重點是紅色框框裡的：

JD 裡要強調的是，團隊合作的重要性：海賊團裡面每個人都有不同的專業背景，但是有同樣的目標！

共同目標很重要、團隊溝通很重要、協作很重要、敏捷很重要，但請不要因此想要消滅、忽略個別的專業、職能，這只會製造更多對立、不信任的問題。

我當時的組織是 QA 在 R&D 裡面，但是我的老闆跟我說：我的位置是跟他一樣的 (協理級)，所以希望我用那樣的高度建立團隊，而當時我也的確用這樣的高度在規劃整個組織。

補充 (2018/05/02)

這篇是幾年前，朋友問我的問題，過了一段時間，重新整理過，還是很感慨。

這幾年要殺掉 QA 的聲音到處都是，特別是 DevOps 越來越流行之後，幾乎都把 QA 的聲音蓋掉了，應該沒有人聽過 QAOps 吧？只是常常會聽到說 Automation 之後就不需要 Q 了。。。

從來沒有人敢喊 NoDev, NoPM, NoBoss …

其實常常是會覺得莫名其妙，因為大部分開發語言與環境 (IDE) 跟測試相關的整合，並不是那麼完美，而且寫 Automation 這件事情難度是高的，特別是新創團隊，如果人員素質參差不齊，工具與訓練還不完善，所以為的 Automaion 只是行銷用語：唬爛用的。。。

另外要再次強調的是：QA 不是只有找問題、Automation 這種表面的東西，QA 更多關注的是程序品質，確保程序能產出有品質的產出物。

• 自動化的想法與經驗參閱：自動化帶來的問題、軟體自動化測試常見的問題、自動化 XXX 的陷阱

DevOps 有三個圈圈 (下圖)，當這三個角色失去平衡的時候，剩下能處理的，只有政治問題了。

延伸閱讀

測試系列

• Software QA 的職能條件
• 淺談軟體測試的階段與策略
• 軟體自動化測試常見的問題
• 如何有效的回報問題
• 新書上市 - 共同著作《軟體測試實務 I、II》

DevOps 相關

• Resource Provisioning and DevOps
• 導入 CI/CD 的第一步
• 怎樣的 CI/CD 才夠 Quality?
• Artifacts Management
• 聊聊軟體交付的濫觴 談產出物管理
• Version Control

概念

• Software Development Lifecycle
• 自動化帶來的問題
• 自動化 XXX 的陷阱
• 協同合作系統建制與導入 - 以 Redmine 為例
• 為什麼寫文件？
• 溝通 = 成本
• Issue Tracking 在企業裡的價值 - KM