如何規劃一個測試計畫

關於測試計畫

這篇文章主要探討下列主題:

  • 為什麼要一個測試計畫
  • 如何開始一個測試計畫
  • 測試計畫內容包含哪些
  • 測試前、測試過程、測試後的產出

對於programmer 設計或是開發程式,產出不外乎是設計文件、程式碼、應用程式。

那麼相對應的QA 測試的產出與所帶來的價值為何?

為什麼要測試計畫?

在一開始團隊還沒有完整的品管制度時,大家或許會有些疑問,為什麼要寫測試計畫文件,

工作的忙不過來了,這樣的文件效益跟目的為何? 這時候就需要 Quality lead 對於團隊這樣的疑慮多做說明與溝通。

測試計畫可以提供下列好處:

  • 幫助團隊與管理階層了解整個測試的範圍、潛在風險、投入的時間、測試的策略、所需的資源等
  • 幫助客戶、相關協力部門了解整個專案中,測試所扮演的腳色與帶來的預期效益。
  • 對於整體的測試目標建立一定的共識,例如:品質流程、自動化測試、測試的策略、測試的目標與範圍等,

那麼怎樣展開一個測試計畫呢?

 

1. 測試的目標

首先要與客戶、專案經理、Project sponsors 等確認測試的目標。舉例來說,測試目標可能是:

  • 效能測試,網站在同時3000人使用時,效能的表現為何?
  • 資訊安全測試,網站是否有潛在已知且重大的資訊安全風險?
  • 功能測試,新功能上線前,相關的功能是否妥善?

除了,基本的功能必須運作正常之外,通常要先了解最終客戶使用該系統的使用情境,

因此,多思考下列問題:

  • 潛在的客戶與使用者為何?
  • 什麼情況下會使用這項功能?
  • 客戶與使用者多半是透過怎樣的軟硬體使用這個服務?

如何了解最終客戶的使用情境呢? 可以從上一個版本的經驗獲得、從客戶技術支援部門獲得、從類似的產品中知道、從使用者訪談或是 beta testing 中知道。

2. 測試的策略

測試的策略指的是:在達到該測試目標的前提下,在目前的資源與成本下,要用哪一種方式測試是最有效率與效果的?

這邊以三個層面來做討論,

  • 風險分析:

    風險指的是系統最有可能出錯的部分、嚴重性、出錯的機率。

    通常我們會該系統最常被使用的功能,或是以往客戶回報的問題、或是之前內部測試的一些歷史紀錄,或是程式修改比較大幅度的部分,

由於時間與資源有限,因此可以針對這些高風險的部分安排相關的測試。

  •  測試的方式

            測試的方式可以是手動測試、自動化測試、黑箱測試、白箱測試等。通常針對變異不大的基本功能,我們會進行自動化 API or unit testing.

針對畫面比較大幅度修改的功能,可以進行白箱測試與手動測試。當然,手動測試的另外一個用意是了解整個系統的容易使用度與畫面流程的流暢。

  • 決定什麼不在測試範圍

決定什麼不用測試反而是最困難的議題。通常會將測試個案進行分類 P1, P2, P3..

之後訂定測試的策略,例如每天只測試 P1 與新增修改的功能。每周測試 P1/P2。重要時程的 build 測試 P1/P2/P3.等

 3. 測試的條件

想像軟體測試是整個生產鏈的一環之一,那麼生產的工作站要達到怎樣的基本條件才進入測試的工作站才是比較洽當呢? 這就是所謂的 Entry criteria。

而符合怎樣的條件,整個測試周期就可以結束,這就是所謂的 Exit Criteria

舉例來說,我們可以定義該軟體至少要可以安裝完成,成功登入。才能夠進入測試的條件。換句話說,如果該軟體連安裝都沒有辦法安裝,那麼自然就不符合 Entry Criteria. 定義這樣的條件在於讓大家對於品質的驗收條件有一定的共識。同時也可以讓測試部門能夠更有效率的掌握品質的狀況。

4. 資源與時程的規劃

時程的規劃不外乎是專案管理的一環。這裏特別說明的是”資源”

通常一個QA 團隊會有多元化專業技能的組成。怎麼呢說?

因為系統的複雜度,專業分工下,QA測試的專業領域也變得多元,

例如:自動化測試、效能測試、資訊安全測試、資料庫測試等。

5. 測試的環境

測試的環境例如:Platform 是否支援各式的平台Windows 、Linux 、Mac..

是否支援手機,決定測試的手機版本與類型。iOS 、Android、

是否為雲端服務, 該雲端服務的availability 的需求為和?

這些都會引響如何準備相關的測試環境,自建、租用、雲端等。

6. 測試的產出

寫程式我們很清楚,產出不外乎是設計文件與程式碼。但是如果是測試部門,產出只有測試報告嗎?

一個比較專業的品管團隊,在測試過程中會產出下列文件

測試前

  • 測試計畫文件
  • 測試個案
  • 測試規格、如何測試、用什麼工具、系統功能描述

測試中

  • 測試的腳本
  • 測試資料
  • 測試所發現的問題. 這部分通常會使用 Issue Management 來做紀錄與管理
  • 測試工具、環境
  • 訓練文件

測試完成後

  • 測試結果與報告
  • 測試經驗與學習
  • “Release notes”  這個產品有哪些重大的瑕疵需要注意、或是有什麼風險需要告知內部或是外部客戶

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *