Software QA 的職能條件

很多事情，換個角度會有完全不一樣的見解。這篇文章整理我個人對於 SQA 職能的一些想法與經驗談。

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

我的 SQA 經歷

As a Software Developer, Unit Test / WebUI Integration Test / Automation Test

很多年前 (2007 吧?)，我的主要角色都是 Developer，參與的工作大多都是 J2EE / Eclipse Plugin / Websphere Application Server / z System (3270, 5250) … 等相關。有一次跟老闆聊天聊到對於『測試』的看法，當時我還沒做過 QA 工作，不過就我知道的分析給老闆聽，但心裡其實知道一件事就是：測試不是那麼好做的，比開發難很多。

過沒多久，我參與一個日本 Banking 使用的 middleware framework 開發測試。其中一個工作內容是開發 code generator (產生 Java code with design pattern)，然後自己要做做自動化驗證，那時候用了很多 ANT / shell scripts / Eclipse Plugins 等 … 跑自動化測試、產生報表等。

2008 金融海嘯，我又到另一個專案，角色還是 Developer，這次專案上有自動化測試的項目，QA / Tester 沒辦法接，我主動接了起來，測試包含 GUI / Eclipse / Web 自動化:

Web GUI: 用 RFT 做 WebUI 的自動化
IDE 的測試：主要是 Eclipse Plugins 應用程式的自動化測試。我們的產品是 IDE (Eclipse Plugin)，然後用另一個 IDE 來測產品，就是用 IDE 測 IDE …. (超級過癮的 eclipse 測 eclipse) …..

這個過程，除了了解自動化的流程，技術、測試的項目，還自己實作 log engine、test case management、report、gui common test libraries .. 等。

RFT: Rational Functional Tester，是 IBM Rational 開發產品線的其中一個產品。

As an SQA member, focus on Regression Test

後來加入一個防火牆產品的 SQA Team 裡，這就是真的是在 SQA 的角色了。負責 Firmware 測試，在 Fixpack Team (有點像 Hotfix ，但不是很急的問題，大多都是效能問題。SQA 裡分 Release 和 Fixpack 兩個 Team)，專注在 Regression Test，目的就是：

驗證 所有 Release Build 累積發現的新問題，新功能則由 Release Team 負責
這些新問題都要可以自動化測試，而且每次都要針對不同的客戶測試
不同的客戶是有不同 Build 的，我們稱為 Customer Build，因為客戶夠大，付的錢很多，他們不要新功能，只要穩定。
Customer Build 累積數量約四十個。
- 也就是說，同一個版本就要跑四十種不同的 Build。那時候幾乎每天都有客戶都要跑 Regression，然後都是一天內要跑完。有時候一天多的話，會有三到四個要跑。

Fixpack Team 面對的客戶都是全球各州的超大銀行，這些銀行都很有錢，所以要求也很高。剛好有機會要導入自動化測試，我主動開發了分散式的 Test Framework，導入到整個 Team 裡。整合了很多奇奇怪怪的既有 scripts (c / c++ / perl / python / bash / java)，把測試流程、build 的流程、測試的技術、教育訓練、測試角色定義、報表、資源監控管理都包含在整個 Framework 裡。Test Framework 完成開始執行之後，就變成 Product Certificate Test，出貨前一定要走的蓋章程序。這過程學到很多自動化的經驗與想法。

淺談軟體測試的階段與策略: 這段開發的摘要在這篇的 Designing Test Architecture and Framework，包含測試流程定義、Lifecycle、Lib、Report、Resource Management … 等。

軟體自動化測試常見的問題: 整合過程踩過的雷則記錄在

總結我自己前半段 SQA 經歷，以及後半段 SQA Manager / SDET Lead 經歷如下圖：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

因為上述的經歷，後來加入 startup 新創事業，挑戰 SQA Manager 角色，專注在流程與管理面，這些體悟又更深了。整理一些 SQA 不為外人所知的現象。

註一：相關經歷分享參閱演講：從理想、到現實的距離，開啟品味軟體測試之路
註二：SQA: Software Quality Assurance, 指的是軟體品質保證。QA 這個詞我個人傾嚮他是個流程、制度，而非組織，或者角色。就像 DevOps 應該是一種流程、制度，而非組織角色。

