自動化測試要做到以下這樣是有點難度的
(1) 自動化程式沒有用戶經驗
工程師不是用戶, 他可能沒有實際使用產品的經驗, 沒有實際拿產品來解決問題, 真正去做些事情. 因此, 工程師寫出來的自動化, 跟真實狀況可能差很多
(2) 太小的專案, 自動化的投資報酬率太低
有時候客戶叫你改個小功能, 叫你下午就給他. 這時候把程式寫完就差不多, 要能再多寫些測試程式真的很拼. 更不用說如果是 legacy system, 更不太可能簡單就寫出測試程式來驗證.
(3) 所謂 pass 不是一成不變的
什麼叫做這個測試個案通過了? 程式是人寫的, 寫檢查什麼就是執行什麼, 不會少做也不會多做. 可是人不一樣, 好的測試人員會多看一些, 東 try 一下, 西 try 一些, 往往可能會看出更多問題. 你可能會說 pass 條件應該要一開始就寫好, 但是系統很複雜時, 你很難想的很周全, 有可能是越多嘗試, 越看出更多有疑惑的地方. 但是測試程式不行. 或許 AI or 深度學習有指望, 但應該還要一陣子吧
(4) 整合設備很複雜
有時候你整合一堆網路設備, 硬體設備, 或是 IoT 裝置等等, 這些東西都有介面, 都可以用程式去控制嗎? 可能沒有, 也可能有. 就算有, 投資報酬率是否是你可以接受或負擔呢?
(5) 測試程式無法很快重現客戶的問題
當你的客戶在他的真實環境中, 找到了一個 bug. 你會去寫個程式重現他的問題嗎? 或者是你交付了 hotfix 後, 你就可以寫出測試程式去確認這個 bug 是有被修復嗎? 或許有可能, 但時間會花很長. 另外, 客戶的環境也可能你是無法模擬和接觸的, 這時候你是無法靠自動化測試程式, 還是需要人工去確認處理的.
(6) 你無法處理你想像不到的狀況
就像前面所說的, 程式是人寫的, 寫檢查什麼就是執行什麼, 但是 bug 往往就在你想像不到的狀況, 因此, 當自動化程式的行為是固定時, 這是不足夠的, 需要人工介入, 讓人的創意來探索更多狀況.
文章標籤
全站熱搜
留言列表
