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,出貨前一定要走的蓋章程序。這過程學到很多自動化的經驗與想法。

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


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

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

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


本文

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

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

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 往往都是屬於附屬單位,大多僅止於 *能動- 就出貨的程度。很多公司都是為了省錢,所以往往忽略這段,然後問題都是上線 / 出貨的之後才發現。上線 / 出貨之後的成本遠比測試環境的成本高很多。

相關文章:

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 其實是不太適合做這樣的任務。

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


2. 軟實力

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

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

2.1 溝通表達能力

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

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

其實不只是 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)
  • 使用者接受測試 (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 為例
  1. 這邊要強調,*測試- 這個工作的專業度與技術深度,不會輸給開發 (Developer),甚至更深更廣,而他的管理工具更是需要具備專業經驗與知識才能夠駕馭,不是花了錢,品質就可以達到 100%。該有的 Domain Know How 還是要有,否則只是打腫臉充胖子而已。
  2. 國外的 QA 的條件是要做過 Developer,而且是 Senior Developer
  3. 花錢買工具以為事情就完美的老闆很多,就像花錢買很貴的吉他,然後都沒在練,彈出來一樣 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 又出現了?

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


延伸閱讀

站內延伸

參考資料 (站外)

更新紀錄

  • 2022/08/22: 調整測試階段用詞


Comments

2015/10/11 11:08:00





  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