本文

主題提到的 How to be an SQA，我分成以下兩大部分：

專業技能: 硬技能，指的是 IT 技術，包含系統能力、配置、系統開發、自動化、網路基礎知識 .. 等
軟實力: 包含表達、溝通、組織、分析、協調等能力，比較偏管理技能的部分。

1. 硬技能

獨立建置測試環境，知道環境的範圍，Component 之間的關係與介面。
具備基本 coding 能力:
- 至少一種直譯是語言：像是 javascript, python, bash，推薦 python + bash
- 學習 SQL
- 能夠了解 HTML / CSS / Javascript
- 熟悉一種以上的 IDE or Editor: 首推 vi，過了廿年依舊好用。
系統管理 / 配置能力:
- 系統：Linux / docker / K8s
- 網路：ssh / ngnix / tomcat / apache
- 資料庫：MySQL / PostgreSQL
網路基礎知識以及工具: WAN / LAN / TCP / UDP / HTTP / DNS / tcpdump / wireshark …
自動化: 大哉問

1.1 測試環境建置與配置

這非常重要，模擬系統設定，對系統架構部署的影響。我的基本原則是：

沒什麼環境是無法模擬的，除非你測的是太空船。

所以環境的建置是基本，且重要的基礎能力。環境配置的問題不能等到了維運才發現，因為線上的系統維運，不是說改就改，說停的停的，所以他是測試的一環。

環境的配置牽涉到 服務 (Service) 定義，每個 Service 都有自己的 Endpoint，以及和其他 Service 通訊介面，像是協定、資料結構等，例如走 TCP or HTTPS / gRPC。清楚知道這些關係，測試過程，才有辦法釐清問題的節點是在哪裡；部署時，才知道要怎麼調整，然後找出架構性的問題。介面還有一個很重要的就是錯誤處理，Service 彼此溝通時，如果遇到 Exception 該怎麼處理，會出現什麼狀況。類似問題，如果上正式環境才發現，都是很棘手的問題。

註：以前還沒有服務化的概念，所以通常都稱為 Component。隨著時代推進，現在習慣稱為 服務 (Service)，每個服務都有一個獨立的 Endpoint。

這段能夠自動化最好，而且測試環境的配置必須是跟線上的一致，最常被忽略的像是 SSL Certificate, DNS 配置。

測試目標能否配置、要怎麼配置，需要 developer 配合設計，利用 IoC / DI / AoP 等概念，設計出配置依賴互轉的功能。如果沒有辦法配置，那麼對於測試工作來講，是很卡的，而且也會限制整個測試的廣度與深度。上線後問題會反撲回 Developer 自己，然後 QA / PM / SE / AE 會在那邊乾著急。

環境的配置會跟 SE (System Engineer) or 現在很潮的 DevOps 有關係，因為這些單位往往需要知道部署時要如何配置，然後才是考慮線上的部署調配。 SE/DevOps 需要跟 Developer 了解配置的細節，需要跟 QA 了解可能的問題，以及測試環境如何配置。進而更清楚線上系統該怎麼調配。

比較有規模的公司，像是 Trend Micro、IBM，或者 KKBox 都有獨立的 QA / SQA / QE 部門，硬體廠 (網通) 則會花錢蓋實驗室 (就像義美一樣) ，而且具備一定的技術能力，需要配置自己的測試環境。這種測試環境有個很重要的目的：在理想的條件之象，量測 (Measure) 系統的狀況，或者在很髒的環境之下，執行壓力 (Load test)、效能 (Performance)、穩定性 (Stability)、可靠度 (Reliability)、容錯 (Fault Tolerance) 等測試。

不過大部份的台商公司，QA 往往都是屬於附屬單位，大多僅止於 *能動- 就出貨的程度。很多公司都是為了省錢，所以往往忽略這段，然後問題都是上線 / 出貨的之後才發現。上線 / 出貨之後的成本遠比測試環境的成本高很多。

建置 (Provisioning) 參閱 Resource Provisioning and DevOps

