身為測試人員, 我們知道如何有效率地開立, 設計和執行測試個案. 但是 …

如何知道我們 何時可以停止?
如何知道我們 做了夠多的測試?

另外, 管理者也會問雷同的問題:

現在測試夠了嗎?
現在產品品質已經可以出貨了嗎?

那這個問題可以怎麼回答呢?

我們來看看大神的說法:

“當我們度量後發現, 大多數的問題已經被修正, 並且有信心我們已經可以準備執行驗收測試了, 這樣測試就可以結束”

– Bill Hetzel
The Complete Guide to Software Testing

不幸地, “大多數的問題已經被修正”, 以及“有信心”這些事情是相當含糊的

另外, Trump 有說過一句話也很有趣

If we stop testing right now, we'd have very few cases' of the coronavirus
如果我們現在停止測試，我們的冠狀病毒病例就會很少”

這跟軟體測試很像, 只要不要叫測試人員測試, 就不會有 bug. 所以在問我們什麼可以停止測試時要小心, 測試人員隨時可以停止測試, 只要你嫌棄目前品質不好, 專案進度來不來的話.

以下是一些參考的標準, 從這些面向幫助你思考是否可以停止.

1. 涵蓋度目標被滿足

對於能不能停止測試, 很多人都希望可以給個明確答案. 所謂明確的答案, 就是要有明確的數字, 當這個數字出來後, 一拍兩瞪眼, 繼續和不繼續是很明確的.

為了能有明確的數字, 很多人出的招就是涵蓋度. 所謂涵蓋度的定義, 就是:已經被處理過的項目/所有要被處理的項目. 例如:

• 已經被執行的測試/ 所有要執行的測試
• 已經被執行過的路徑/ 所有可被執行的路徑
• 已經被執行過的功能/所有可被執行的功能

這裏所謂的“項目”, 大概有這兩類:

• 程式碼的角度
Statement coverage
Branch coverage
Condition coverage
Path coverage

• 系統的角度
Functions tested
Use cases tested
Use case scenarios (main path and exception paths) tested
Scenario for Performance (非功能性測試)

讓我們來看個範例：

90% statement coverage 或是
70% branch coverage 或是
90% use case scenario coverage 或是
100% function coverage (這次寫的) + 95% use case scenario coverage

如果可以達到這些條件, 我們就可以測試可以結束了.

這些條件通常是一開始, 在規劃測試計畫時, 相關的利害關係人就要一起討論. 事前把這些講好, 讓團隊有個目標可以衝刺, 避免在專案結束階段, 大家才來吵來吵去的.

2. 錯誤發現率

當你在進行測試時, 可能會有下圖這樣的統計, 不管是自己弄的, 或是測試管理工具給你的. 這個圖表可以告訴你很多資訊, 其中一個資訊, 就是上面數據的斜率. 當斜率減緩, 或是減緩到某一定的值, 你就你停止.

另一個可以參考的, 當連續幾週, 所找到的 bug 數目低於某個數值, 也是可以考慮停止.

圖 26-1 bug 在每週被找到的數量

3. 投資報酬率

殺頭的生意有人做, 賠錢的生意沒人做. 因此, 如果要找到 bug 的費用, 比修復 bug 還要貴, 這時候可能就不會再測試. 例如: 為了找到下一個 bug, 需要 5 個人花一週的時間, 這樣的成本就很高.

有的人會用 Mean Time To Detect (MTTD) 的觀念, 來看看是否要繼續投資. 簡單的計算的公式是, 搜尋 bug 總共花費的時間/ 總共找到的 bug 數目. 例如: 花了 24 小時, 才找到 8 個 bug. 這時候就是平均 1 個要花 3 小時.

在第一循環的測試, 這個值可能很低, 平均每個 bug 可能很快被找到, 但是等到第二個循環或第三個循環, 這個值可能就很高. 這時候如果你還要找下一個 bug的話, 你可以思考這樣是否值得.

4. 共識

上面講起來很漂亮, 都有一些數字來輔助, 有了這些資訊, 我想是每個人都很容易決策是否要繼續.

但是 … 就是那個但是, 大多數的團隊沒有這些資料. 或者有些專案, 不值得花代價, 或沒有錢去花這些代價, 因此那我們要怎麼辦呢?

我們可以用一些非科學的方法來處理. 雖然不科學, 但不一定不準, 這裏的作法就是詢問大家, 讓大家做個簡單的討論, 哪些地方還有問題, 哪些種類的問題, 出貨會有什麼風險, 如果有可以怎麼補救. 這些討論完, 其實大概就可以知道是否能出貨.

5. 老闆說出貨

這裏的決定方式, 就是老闆說要出貨, 那就出貨了.

一方面, 他是出錢的人, 他還是有決定權.

另一方面, 如果你覺得有問題, 測試人員很大的責任, 就是要提供足夠的資訊, 讓管理明白受測產品的品質. 如果你已經盡全力提供這些資料, 那不能完全怪你.

如果事後出包, 老闆不承認自己的錯誤, 並且還很用力責備測試人員, 我想你有天會想明白該怎麼做的.

6. 到處都是錯誤

這個狀況很單純, 有些受測程式, 在短短時間內就找到一堆 bug, 或許 30 分鐘內就很容找來 20 多個 bug. 這時候不用多解釋, 也知道出貨出去是會死人的.

7. 計畫的事情都已經做完

通常在開始測試執行之前, 總是會有個簡單的計畫, 不管是寫到多詳細, 總是會列出大約要做的事情.

如果這些事情都做完, 並且所找到的 bug 也都解掉, 我想這時候是一定可以出貨.

但是 … 就是這個但是 …. 目前我還沒看過這麼順利的案子, 能在專案時間到之後, 沒有大問題就笑很久.

8. 錢花光了

這個狀況不常見, 錢花光, 導致沒有錢可以支付員工或是測試的人.

這種狀況可能是新創的公司比較常見. 或者是接案公司, 錢給不進來. 所以也就沒有測試要進行.

9. 重要的錯誤已經修復了

這種通常是 1.0 的產品, 這時候這個產品有沒有人還不知道, 所以你把品質做到 100 分不重要, 重要的事先確認是否有人要. 因此, 對於這種版本, 只要確保主功能沒問題, 就可以發佈到市場上. 等到有人要, 會大賣, 我們再往上提升品質的要求.