在軟體發佈之前, 你需要對軟體的不同功能, 進行徹底的測試, 而第一件事情就是先規劃如何進行測試. 你需要考量策略、目標、截止日期、範圍、資源, 以及對其測試工作的估計, 最終將這些東西給記錄下來.

測試計劃是高度動態的, 內容隨著專案的進展而變化. 根據測試結果和不斷變化的需求, 測試經理會定期更新測試計劃. 在這個計畫中, 我們主要要說明三類事情

1. 目的是什麼
   為什麼要做這個測試, 是為了交付高品質的產品, 還是為了某個商業目的, 如果是後者不見得就是要追求都沒有 bug, 有可能沒有某種類型的 bug. 例如: 像是 1.0 的產品, 我們只要確保主功能沒問題就好, 因為商業目標是要確定有人要, 如果沒人要, 品質都沒問題也沒用.

2. 能做什麼
   因為不是所有東西都能找到, 也不是時間或資源都沒限制, 因此要先確認那些類型是我們能做到的. 所以這裡也隱含一件事情, 那就是需要討論哪些是我們不做, 或者是做不到的, 在測試之前先說好, 避免有錯誤的期待, 以及浪費資源去測試不需要測試的部分.

3. 限制是什麼
   有時候為了要測試這部分, 我們可能需要買很多測試系統, 或是準備海量的資訊, 這些東西在某些場景是天價, 或者是做不到. 像是有些雲端的環境, 最多是 production 買一套, 但是你要有多個 stage 就很難. 或者像是支援的手機, 如果是要支援 Android, 那可能需要上百隻, 如果每個測試人員或是每個專案都要, 公司也很難負擔得起.

在測試計畫中, 會包含哪些資訊呢? 如下圖 16-1 所示, 主要包含: 測試策略, 可追蹤性, 時程規劃, 資源, 測試執行, 變動管理, 和通過準則等等. 就讓我一一來介紹:

圖 16-1 測試計畫包含的內容

(1). 測試策略
我想大家可能聽過戰略和戰術這兩個名詞：

• 戰略: 是指為實現某種目標而制定的高層次、全方位的長期行動計劃
• 戰術: 讓您實際抵達終點的個別步驟和行動

在測試計畫中, 其中一個重要的資訊, 就是要描述測試策略. 要定義出為了要實現某種目標, 這個組織在高層次下會怎樣來進行測試. 他不該只是一份冰冷冷的流程文件, 而是告訴你要如何思考和選擇, 好讓你可以滿足商業和測試的目標. 測試策略會在專案需求的階段去訂定出來.

如下圖所示, 測試策略會從以下面向來說明要如何進行.

圖 16-2 測試策略主要要考量的面向

A. 測試目標
這裡不外乎考量幾個面向的需求 a. 老闆, b. 客戶, c. 品質. 等等. 從這些人的需求, 了解你要達到的目標是什麼. 例如

• 在 6/30 時要能去 demo, 但是 8/31 要能上線
• 在 6/30 時要能有 beta 的品質
o P1/P2 bug 要被修復
• 在 6/30 時要上線
o P1/P2/P3 bug 要被修復
o 90 % line coverage

這些是因為不同需求, 所以你要達到的程度也就不同

B. 測試方式 (Test Approach)
這裡會從不同角度說明大致會怎麼做

• 進行階段/活動
要進行哪些階段的測試, 像是單元測試, 整合測試, 系統測試等等

• 測試方法
使用黑箱, 白箱或是灰箱等等

• 自動化
哪些部分要進行測試自動化, UI, API, 端到端?

不同模組有可能會有不同的測試方式. 例如新的功能模組和 legacy system. 前者可能會做單元測試或 API 測試. 但是後者可能只進行功能測試等等.

C. 測試環境
這裡是在說明要在哪些環境上進行測試. 這不一定包含所有受測軟體所支援的環境, 而是說明這次測試想要涵蓋的範圍. 例如:

• 瀏覽器:
支援 IE 最後兩版, FireFox, Safari
• 作業系統:
Win 10, 11, 365

此外, 還會提到哪些環境是我們沒有, 但是需要去租借的. 例如有些網路設備或是珍貴的測試工具等等.

D. 測試度量
為了要了解目前測試狀態, 需要有些指標來呈現現狀. 你需要定義好要收集什麼資訊, 多久收集一次, 以及如何收集等等.

這些事情都是有成本的, 所以在使用之前, 要先好好討論一下, 你的目的是什麼, 收集之後要拿來怎麼用, 會產生什麼可能的行動.

哪可能會有什麼度量指標, 這邊有些範例

• 測試個案數/每千行程式
想要了解開的測試個案是否足夠, 可以和前幾次或前幾個本版做比較, 看看是否維持一定水準. 如果可能的話, 可以看到子系統或模組層次, 更可以知道哪邊是否不足.

• 抓到的 bug 數/每千行程式
想知道抓的 bug 是否夠多. 以及測試個案是否開立的有效. 因為前一個指標可能會造成為了湊數字, 大家隨意加開測試個案. 加上這個指標, 就可以知道你開的測試個案品質如何, 是否真的有效.

