前面聊完測試管理的定義後, 對於它在做些什麼, 應該有些初步的認識. 有些人會認為應該可以用專案管理的方法來處理, 這算對也不對. 為什麼?

傳統專案要做什麼, 一開始會定義好, 然後規劃接下要做什麼來完成. 中間即使有隕石進來, 還是可以根據優先順序, 調整計畫來面對. 不見得那麼未知.

但是在測試裡, 有很多特色, 讓你很難事先規劃管理, 例如: 沒有文件, 常常要通靈測試. 原先規劃要測 3 天, 但沒想到受測系統品質爛到不行, 到處暴雷, 造成很多東西都要重測, 並且不知道還要測多久. 所以相比一般專案管理, 能見度很差, 未知性太高, 能控度很低, 你需更多心力才能顧好.

為了讓你知道大概會有哪雷, 就讓我一一道來, 希望未來在做測試管理時, 能幫助你先考慮到這些狀況.

1. 如何讓測試進度可見
   測試的工作和開發相似, 很多動作從外界看不到他們在幹嘛. 以開發來說, 你坐在電腦面前就是認真工作嗎? 你上網就是在查程式相關資料嗎? 測試也是如此.

• 測試個案跑完
這個狀況最嚴重. 測試人員每次在執行測試個案時, 時間到了跟你說跑完了, 你是很難知道他有沒有執行.
另外, 他跟你說沒跑完, 需要更多時間, 這時候你也很難知道他是不是騙你, 他是否有很認真在跑.

• 安裝系統
同樣地, 安裝系統也是. 因為機器的軟硬體環境不同, 有可能需要不同長度的時間, 所以這裡也很難可以衡量這個時間是否合理.

• 抓到 bug 不等於抓到大多數 bug
抓不到 bug 是很嚴重的事情, 所以測試人員通常不會都沒有抓到, 總是會抓到幾個. 但是這不代表他是否把所有或大多數的 bug都抓到.

圖 15-1 測試工作執行的能見度不高

2. 測試時程不切實際
   在專案開發過程, 測試時程會怎樣被定出來呢? 大概有幾種可能:

• 回推時間
基本上就是根據專案死線時間, 扣除掉開發系統所需時間, 剩下才留給測試. 所以在這剩下的一丁點時間, 你要想辦法可以達成老闆要的目標. 雖然聽起來不可能, 但這就是你的事了.

• 固定長度
有些團隊的作法, 他們可能就是固定給你一段時間, 三天, 一週或是兩週, 雖然不多, 但是至少是一個基本盤的固定長度. 你還可以有些操作空間.

• 沒有資訊
開發什麼時候可以完成不知道, 可以測多久不太清楚, 客戶常常隨時來要一個版本, 一切資訊都是不明的, 測試人員只能伺機而動, 有多時間就盡量把重要問題找出來.

圖 15-2 推出測試時程的常見手法

3. 管理複雜的測試環境
   有些受測系統所需要支援的伺服器平台, 瀏覽器, 資料庫, 用戶端平台 種類非常多, 這些東西乘起來的組合, 或許不是天文數字, 但是只要來個上百種, 大概就崩潰了.

一方面你沒有測試自動化, 如果要寫測試程式的時間不是你想像的久, 並且你也沒有這樣的人力. 另一方面, 不是寫測試程式而已, 你還要要求開發人員配合修改受測程式, 讓測試程式可以呼叫他們的 API, 這又是一件挑戰的事.

可是你又不能不測, 不測就說你支援這些平台組合, 這種騙用戶的事情, 總有一天會出包, 那時候不只是賠錢, 商譽的損失可能不是你能想像的.

4. 處理大量的測試資料
   在測試時通常不是有測就好, 這就是大部分開發和管理者所擔心的. 他們往往只測正常資料, 偶而不小心加些異常資料, 所以他們常常煩惱涵蓋度不夠, 他們都知道那些測試只是在交代, 說他們有做, 但是是否是做好, 做對, 他們就不敢說了.

測試之所以會做不好, 有一大部分跟測試資料有關, 除了前面提到的正常資料和異常資料外, 你還需要混合型的資料, 包含正確和不正確, 以某種比例混搭. 另外, 除了你假造的資料, 還需要拿一些真實世界中出現的資料. 並且這些資料不能只是少量, 還需要有些巨量資料, 來驗證某些場景是否仍可以運作正常.

圖 15-3 需要的測試資料種類

5. 需求模糊且常常變動
   需求這件事情, 不管開發或測試都很頭痛, 因為他常常不清楚, 並且也常常變動.

但是測試人員和開發人員不同之處, 當這些不清楚時, 為了要把程式寫出來, 開發人員會去定義他自己的需求, 這是測試人員無法做到的.

另外, 不管是客戶定義的, 或者是開發人員定義的, 很多時候都不會有文件, 測試人員往往需要通靈去測. 這時候老闆還要求說要去估一個時程出來, 你說可以怎麼辦?

6. 團隊缺乏測試相關知識和能力
   在學校裡, 會教軟體工程課程的老師不多, 更不用說軟體測試了. 因此, 大多數的團隊成員是不會軟體測試了. 所以只能在工作中學習.

