How to be an SQA?


很多事情,換個角度會有完全不一樣的見解。

我的 SQA 經歷

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

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

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

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

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

後來加入一個防火牆產品的 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,出貨前一定要走的蓋章程序。這過程學到很多自動化的經驗與想法。

以上是豐功偉業 XD

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

SQA: Software Quality Assurance, 指的是軟體品質保證。QA 這個詞我個人傾嚮他是個流程、制度,而非組織,或者角色。就像 DevOps 應該是一種流程、制度,而非組織角色。

本文

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

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

1. 專業技能

  • 獨立建置測試環境,知道環境的範圍,Component 之間的關係與介面。
  • 具備基本 script 能力: bash, sql, html, javascript, python, ruby, perl, php …
  • 系統管理 / 配置能力: linux / ssh / ngnix / tomcat / jdk
  • 網路基礎知識以及工具: tcp / udp / http / tcpdump / wireshark …
  • 自動化: 大哉問

1.1 測試環境建置與配置

這非常重要,模擬系統設定,對系統架構部署的影響。沒什麼環境是無法模擬的,除非你測的是太空船。所以環境的建置是基本,且重要的基礎能力。

環境配置的問題不能等到了維運才發現,因為線上的系統維運,不是說改就改,說停的停的,所以他是測試的一環。

環境的配置牽涉到角色的定義,或者叫做 Component 介面。每個 Component 都有自己的 In/Out,和其他 Component 溝通的方式,以及協定。清楚知道這些關係,測試過程,才有辦法釐清問題的節點是在哪裡;部屬時,才知道要怎麼調整,然後找出架構性的問題。介面還有一個很重要的就是錯誤處理,Component 彼此溝通時,如果遇到 Exception 該怎麼處理,會出現什麼狀況。類似問題,如果上正式環境才發現,都是很棘手的問題。

這段能夠自動化最好,而且測試環境的配置必須是跟線上的一致,最常被忽略的像是 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/SQE 部門,硬體廠 (網通) 則會花錢蓋實驗室 (就像義美一樣) ,而且具備一定的技術能力,需要配置自己的測試環境。這種測試環境有個很重要的目的:在理想的條件之象,量測 (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 其實是不太適合做這樣的任務。

“自動化” 會用在很多領域,像是測試、部署、控制、監控、效能等。這是很深的課題,可以參閱我另一篇抱怨文:軟體自動化測試常見的問題,或者 Test Framework for Regression Design 的分享。

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 協助注意狀況。

2.3 組織與分析

問題分析

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

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

組織 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.

組織執行狀況與結果

測試執行完之後,主要會產生這兩個:

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

報表組織與分析

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

異常分析

整理所有的 fail record, 分析 bug 的比例以及關係。

2.4 協調

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

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

2.5 測試階段與策略

測試的階段有很多,如下:

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

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

完整說明參閱:Stages in Software Testing

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) 完整,是真正的 專業的 測試管理平台。
  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 又出現了?

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

延伸閱讀 (站內)

參考資料 (站外)


Comments