由上面的範例可知, 不是只要有指標就好, 單一指標不容易考慮周全, 藉由多個指標相互幫忙, 會讓你看到團隊真實的健康狀態.

E. 測試風險
進行開發不會沒有風險, 因此一開始就需要整理出目前可以想到的風險有哪些. 接著就是列出目前想到的緩解方案是什麼. 隨著專案的進行, 會更新風險處理的狀態. 如下表所示, 你可以有類似的表格來記錄:

F. 測試工具
需要整理出所需工具為何, 自動化測試是否需要額外的機器和工具. 以及這些工具放在哪裡, 是否有相關的文件等等.

常見的種類如下:

• 測試管理工具,
• Bug 管理工具
• 測試自動化工具
• 效能測試工具
• 測試機器
• 產生測試資料的工具

基本上好的測試策略應該要注意以下事情

• 關注風險
不可能沒風險, 也不可能不發生, 但是要想些作法, 讓風險降低

• 多樣性
你無法用一招找到所有問題, 你需要有很多關卡,這關躲掉, 下一關希望能掃到. 如果 bug 可以躲過這麼多關沒有被找到, 也只能摸摸鼻子認了.

另外, 你需要針對不同場景, 有不同的作法. 像是時間充裕可以怎麼做, 如果只有 2 小時, 哪你又可以怎麼辦.

• 實用
策略這東西最終還是要能做得到, 做得完. 不應該是寫得很漂亮, 可是卻無法照著玩.

以下這個範例, 就是在不同階段, 會有不同的進行方式

(2) 可追蹤性
在規劃測試計畫時, 有件重要的事情, 就是確認要測試的功能, 是否我們都考慮進去了, 都有建立相對應的測試. 所以我們會建立需求和其他測試活動或文件的關聯. 如下圖 16-3 所示.

圖 16-3 需求和測試的對應關係

當你有這樣的對應關係, 以可以知道是否每個需求項目都有相對應的測試. 並且對應的測試個案或是測試活動是什麼. 此外, 當需求有變動時, 可知道哪些測試個案受到影響.

(3) 時程規劃
我們會需要一個比較詳細測試的活動及時間表. 在專案初期時, 這裡可能只是比較高層次的規劃, 隨著時間的演進, 會越來越詳盡.

測試活動會包含: 環境準備, 個案設計, 自動化開發和維護, 個案執行, 驗證 bug, 文件撰寫, 和教育訓練.

圖 16-4 測試活動的時程表

圖片來源:
https://www.researchgate.net/figure/An-example-system-test-schedule_fig2_228679262

(4) 資源
在執行測試的過程中, 人力的安排很重要, 它不單是要有人, 還要有對的人, 有能力的人. 所以要知道哪些人是可以參與測試的. 他們有些人可能無法一開始就參與, 如果可以盡量爭取他們早期就加入, 或者是至少需求或設計討論時, 可以邀請他們參加.

接著你需要知道測試此專案, 需要哪些相關的技能, 如果參與的人沒有足夠的能力, 需要安排技能訓練, 想辦法讓他有些基本知識.

然後你也要安排好, 如何分配工作這些測試人員, 是某些就固定測否些項目, 還是都可以指派. 是單人自己測試, 還是 pair testing.

(5) 測試執行
在執行測試時, 會需要以下資訊:

• 決定測試個案順序
當測試個案太多, 無法全部執行, 在建立測試個案, 就需要設定測試個案的優先順序. 你可能根據重要性和複雜度來決定

• 個案之間的關聯/分類
哪些測試個案會一起執行, 在什麼著況下執行. 例如: ready for test 的測試個案, 會放在 smoke test. 主功能類的測試個案可能是第一循環會去測試. 例外處理的測試個案可能是第二循環去測.

• 總共有執行多少循環
每個循環的目的為何
每個循環大約花多時間
要執行哪些測試個案

(6) 變動管理
在測試過程中, 很多東西都會變動, 若沒有流程來控制, 後面就會變成不可控.

• 受測軟體版本控制方式
如何選出哪個版本可以讓測試人員測試.
當開發人員修復後, 經過怎樣快速驗證, 才可以讓所有人都換版本. 或者是累積多久才需要換?

• 自動化程式的控制方式
自動化測試程式需要版控嗎? 需要從版控系統建構新的測試程式嗎?

• 測試個案的版本控制
如何區分哪些測試個案在這個版本有用, 哪些在之前版本有用. 需要把測試個案進版控管理嗎?

• 測試環境的版本控制
每個測試人員和開發人員他們所用的測試環境一樣嗎? 會有在這台會發生問題, 在另一台不會發生問題的狀況嗎? 怎樣產生測試環境才不會出現這樣的問題？如何可以很快速產生這些測試環境呢?

(7) 通過準則
當測試告一段落時, 需要瞭解什麼叫做完成, 怎樣才算通過, 最後要交付哪些東西. 這裡我們會需要以下資訊:

• 測試完成的準則 (測試人員)
需要執行哪些活動
需要交付哪些文件

• 測試通過的準則 (針對受測軟體)
每個階段的通過準則
Bug 處理的準則