Artifacts Management

Version Control 與 Artifact Management

1.2 測試工作 (Test)

這是大部份人認為 QA 的主要工作項目，但實際上他只是 項目之一，下述是之一：

根據 Spec 找問題, 也就是一般測試, open / verify bug
根據未來部署環境，找上線後可能會發生的問題
找出效能問題, 必要的話, 要自動化, 目的是提高效率。技術上，這是另一個課題
針對錯誤處理 (Error Handling) 提出建議
提出建議, 不管是 UI / UX, 甚至是 Design / 架構 / 部署的問題

最後兩點其實很多公司的 QA 不會做這個，即使做了也不會被重視，那其實只有 QC 的範圍而已

硬體廠的品保部門就會直接叫 QC，分成 IQC / OQC.

關於 QA, QC 的觀念請參考 “QA、QC，傻傻分不清楚！“，台灣的老闆有 9 成以上都不懂。

1.3 自動化 (Automation)

自動化是現在軟體工程很重要的一環，加上現在很流行的 CI / CD / DevOps 等趨勢，他更是這些概念的基礎建設。

自動化的程式開發，不會只有在應用層 (Application)，通常會跟系統打交道，所以需要懂得很多系統程式設計，像 script、跨平台的技術處理能力、流程控制、文字分析、資源管理與整合、部署 … 等，其實範圍非常大，具備這樣能力的人，更是難找。

所以自動化測試職缺的條件，應該是要具備 Developer + System Engineer 背景的，而且是 Senior 的，兩者缺一不可。然後再加上對於產品的 Know How 與做過測試與了解流程，才適合做自動化測試的工作。Junior 其實是不太適合做這樣的任務。

“自動化” 會用在很多領域，像是測試、部署、控制、監控、效能等。這是很深的課題，可以參閱其他的分享文：

軟體自動化測試常見的問題

Designing Test Architecture and Framework

自動化 XXX 的陷阱

2. 軟實力

技術、硬技能以外的技能，都是軟實力、軟技能。

溝通表達: 口說、文字
Bug 追蹤的流程
組織與分析
協調能力
測試階段與策略
專案管理

2.1 溝通表達能力

如何陳述一個問題，清楚且精準的表達，表達包含圖、文的呈現、口說。我在協同合作系統建制與導入 - 以 Redmine 為例提到 template 的想法，他就是把描述問題的過程作正規化的規範。

最基本的就是開 bug。如何把 bug 說清楚，講明白，讓 developer 很快的復現、找到問題點。
把問題的關聯性找出來，要具備細心，組織與獨立思考能力。
提出『建議』，更好的做法，甚至是發現設計上的盲點。

其實不只是 QA 需要，Developer 也很需要這能力。但實際上開發過程中，Developer 往往被時程壓得半死，然後規格又一直被亂改，加上要學習新東西，這些事情就會被忽略了，衝突很容易因此而起。

更多參閱：如何有效的回報問題

2.2 Bug 追蹤的流程

測試執行過程中，要怎麼有效地追蹤以及掌握 Bug 的狀況，通常會有幾個指標性的重點：

Bug Open 的數量以及速度
測試執行的比率
Developer 解 Bug 的速度
Bug 嚴重性的數量

如果上述的數字都在一定等級之上，表示產出問題很大，那麼就要請 PM / Developer Leader 協助注意狀況。

工具請參考 Redmine 系列文章

2.3 組織與分析

問題分析

發現問題了，要怎麼釐清問題點到底在哪裡？是輸入造成的？還是環境造成的？還是設計有問題？還是誤動作？問題的狀況百百種，我建議從三個層面分析：

Input 之前的錯誤: Validation, Input value
Processing 時的錯誤: Runtime Error, Exception, 商務邏輯錯誤, UI/UX 設計錯誤
事後的錯誤處理: 例如應該出現錯誤，結果沒有任何結果

Validation 是上線後，導致資料庫資料混亂的來源，同時也是資安隱形殺手，所以一定要做。

組織 Test Spec / Test Case / User Story / User Scenario / Use Case

