軟體測試過程常常有很多狀況出現, 對於沒有經驗的管理者或是開發人員, 他們不太清楚這些事情要如何處理, 因此, 這邊跟大家分享一些經驗, 讓大家在進行規劃時, 能夠少踩一些雷.

1. 了解你的使命 - Know Your Mission (KYM)

在進行規劃時, 因為大多數人是工程背景出身, 會從技術角度出發, 思考測試工作該如何進行, 哪些東西要考慮進來才能顧到所有品質. 並且也做得非常辛苦, 因為要測得東西真的很多. 但是, 最後結果並沒有讓客戶或是長官滿意. 為什麼會這樣呢?

我們大多時候, 在意的是從自己角度的需求, 並不是客戶或是長官的需求. 對於長官來說, 他要的專案能夠準時發佈; 從公司的思維來說, 他要的產品能夠賣錢; 從客戶的角度來說, 他要的他有用的功能, 都沒有大問題. 所以沒有一項是要產品品質完美無缺.

所以在規劃階段, 不是優先考量產品品質要完美無缺, 而是其他利害關係人要什麼. 先去了解他們的期待, 規劃出能夠在這個時間內, 達到他們期待的可行作法. 這個才是你的使命.

2. 持續規劃

圖 17-1 美國總統 艾森豪

美國總統 艾森豪 說到: Plan is nothing. Planning is everything. 有計劃當然很重要, 但是更重要的是要持續規劃.

我們不是在專案一開始的時候, 才需要撰寫測試計畫書. 因為測試狀況多變, 你需要不斷調整測試計畫. 所以比較好的方式, 是類似敏捷開發的作法,

或許你一開始有的高層次的計畫, 但是每隔兩週, 你會有個迭代計畫, 去規劃未來兩次, 測試的工作要如何.

在這兩週要做的事情應該會比較確認, 所以規劃起來比較容易和準確. 就算中間遇到大變化, 浪費的也是這兩週事情, 而不是整個計畫都有問題.

這樣迭代式的規劃, 可以讓你在規劃上, 保持最高的彈性.

3. 測試左移 + 多層次持續測試

測試左移(test left)是這幾年出現的名詞. 以前軟體開發, 是屬於循序開發的流程, 需求分析, 設計, 開發, 測試和維護會循序進行. 因此, 如果你的測試活動, 是發生在傳統測試階段之前的, 我們就稱為測試左移. 如果是在傳統測試階段之後發生的, 就是測試右移(test right).

測試左移的想法, 就是希望當問題發生時, 早期就抓到, 一方面成本比較低, 另一方面也比較容易解決, 哪些活動是屬於測試左移的測試呢? 需求檢視, 架構設計檢視, code review, 或者是靜態測試等等. 所以在規劃過程需要多排入這些活動.

另外, 你也很難只靠某個人, 就可以解決所有問題. 因此, 我們可以讓測試活動小而多, 多幾關檢查, 並且是不同人檢查. 這樣可以讓多雙眼睛幫忙一起看, 並且是大家一起負擔, 多種想法考慮會比較周全.

這裡就有一個多層次, 持續進行測試的方式：

4. 測試人員的參與方式

測試人員是非常珍貴的資源, 因為在很多公司不是沒有, 要不然就是很多團隊一起共用. 因此不容易讓他們緊密合作. 這裡有幾種方式可以參考：

• 全程參與最佳
如果可以全程參與, 這樣幫助最大, 可惜不容易有這樣的狀況

• 至少參與需求討論
如果後期才能進來測試, 我會建議期前期時, 至少可以參與需求討論. 這樣可以有些好處：

a. 熟悉需求: 因為之後才進來, 在時間短又不是很懂系統在做什麼的情況下, 任誰都無法測試的很好. 如果前面有參與需求討論, 或者至少在旁邊聽聽, 都會很有幫助

b. 及早提出問題: 在考慮需求時, 開發人員是從技術觀點看看可行性. 測試人員會考慮一下其他狀況系統會做什麼, 或是從用戶角度提出怎麼用的問題. 幫助開發人員及早就把這些考慮進去.

• 搭擋測試 (Pair Testing)
如果前期沒有進來, 可以藉由 Pair Testing 的方式, 讓開發人員和測試人員一起測試. 一方面測試人員可以學習系統知識, 一方面也讓測試場景可以產生更多火花. 這樣進行測試會比較有效果.

• 指導開立測試個案
如果測試人員真的無法進來一起測試, 另一種方式就是請測試人員指導開發人員進行測試. 那其中最有效果的方式, 就是指導開發人員開立測試個案. 因為開發人員要寫測試程式不是問題, 他不擅長的是如何考慮多種測試場景, 而這部分正是測試人員所擅長的. 因此, 當開發人員開完測試個案後, 就可以和測試人員一起檢視, 補足考慮不周的部分.

