有一位程序員，喜歡新東西，經常引入新方法新思路試圖改變現狀。
有一次，他覺得部門在測試手段太依賴手工測試了，於是就想引入自動測試。他調研試用了幾種工具以後，選擇了某大公司的產品作爲主要工具。
他計算了一下，一共有1000條測試用例需要自動化，於是他定下計劃:一個人一天可以寫5個測試用例，所以需要200個人天;計劃要在一個季度完成，按一個人一季度共60個人天的話，需要4個人還有餘。這樣，全部用例做好以後，他估計，至少減少一半測試工作量。
於是，這老兄報告給總經理，總經理同意了。於是就給他招了4個人，成立了自動測試組，風風火火就幹起來了。
他的做法是，手工測試有多少條用例，他就用自動測試工具實現多少條。
一個季度下來了，全部測試用例完成了。當然大家敲鑼打鼓的慶祝。但接下來，卻遇到了意想不到的問題。
第一、所有的測試人員都認爲自動測試組寫出來的腳本沒有用。爲什麼呢?因爲自動測試組的員工都是新招的，對產品不熟;因此他們只好對照着手工測試用例一條條的做，就像做翻譯一樣把手工測試用例變成自動腳本。但測試人員說，手工測試用例本身就不夠完善，很多測試的驗證點是憑經驗的，這樣翻譯出來的用例當然不過關。
第二、新產品特性已經改變了，寫出得腳本過期了。因爲是比照着手工用例，自動測試組使用的用例是產品的上一個版本的，這樣寫出來的用例當然不適合現狀。
第三、短期內投入產出比很低。手工測試一天能走100個測試用例，1000個用例10天走完。但4個自動測試工程師3個月才完成1000個用例的開發，也就是花了4×3×20=240個人天，就算測試用例100%可用，也需要240÷10=24輪才能在成本上持平，如果每個版本測3輪的話，相當於8個版本。而8個版本，產品還在不在都難說了。
程序員做了反省，發現自己犯的最大錯誤是:自己提出問題的初衷是減少測試工作量，但執行的時候卻把“翻譯”完所有的測試作爲了目的，而忘記了最初的目標。因爲只顧着往前趕數量，從來沒有請手工測試的工程師來看看，是不是可以100%替代手工測試;也沒有在小模塊上試試，看看開發人員有什麼意見。
這樣，程序員改變了做法。和開發、手工測試和手下溝通後，他決定把自動測試工程師分散到模塊去，和相應模塊的開發，測試成爲一個工作小組。開發人員設計編碼的時候，他們就設計自動測試用例，充分聽取手工測試工程師的經驗，並且每天都運行一遍。這樣，自動測試的腳本就完全和產品同步。他們把自動測試用例和產品代碼簽入到同一個代碼庫，同樣的版本具有同樣的標籤，這樣，每個版本的產品都有了自動測試的腳本。
這樣，又過了一個季度，團隊開始接受自動測試了。而且有了一個意外的收穫，開發人員現在樂於用自動腳本做單元測試，居然開發效率和質量都提高了。
程序員得出一個經驗，目標在最初的設定，一般都會比較清楚的，但在漫長的實現過程中很容易忘了原來的目標是什麼，而把一些表面的指標當成重要的東西。因此，經常看看今天所做的努力和原先的目標是否一致，和能否一致，是很重要的。