我們與bug的距離

最近跟同事分享軟體測試的做法與工具
同事提出一些問題引發我後續的思考
1.寫了測試可以幫我們找到bug 嗎？
我回答測試比較像是保護程式不出現 bug ，因為程式寫完、測完之後就不會壞掉了，會出現問題通常都是在程式有變動，像是加入新需求或是需求變動的時候，而軟體測試就是要確保我們變動之後，之前的需求還是有被滿足，沒有產生bug。
2.另外一位同事提出，他以前公司曾用過monkey test 來找bug 。

這兩個問題讓我開始思考，bug的定義是什麼？
先不要看網路上的資料，先自己思考一次。
不符合需求的是bug，那需求上沒寫的呢？
會crash？這應該是大家都認可的bug
那跑版呢？這就要歸咎原因是多尺寸裝置或不同瀏覽器造成的，還是程式寫錯，如果是多尺寸裝置或不同瀏覽器這就是沒在需求中不是bug，而程式寫錯當然就是bug。

以前我會覺得monkey test沒用，但隨著對各總不同工具的了解跟體會後，說沒用這個詞太重了，每個工具都有可能可以解決測試上的部分問題，只是%數多寡而已。

之前朋友跟我分享他們家的測試很厲害，測試 Android 的SeekBar 可以測出bug 。

那他是怎麼測出來的呢？據說是點著微抖動幾十秒之後會 crash ，然後他去看log是這個元件底層產生的錯誤。

這樣也算bug嗎？這根本不符合一般使用狀況，這個案例就很灰色地帶了，因為他的確造成了crash 但這也不是在需求之內？

就像做一臺電風扇，我們也只會測開關正不正常、有沒有風，比較看不見的就是電壓或是零件有沒有符合相關的安全規定，但應該不會有人把它拿去北極然後冷到轉不動說這臺電風扇有問題吧？但在軟體上就很難說了，因為軟體上的極端狀況不是大家都能理解的，上面那個例子就是極端狀況，而且大部分的使用者不會這樣使用，我不會覺得他是一個bug，大家認為呢？

而我覺得monkey test 效果比較不好的點是，其實大部分的人期待monkey test做的是探索測試，但它做起來卻比較偏向壓力測試，而探索測試比較像沒有規格的手動測試，就是直接看畫面上有什麼去建立使用邏輯或者做不同邏輯的使用操作試試看會不會 crash 或是探索出一些規格上當初沒定到的需求或邏輯，這部分是我覺得很難用工具取代的部分，而規格上有的邏輯就可以使用軟體測試去驗証減少人力在回歸測試上消耗，或是避免根本不做回歸測試產生的問題。

舉電風扇的例子，我風速1跟風速2一起按會怎樣？如果當初需求沒有定義這塊，就會靠探索測試來挖掘，然後討論這是不是問題，要怎麼解決？如果是就要定出新的需求，如果不是也要記錄下來然後找是否會導致什麼更大的問題，像我風速1跟2一起按沒功能沒關係，但至少不會因為短路而害電風扇燒起來。

功能(feature)是人定義的，bug也是人定義的，所以才會有這不是bug是feature這個笑話產生，有問題的時候大家應該開放心胸的互相了解與討論，而是不是自己為是的定義與譴責，就像台劇『我們與惡的距離』一樣，要讓這個世界(產品)更好，需要互相去理解而不是去譴責。

最後希望你帶走知識的同時，也能留下一兩句的心得與我們分享或是幫我們按下+1並分享到FB