圖 17-2 測試人員可以參與方式

5. 多少測試才足夠

很多人會問測試要測多少才足夠, 這是一個很難的問題. 並且沒有 通用公式.

這裡有個角度的想法提供大家參考, 個人覺得測試是一個資訊收集的過程, 那收集資訊要做什麼呢? 要讓管理者有足夠訊息做出好的決策, 也就是提出產品品質方面的資訊, 如果管理者覺得品質夠了, 就可以停下來. 通常我們會看以下面向的資訊:

• 風險：專注於軟體的關鍵或高風險領域, 這些領域一旦失敗可能會產生重大影響.

• 品質目標：測試應足以滿足品質目標, 像是效能、安全性、可用性和可靠性要求.

• 預算和時間限制：根據可用資源決定測試工作的優先順序, 在預算和時間用完之前, 把重要的部分給測好.

• 使用者期望：測試應確保軟體滿足使用者期望並提供良好的使用者體驗。

• 法規遵循：如果軟體需要遵守特定法規或標準，請確保測試可以滿足這些要求。

6. 兩輪測試是最基本的

很多狀況測試一輪是不夠的, 必須要多輪會比較合適. 但是在時間和人力考量下, 很多時候做不到這一點.

所以理想的基本作法, 可以是這樣的

• 第一輪: 找出大多數的問題
• 第二輪: 確認問題已被修復, 再進行回歸測試

但是這中間若是遇到超多 bug, 可能兩輪就不管用了.

• Show stopper:
所謂 Show stopper 就是這個狀況出現後, 後面就無法繼續下去, 導致一切停擺. 測試的時候最怕遇到這種 show stopper, 當主功能不能動, 後續測試就無法進行下去了.

• 修復問題又帶來新問題:
改 A 錯 B 的狀況, 在軟體開發過程屢見不鮮. 如果是在測試後期, 才發現修復的 bug 又帶來新的問題, 在時間不足的狀況下, 便對測試產生很大的挑戰.

7. 即時回報問題

很多時候, 找到 bug 並沒有及時通知相關利害關係人, 導致大家誤判, 以為現在情況一切很好. 所以個人建議會試試以下方式

• 立即告知開發人員
立即跟開發人員說的目的, 是在第一時間讓他看到現場, 給他除錯的機會和資訊, 之後看到 bug 報告時, 就可以很快知道你在寫什麼, 這個東西要如何解.

• 立刻告知主管
對於重要或是風險高的 bug, 最好同時也告知主管, 讓他知道其實受測產品是有狀況, 如果需要多點時間去修的話, 讓他心裡也有譜, 後續要做什麼去調整, 就可以早點去做.

• 立刻填寫 bug 報告
當通知完開發人員和主管後, 接著就要紀錄 bug 報告. 因為口頭講講的資訊, 一方面容易忘記, 另一方面真的要解 bug, 是需要更詳細的資訊.

圖 17-3 立即回報的方式

8. 輪調測試人員負責的項目

在安排測試工作時, 我們基於以下因素來輪調測試人員的工作:

• 有趣
每次測相同的東西很無聊, 如果可以換點不一樣的項目去測, 會讓測試工作更有趣.

• 備援
如果這個人離職很危險, 或這個受測項目很重要, 會建議安排多個人測試相同項目, 這樣比較能降低風險

• 不同知識視角
懂較多功能比較找得到問題, 這樣比較容易知道整體是在做什麼, 是否相互之間有衝突的地方.

• 不同想法
不同的人會用不同想法來測試, 如果都是同一個人, 大致出的招都差不多.

9. 測試工作的評估

估計測試工作量對於有效的專案規劃, 資源分配和調度至關重要, 有助於防止專案延遲和超出預算. 以下有幾個方法

圖 17-4 評估的方法

• 工作分解結構 (WBS)
一個複雜的專案被分成多個模組, 這些模組分為子模組, 每個子模組進一步分為功能... 當問題被切小後, 估算就會比較準切.

• 3 點評估法 (3 Points Estimation)
根據先前的經驗或最佳猜測，最初為每個任務產生三個值:
最佳時間 (a), 最可能的時間 (m), 最差時間 ©
3 點評估法的時間 = (a + 4m + b)/ 6

• 敏捷評估法
利用 playing poker 或是 T-shirt size 的方式, 團隊集體討論協調來得到評估的答案. 一方面避免只有單一面向的思考, 另一方面可以學習到你不知道的資訊.