如果是做測試的工作, 他沒有選擇, 可能會摸摸鼻子去學, 雖然大多也沒去好好學. 但是如果他原先是開發人員的話, 他可能會說:

• 我是來寫程式的
這是最常聽到的說(藉)法(口), 開發人員覺得這不是他們的工作, 品質的事情不歸他們管, 當初找人的時候沒說要做這些.

• 我沒興趣
因為個人職涯規劃的關係, 我對開發比較有興趣, 測試的事情真的不行, 我不擅長去找麻煩.

• 這不入流
開發比較有技術性的, 這種不寫程式的工作, 很 low, 很沒有成就感. 我不是很想做這些.

圖 15-4 開發不想學測試的原因

7. 週五發佈
   總是會因為某種慘事, 會讓你有機會週五下午要發佈. 這時候就看平時有沒有積陰德. 因為如果你平時基本功有做, 這時候會慘狀的機率就可以降低. 為什麼這樣說呢? 你總不能說當星期五下午發生重大車禍時, 醫院說這時候最好不要來. 或者是之前飲料點事件, 下班前去點飲料, 你就會想要加料.

你應該是思考以下事情是否做好

• 是否頻繁 check-in 和測試
如果你平時都每小時就 check-in code, 並且進行 CI/CD 測試, 並且有錯可以在 30 分鐘內修復. 自然風險就可以降低

• 是否有常運行的恢復機制
不可能測到所有狀況, 這件事情是大家公認的. 所以要先考慮好你有哪些回覆機制, 以及你是否平時就有演練這些機制, 確保他還是有用的.

• 是否很多環節是手動
有時候雖然有測試, 也有恢復機制, 但是很多地方都是手動的. 在平時可能還好, 在警急的狀態, 那就會抖得不得了.

8. 確保受測軟體的品質沒問題
   老闆或者開發人員常常會覺得bug 沒有抓到, 這是測試人員的問題, 測試人員不專業. 測試人員需要找到所有 bug.

在這種狀況下, 測試人員就會變得保守, 他就可能會要求

• 需求範圍要確定
• 文件要先準備好
• Code Complete 後不能再加功能
• 不接受最後一刻的修改

你覺得這樣的態度, 你可以接受嗎?

9. 缺少自動化
   我們都知道測試能自動化的話, 可以省下不少時間, 並且可以重複執行很多次, 每次都不需要人介入. 聽起來一起都那麼美好.

但是實際上, 測試自動化老是排不上優先順序, 因為它真的很花時間, 在專案時程和自動化兩這之間, 往往選擇的是 Schedule, 不是只有專案經理會這麼選, 開發人員也是, 所以自動化這條路往往是不通的, 你很難利用自動化來幫助測試工作.

10. 開發和測試不和睦
    開發人員常常和測試人員站在對立面. 前者是要求快, 趕快把東西做出來, 有些事情不用想得太多. 後者是要求穩, 要有品質, 客戶不會接受這些東西. 因此兩者常常會不合, 彼此之間沒有共同的目標.

當不合之後, 兩者在互動就會就會出現神奇的地方. RD 不解釋怎麼做, 也不說明怎麼修復 bug 的. 光是這兩點上不給資訊, 或者是給的資訊不足或不完全正確, 測試人員就會繞很多遠路. 本來就測不完, 這樣只會讓災情更加慘重.

11. 最後一刻的修改
    最後一刻的修改, 這件事情不好避免, 有時候就是真的找到嚴重 bug, 有時候就是真的被硬塞. 這時候要如何測試就很考驗功力.

• 影響範圍
如何決定哪些地方受到這次修改的影響, 這是回歸測試需要考量的

• 時間有限要做什麼測試
這時候時間通常很短, 有什麼測試活動是這麼短時間內可以做的, 並且可以有效減低風險. (因為全部都跑已經是不可能的事, 就算都有自動化時間也可能不夠)

• 風險規避
如果因為這樣出包了, 那我們可以做什麼減輕災難, 如何快速復原.

12. 無法估算測試要做多久
    很多時候老闆總是會要求給個測完的時間. 對於測試人員來說, 這個時間真的很難給. 為什麼呢？ 讓我們來一下這個狀況

1 個測試個案, 要執行 5 分鐘
1 個 bug, 修復和重測要 10 分鐘

第一回合測試
我們有 100 個測試個案, 要執行 5 x 100 = 500 分鐘
找到 20 個 bug, 還需要 20 x 10 = 200 分鐘

這時候就結束了嗎? 當然不是, 我們還需要進行回歸測試, 因此我們就有第二回合

第二回合測試
回歸測試 還需要 5 x 100 = 500 分鐘
找到 10 個 bug, 還需要 10 x 10 = 200 分鐘

這時候就結束了嗎? 通常不敢, 我們還需要進行回歸測試, 因此我們就有第三回合

第三回合測試
回歸測試 還需要 5 x 100 = 500 分鐘
找到 5 個 bug, 還需要 5 x 10 = 50 分鐘

所以看到這裡, 就如我前面所說的, 測試要測多久, 不是測試人員可以決定的, 要看開發人員寫的代碼品質如何, 如果是一堆爛貨, 就需要很長的時間. 要多長呢?要看受測程式有多爛.