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