測試的文件組織是很複雜的工作，但卻又非常重要。因為經過這樣組織分析的過程，才能夠瞭解商務需求，流程等產品面的概念，特別是會有很多新名詞，或者新技術要了解後，才有辦法寫執行計畫與執行腳本。

一些名稱簡單定義如下：

Test Specification (Test Spec): 描述測試的步驟、預期條件，但是不包含前置 / 場景
Test Case: Test Spec 在什麼樣的版本 (Version) 執行，就是物件導向的 Instance, Test Spec 則是 Class
User Story: 描述特定 角色 的使用狀況, 重點在角色. 通常的寫法就是
- As a (user type) I want to (action/feature) so that (reason)
- As a (user type) I want to (action/feature) because (reason)
User Scenario: User Story 的延伸，把場景 / 環境放進去，講一個故事. 拍廣告的劇本。
Use Case: 根據 User Scenario 很清楚精準的，把步驟寫下來，基本上就是回到 Test Spec 的東西了。

Test Spec / Test Case 是在 Test Management 系統裡面會用的名稱，各大系統的名稱不一樣，有些 Test Spec 叫做 Test Plan or Test Case.

Ref: How to Tell the User’s Story

組織執行狀況與結果

測試執行完之後，主要會產生這兩個：

執行紀錄 (Execution Record, ER)：有成功、失敗、或尚未執行。失敗的需要被分析原因，像是屬於哪一些 component, 是否重複失敗 … 等.
Bug / Defect: 同樣的要分析分佈, 嚴重性比例等
- 上線前發現稱為 Defect
- 上線後發現稱為 Bug

報表組織與分析

人員 workload
測試執行時間
根據時間和週期分析
根據比例分析

異常分析

整理所有的 fail record, 分析 bug 的比例以及關係。
評估風險，如果無法滿足驗收條件，要跟 PM 討論 Release 項目。
提出改善建議

2.4 協調

QA 和 Developer、PM、DevOps / SE / IT 會有很密切的往來，甚至和 FAE / AE / HelpDesk 也會很密切，溝通就變得非常重要。瞭解商業流程，或者產品功能，然後清楚的問題描述給不同對象，讓彼此知道問題，甚至取得時間與空間的平衡。

測試工作經常需要跟 Developer / PM 討論問題，特別是會花很多時間了解、釐清需求。需求清楚了，然後根據需求的流程、定義、環境、執行場景，才有辦法判斷出，是否是 bug ，然後 bug 的嚴重性，甚至是提出建議。

2.5 測試階段與策略

測試的階段有很多，如下：

功能測試 (Functional Test): 測試基本功能邏輯的正確性，相關可以參閱輕鬆聊：系統測試 (SVT) 的三兩事
整合測試 (Integration Test): 下面這張圖是經典的例子，不難懂，但是能落實的不多。
系統測試 (System Test): 詳細參閱輕鬆聊：系統測試 (SVT) 的三兩事
回歸測試 (Regression Test): 當經過功能測試，系統整合測試之後，會產生很多 Defects，這些修正之後，有可能會導致 Side-Effect，所以最好在 Release 前還要有一次重新且完整的測試，這個階段叫做回歸測試。
- 回歸測試非常仰賴自動化，因為通常他引許的執行時間非常短，但要執行的範圍非常的大。
- 回歸測試除了要跑既有的 Test Case，另外很重要的就是要驗證曾經出現過的 Defect / Bug，確認這些 Bug 不會回娘家。
- 如果商務邏輯已經更改，那麼自動化測試的 Task 都要跟著調整，這其實是非常大的工程，特別是 Task 數量很多的時候。
安裝/部署測試 (Installation / Deployment Test)：套裝軟體的安裝，或者 Server Side 的部署。
壓力/效能測試 (Load / Performance Test)
- 容量量測 (Capacity Measure)，詳細參閱如何量測系統的容量？
- 可靠性測試 (Reliability)，相關概念參閱可靠性工程 (Reliability Engineering)
- 穩定度測試 (Stability)
使用者接受測試 (UAT, User Acceptance Test)

是否每個都要執行？要看實際上有多少資源以及時間，所以必須要有所取捨，通常至少要有 功能測試, 回歸測試. 但是實際上很多是只有功能測試，而且還沒有執行完。

