上篇講到自動化測試與手動測試都有適合應用的場景及必要性，兩者皆不可偏廢。

在手動測試中有個分支，叫做探索性測試 (Exploratory testing)

近年軟體開發因為DevOps(開發運維)與Agile(敏捷開發)這兩大概念的盛行

探索性測試這個被歸類在敏捷測試下的測試方法也就重新被大家重視

接下來簡單介紹探索性測試的核心觀念

探索性測試的核心

這個網路上抓到的圖畫得不好，應該還會有順時鐘的四個箭頭

代表整個測試是經由 設計->執行->分析->學習->設計

最後再接到新一輪的設計階段，週而復始的優化測試品質與測試覆蓋率

探索性測試 vs 腳本測試

探索性測試，本質上是一種黑箱測試（Black-box testing）

意思是你在不了解程式邏輯的情況下，從使用者的角度對你的軟體做各種功能測試

這是一種最貼近使用者的測試方法，能更容易發現使用者可能會遇到的問題

舉個例子，今天你在測試一個跑在Windows筆電上的商用軟體

上班族的使用者行為(user behavior)可能從某層樓搭電梯到另一個樓層的會議室去開會

筆電的狀態會從正常使用 -> 休眠（關上筆電）-> 斷網路(進電梯) -> 重新連線(出電梯) -> 登入(開啟筆電)

在這樣場景下，你的軟體能不能正常運行不Crash，不測試其實沒人知道。

RD對軟體本身的邏輯判斷與功能實作可能想了很多很完整的解決方案

但是對網路狀態與系統狀態的錯誤處理(error handling)不一定都會想得很全面

不過對使用者來說，我就是裝了你們家的產品，出問題我就是要你們修到好（誤）

而相對於探索性測試

基於腳本的測試(Scripted test)就是白箱測試 (White-box testing)

意思是測試有已知的標準答案，驗證過程跟答案是跟著程式邏輯走的。

比如說後端的 /healthcheck API 在服務上線之後

正常情況下戳這隻API，HTTP response都會是200 OK。

那你不論是手動用postman去打或是用簡單的script都可以成功驗證這件事。

或是今天測試一個藏書查詢的網站，輸入一個不存在的藏書編號之後

會跳出查詢到0筆的藏書記錄，且不會跳出其他不相關的藏書在查詢結果等。

簡單小結

從比較實用的觀點來看，我總結上面提到的兩種測試：

• 探索型測試

  • 先設計再執行最後再分析學習
  • 著重在測試有價值的使用者情境(user scenario)
  • 著重在發現潛在的未知問題
  • 以手動測試為主

• 傳統腳本測試

  • 先分析再設計最後再執行測試
  • 順著程式邏輯設計測試案例(test case)
  • 確保已知問題不會再發生 (搭配自動化測試效果較好)
  • 包含手動與自動測試

所以手動測試是不是真的不再被需要了呢？我認為以一個經驗足夠的QA

探索性測試也許比腳本測試更能抓到使用者實際會遇到的問題

藉而提早發現軟體開發過程上的瑕疵，讓產品品質在發布前達到一定的信心程度。

而上一篇的標題問句：自動化測試是否為QA必要之惡？

我自己覺得它不能作為評斷QA好壞的唯一標準

能夠寫自動化只是一個分支的技能，運用這項技能可以讓程式幫你做重複的事

但QA技能樹還有很多可以精進與學習的地方，切莫見樹不見林。

既然說到探索性測試，那下一篇就不得不提敏捷測試了。