三種 QA (Quality Assurance)


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

第一種:獨立的 QA 部門

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

規模大一點的,除了公司自己產品的 QC 負責 IQC/OQC,另外還會有自己的實驗室、認證中心、制定認證的團隊,甚至是專門執行認證與稽核的業務,更大的就是獨立成一種獲利模式的公司,專門蓋章用,具備權威性,像是 ISO XXXX …

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

缺點:

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

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

通常是以技術導向的。這類的 QA 要懂技術,會寫 Code,懂得自動化工具。依照不同產品性質,需要條件如下:

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

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

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

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

常見問題:

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

解法:

  1. 導入 持續部署 (Continuous Deployment),相關概念:
  2. 測試環境有持續部署,才有辦法在內部形成溝通循環,減少溝通成本,然後 持續交付 (Delivery) 才有品質
  3. 讓 QA 團隊可以獨立運作,包含學習瞭解系統架構、環境建置、配置管理。相關文章:
  4. 不要以為手動測試不重要,手動跟自動是相輔相成,這比例問題,不是 0 / 1 問題,理想是 2:8,能做到 6:4 就很棒了。
    • 如果一級主管都不知道產品怎麼用,那這產品不會好到哪去。
    • 主管會怎麼用?手動啊,難道還自動啊 XD
    • 手動的重要性在於:客戶的真實行為、感受、體驗
  5. 基本上溝通要時間,描述問題要時間。講過的東西會忘,寫下來的不會,所以與其花很多時間溝通,不如花時間訓練同仁如何寫文件。參閱:
  6. 使用 Issue Tracking 平台,標準化溝通方式。相關文章:
  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 更多關注的是程序品質,確保程序能產出有品質的產出物。

DevOps 有三個圈圈 (下圖),當這三個角色失去平衡的時候,剩下能處理的,只有政治問題了,嚴重的,會有 沙賓法案 的問題。


延伸閱讀

測試系列

DevOps 相關

概念


Comments