完整說明參閱：淺談軟體測試的階段與策略

2.6 專案管理

依據不一樣的產品性質，定義測試的策略、方法、技術、流程、範圍、人員配置。
定義策略，配合專案時程，取得時間與資源的平衡
SQA 組織的配置與工作分類：實際上 QA 跟 Tester 是不一樣的角色，我在軟體自動化測試常見的問題有描述，簡單說有以下兩個差異：
測試執行管理與資源分配.
- 問題追蹤或專案管理都有一套系統，有名的像是 Redmine, JIRA.
- 測試管理是很複雜且專業的事情，也有測試管理系統可以使用。我用過 Testlink (Open Source, LAMP), 以及 Testrail (LAMP, 要錢，很貴，但超強).
  - Testrail 我非常推薦 (前後參與兩家公司都有買)，雖然他不便宜 (25 個人要 4500USD = 13.5 萬台幣)，但是流程、Test Spec、Execution / Test Dimension、人力資源分配、與其他系統整合 (e.g., JIRA / Redmine) 完整，是真正的 *專業的- 測試管理平台。
  - 2022/08 Updated: Testrail 後來改成訂閱制， Kiwi TCMS 是另一套 Open Source 的測試管理，可以取代 Testrail.
- 相關實際導入參閱協同合作系統建制與導入 - 以 Redmine 為例

這邊要強調，*測試- 這個工作的專業度與技術深度，不會輸給開發 (Developer)，甚至更深更廣，而他的管理工具更是需要具備專業經驗與知識才能夠駕馭，不是花了錢，品質就可以達到 100%。該有的 Domain Know How 還是要有，否則只是打腫臉充胖子而已。

國外的 QA 的條件是要做過 Developer，而且是 Senior Developer

花錢買工具以為事情就完美的老闆很多，就像花錢買很貴的吉他，然後都沒在練，彈出來一樣 2266.

結論

網路上很多文章會討論 developer 該怎麼做事, 流程怎麼改, 像這樣這篇 600 多個 bugs 要怎麼修？, 但你有沒想過:

這 600 個 bug 要怎麼發現? 找出問題復現的步驟, 是要花很多時間的.
怎麼確認這些是 bug? 根據什麼? 很多問題其實 Spec 是沒寫的, 例如基本的 Form Validation & input range.
如果裡面有一半不是 bug 會怎樣?
developer 要花多少時間解, 之後 QA 才能驗證? 花多少時間驗證? Developer 要煩惱能否解出來，但 QA 煩惱的還剩下多少時間可以解，因為 Release Date 是無法改變的。
這些問題的修復, 有沒有可能帶來新的 side effect? 效能的問題? 該怎麼避免?
你知道 side effect 的連鎖反應，有可能長出一顆樹？發現這棵樹要花多少成本？
這些 bug 的環境該怎麼準備? 自動化?
如果要針對這些 bug 每次都要做回歸測試, 要怎麼做?

很多時候, QA 跟 Developer 一樣, 手上的 Product Spec / Requirement 是不清楚且不知所云的東西，有時候有 Spec 算不錯的，經常是沒有 Spec 的.

Developer 寫 Code 是邏輯性的東西, 如果 coding 過程卻都沒反應 spec 邏輯上的問題, QA 怎麼可能知道那是問題？

很多公司裡，大部份 developer 是屬於強勢端，而 QA 通常是不被公司重視的，特別是在台灣。但就是因為如此，這些問題往往就被忽略、淹沒、漠視。

QA 常被誤解的：這功能跑只要 5 分鐘, 為什麼要測一個禮拜？
- 順利五分鐘，不順利呢？
- 找問題不用時間？
- 準備環境不用時間？
- 找原因不用時間?
- 釐清 Spec 不用時間？
- 如果測試都很順利的話，那就不需要 QA 了。
如何激怒 QA:
- 為什麼這個沒有發現？
- 這不是五分鐘就測完了？
- 為什麼這個 bug 又出現了？

以上的問題是很常見的，要花時間跟老闆教育訓練。