sqz777 der 技術小本本

今天這篇只有紀錄了第一篇的...部分內容
第一章還會有一篇我覺得十分有趣，應該會再發布一個文章來記錄。

這本書的故事開頭由一個22歲剛畢業的新鮮人小宇作為開頭，進入的公司即將進行敏捷的變革，公司找了業界知名的敏捷教練，讓整個公司發動變革，然而這場變革，其他人都十分的興奮，但唯有一群人眉頭深鎖，而這群人就是測試人員。

敏捷轉型意味著必須擁抱變化，如果變化得多，那測試的效率如何提高？測試的質量又如何保證呢？

小宇作為一枚新人，當然感受不到這樣的疑惑，只意識到敏捷轉型在公司已經是勢在必行的事。

我的ＯＳ：這一段我真的有一種很重的既視感啊．．．連年齡都一樣

書中提到，測試人員眼中認為軟體開發應該是這樣的

• 需求是清晰的
• 流程是固化的
• 開發是有序的
• 系統是可測的
• 測試時間是充足的
• 用戶是講道理的

但現實往往是相反的，所以對於需求頻繁變化越來越覺得合理和正常，開發人員延遲開發計畫、壓縮測試時間成為常態。加班這件事似乎成了一種習慣。
書中提了以下幾個問題

• 我們還能隨心所欲的設計大量測試用例？
• 還有大量的系統測試和整合測試時間嗎？
• 還能要求充足地回歸測試嗎？
• 還能期望開發人員提供各種測試建議嗎？
• 現實如此，測試還能不能愉快地進行下去？

問完這個問題後故事接續了下去，全公司接到了這樣的一封信。

字很多可以，意思大概是這樣。

給技術部門的各位大大們：

　　我請一位開發人員修改一個公共的方法，只有三行程式碼。但你們測試人員告訴我因為不確定影響了哪些功能，所以要測試所有核心功能加上各種版本問題所以需要２個禮拜的工作量。

　　這樣我們還是敏捷開發的企業嗎？我也是技術部門出身，以前我深深地以技術部門為榮，今天我不得不以之為恥！

在這之後測試部門開了一個會得出了兩個結果。

1. 縮短回歸測試的範圍
2. 依靠自動化

故事中，決定了先嘗試第二種方案。

最後就發生了自動化過度倚賴ＵＩ，然而ＵＩ大改版後而產生自動化爛掉的情況導致相關人員加班到半夜的狀況也不是稀罕的事。

而我們公司算是兩個都選擇了，目前仍然進行中，一邊盡力縮短回歸測試的範圍，一邊增加自動化的覆蓋範圍。

自動化的價值？

書中是這麼說的
在傳統的瀑布式開發裡，自動化的推行，是一種進步；而在敏捷開發模式裡，自動化勢必不可少的基礎。

而我是這麼認為的．．．
只要你是在軟體開發裡，任何重複的瑣事，都應該要被自動化（如果成本合理），否則這些細小瑣碎的事情遲早會變成龐然大物找你麻煩
還是這些麻煩會創造一種職缺？（誤

備註:自動化依然是有前提的，你仍然需要了解流程還有確認過是否「需要」再進行自動化。

在這裡先簡單的提一下自動化所涵蓋的東西有哪些

• 測試環境的建構和管理
• 測試環境的監控
• 測試情境的建構還有數據準備
• 測試報告的生成
• 測試用例的發布和執行
• ...還有很多，但主要大概這些

以下的檢查書中都是寫「測試」喔．．．但我覺得目前這個世代還沒有到自動化「測試」這個階段，所以我還是覺得寫檢查比較好。

• 自動化能提高效率，縮短檢查的工作時間。
• 自動化和人工檢查相比，每一次的檢查執行操作都是固定的，非常忠實、可靠。
• 自動化檢查能加大每一輪回歸的力度，從而提升覆蓋率。
• 自動化檢查具備更好的重現軟體缺陷的能力，因為它有很強的一致性和可重複性。

這樣就可以看出自動化帶來的好處，所以自動化的ＲＯＩ也可以這麼寫。（以下成本的單位我推測應該就是時間）

自動化的收益＝迭代次數Ｘ全手動執行成本－首次自動化成本－維護次數Ｘ維護成本

如果迭代次數等於維護次數

自動化的收益＝迭代次數Ｘ（全手動執行成本－維護成本）－首次自動化成本

也因為這樣，所以容易說服老闆

自動化說穿了不過就是將一些人工的執行的瑣碎過程讓機器做而已

那麼就可以推斷，自動化可能帶來的好處有以下幾點

• 幫助回歸，節省人力
• 建構手動測時無法建構的場景、數據準備，或執行一些人工做不到的事情，進而提升覆蓋率
• 前置檢查，讓測試和開發有可能併行，提升專案敏捷度，降低測試獨佔週期

讀後想問的問題

各位大大們在自己身處的環境中是如何執行測試的呢?
而已經被自動化的東西又有哪些?
推動自動化這件事情遇到了甚麼樣的困難？