2013年3月29日

軟體測試這回事

做了幾年的軟體測試, 覺得這行飯其實還滿微妙的.

有些人叫測試工程師, 或者 QA (Quality Assurance 品管?) QC (Quality Control), SQA, Tester, blabla.... 這個 domain 對台灣人比較陌生, 最酷的是你在學校很難學到.
一般測試可能會遭遇到以下工作:

  • Manual Test, 使用開發完的產品. 包括照表操課的 (有準備 test plan), 或者隨便亂試的. 這類的工作價值有一部分是使用產品本身就是模擬使用者 (客戶) 去操作產品, 相對於其他測試會更能貼近用戶會遇到的問題. 由於正職的測試人員對產品會有一定的熟悉 (也應該熟悉啦), 這件事會讓測試用戶體驗上有負面的影響, 所以也常有公司單獨作這一塊的測試, 有點像是市場調查.
  • Test Planning (Design?) , 泛指 test case creation, test plan creation, ... 跟產品相關的. 這邊的工作常與上面的工作重疊.  也有些公司把這邊的工作特化出來. 或者產品根本就是有白紙黑字的規格, 這邊的工作負荷相對少. 軟體測試因為產品改變的速度極快 (一天變好幾版也有可能), 規格改變導致測試項目與預期結果也急遽改變, 擔任這個角色的工作內容比較吃重.
  • Test Reporting, 根據測試結果產生測試報告. 這邊提到的測試報告是一個彙整, 根據所有測試報告產生列表或者圖像的結果, 以提供決策人員客觀的品質評估. 有些公司是 Developer 作這件事; 也有些地方是 Lead, Manager 在做的.
  • Test Automation, 測試自動化. 有鑑於人作的永遠不會比程式快, 很多公司在考慮流程優化的時候會想到這件事. 如果讓我來說, 最好的自動測試也許就是作一個產品專門使用你的產品, 但實務上相當不切實際.  試著考慮一個產品, 可能的架構是, 他使用了許多 Library, 如下圖的 OS/Driver/Platform 這塊. 程式本身提供了一些 Interface 來完成流程, 或者與使用者互動.  然後跟使用者互動時的圖形界面. 理論上 presentation 這一層之所以要切開就是為了讓 UI 可以頻繁的更動. 以寫一份自動測試的成本/ 效益而言, 過多對於呈現面的自動化無疑自討苦吃. 市面上有許多產品試著解決這樣的問題, 像是 selenium. 相較之下, 在 API 層作自動化, 可以保證作低限度的正確性. 而相較之下不易改變的 API 行為, 也會保證測試本身有較高的性價比. 
  • Write Test Tool, 輔助測試用工具. 這跟測試自動化有相關但我把他切成兩個部份, 因為目標不完全一致. 通常是幫助測試者完成冗長而不易完成的準備工作, 或者是使用一般狀況下無法碰觸到的情境 (高記憶體用量等等). 有些公司會有專屬的人作這些開發, 包括測試自動化; 但如果 QA 能負擔這些工作, 便能減少許多溝通造成的成本.
  • Test Process, 測試流程規劃, 一般來說是 Manager 以上的角色在做的工作, 如果你作的夠久也可能碰的到. 內容像是, 定義開發流程之中的測試工作.


測試所帶來的價值
  • 提供使用者經驗
  • 風險管理
  • 幫助釐清問題
前面兩個項目前面提過了, 我想談一下幫助釐清問題這件事. 作為一個測試人員, 除了發現問題以外, 很多的時間會花在重現問題, 而這是釐清問題的一個重要關鍵. 測試工程師不能只是對問題束手無策. 常用的作法是在 test case 中列舉, 經由交叉比對縮小問題點. 發現 root cause 這個工作如果在測試這邊就有足夠的資訊, 當問題交到開發工程師手上便會減少處理時花費的時間.
自動化在這個地方就扮演一個極其重要的角色.  如果 test case 設計時考慮到平行處理與容易程式化, 便能大幅縮短執行一個完整測試所需時間. 而兩個完整測試的間隔時間若縮短, 就可以縮小回歸 (regression) 問題所需翻查的 code/commit 數. 當發現問題與研究 root cause 的時間縮短, 可以想見的是品質將隨之提昇, 並且需要的開發時間也縮短了, 兩全其美?

測試是很重要的工作, 最重要的是不要把他作小了.

沒有留言: