有人問我在實施例化需求時, 為什麼一開始不在乎自動化? 如果能自動化, 不就一直可以確認開發人員, 是否照著當初所確認的需求去做, 並且也可以及時檢查. 為什麼呢? 我一開始認為有以下的理由:

 

bulls-eye  

1. 專案背景: 目前我的專案一開始需求很不確定, 老闆也不知道要做什麼, 所以重點不是在於自動化, 而是在於確認範圍是什麼.

2. 要先確認有用: 要導入一個新的方法, 不管那些方法被吹得多好, 都必須先要讓大家接受,  讓大家覺得有用. 一個小的, 及時的成功是需要的, 那個成功絕對不是自動化.

3. 個案的深淺: 到底實例或是個案要寫多少? 然後要寫多深入? 這個問題很難很快有解答, 因此釐清楚會比盲目先去自動化好.

接著我再深入思考我到底在擔心什麼, 發現其實內心還是認為自動化沒有辦法找到太多bug, 因為你能自動化的部分大多是大的 scenario, 並且個數也不太多. 再加上第一次做, 可能會花不少時間在處理自動化測試系統, 尤其是要開發人員來配合更是困難重重. 反而讓大家會有挫折感.

也就是說, 我認為這種自動化對測試並不會幫太多忙, 因為找不到有太多有營養的 bug.

後來我在反覆思考後, 我發現自己得了銀製子彈的病. 企圖想用一種工具, 就解決所有問題. 沒有一種工具或是方法, 用了之後就會把所有事情都解決, 你必須了解使用時機, 將他們一起搭配使用, 這樣才能發揮最佳效用. 

就像防毒軟體一樣, 大型企業都不會只採用某一家的解決方案, 一定是使用數家的產品, 分別部署在不同關卡, 這樣才能擋下最多攻擊.

所以就算自動化的個案不多, 但是我還有別的機制去確保品質, 但是他能確保一些基本功能仍然可以運作. 也就是說, 雖然實施例化需求網子的洞大了點, 但是我有好幾張大小小不同的網子, 只要用的得宜, 效果還是有的.

下週叫 engineer 開始研究一些工具吧, 多張網子還是好的, 至少我們有在編網來抓住夢想 XDD

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()