今天參加 iThome 的 Testing Day，聽完多場精彩的演講後，稍微整理一下聽到的內容。因為四場都和測試自動化有關係，所以就用這個主題整合四場心得吧。
一、Why - 測試自動化
為什麼要測試自動化呢？不管什麼原因，老闆只要你如期交付高品質程式，身為員工，自然要藉由測試，從程式碼開始，慢慢建構出高品質的程式。
在敏捷開發角度來看，程式碼異動與上版的頻率相當高，若沒有測試自動化保護程式，會無法於第一時間抓到異常，很有可能上版了才發現問題，導致公司信譽下降。
身為開發人員或測試人員，應該要有自信大聲的說，這次交付的程式碼都符合需求實例，也要能自豪的說沒有因為這次異動導致之前正常的功能出現異常。
或許你只是覺得手動測試太浪費時間而測試自動化。
因為懶？防止改 A 壞 B？想要安心的開發環境？那開始測試自動化吧！
二、How - 測試自動化
在開始測試自動化前，要請 RD 培養一些好習慣。
- 版本控制
- Daily Build
- 交付程式時附上測試程式：依團隊能力，一開始導入可以從顆粒較粗的整合測試開始。當團隊有實力後，讓核心關鍵功能加上單元測試。並不是要 ATDD 或 TDD，只是要求最終交付程式時有測試程式即可。當團隊漸漸變強，並從測試程式得到好處，譬如某次調整快速找出異常，防止重大 BUG 發生，這時候再導入 TDD，團隊接受度高，才會容易成功。
當 RD 養成的好習慣後，藉由 CI 工具（譬如 jenkins），每次簽入時觸發測試，達成 Build Test。
測試自動化絕對無法一蹴可幾，只有培養好習慣，一步一腳印才能達成。
那 QA 應該做什麼呢？串連前後端測試，功能間的串連，增加測試廣度與深度。當 RD 確保每個 Function 沒有問題，QA 就要確保功能與功能間串連沒有 BUG，進行 UI 測試或資料庫測試。因為要測試自動化，所以以上步驟要寫成 Script，然後才能讓測試自動化。
測試自動化絕對不是只有 RD 出力或只有 QA 出力可以辦到，只有 RD 與 QA 協同合作，一步一步累積而成的。
不要想說事情很多時程很趕沒時間寫測試程式，當測試自動化後，減少手動測試時間，加快找到 BUG，其省下的時間比寫測試程式時間還多。
三、What - 測試自動化
要如何開始測試自動化？David Ko 說趨勢科技導入是「先求有」，要求團隊養成好習慣，那怕剛開始只有幾個測試程式，那又怎樣，「天天跑」，持續下去。只要每次程式簽入時，Code coverage 增加即可。每次跑測試自動化時，一有問題簽入者要馬上找出問題並「快速回報」。只要做到這樣，就能達到近程勝利。
詳細內容可以到 David 的 Blog，內有更詳細的說明。
測試自動化 = 軟體開發，是 RD + QA 一起做的，從和 PO 釐清需求時就一同參加會議，一同確認需求實例。雙方都確認這次開發的任務(Know Your Mission)，拉平雙方間的認知，甚至讓 QA 到團隊中一起協同開發。QA 在每次完成功能後，從更廣的角度下去測試，探索出程式中的 BUG。RD 為了能測試與快速解決 QA 找到的 BUG，會改善程式架構，讓程式更容易測試。互相協同完成程式功能，也同步完成測試程式，一同簽入版控，達成自動化測試。
基本上，幾個 Tips 條列如下：
- Code coverage 設定大於 0%，每次簽入 Code coverage 要求一定只能上升(或不動)。
- 測試自動化結合靜態程式碼分析工具，確保程式碼正確且有一定的品質。
- 可以將補測試案例或重構加入 Backlog 中。
- 每次 Code coverage 大幅上升(譬如增加1%)，SM 一定要大聲的讚賞團隊成員，激勵士氣。
- 導入時可從測試顆粒較粗的做起，比較簡單才能快速累積成就感。
- 當測試程式變多後，可利用平行執行或調整測試程式等方式，減少自動化測試時間。
- David 說趨勢科技沒有做 UI 測試，但有做 API 接口測試。像我是會做 UI 測試(會用 page object)。要不要做 UI 測試，取決於你的 UI 是不是常改。
- 現在前端頁面也是要測試的唷，至少要做到整合測試。
測試自動化不是用來找出 BUG 的，測試自動化最大價值是防止改 A 壞 B，讓你放心重構而不擔心改壞。
四、心得
這次聽到講者各公司導入方法，重點不是工具，也不是技術，往往最大的問題是人。以上整理朝測試自動化之路前進的一些心法與作法，只有實際做下去，才知道上述各環節實作之困境。也只有做了才知道測試自動化為團隊帶來的好處。往往說的多想的多，不如先求有，Show, don't talk.。
測試也不只是 RD 或 QA 的工作，PO也要一同協助團隊產生需求實例，這些需求實例就是測試的基礎，將這些基礎串連起來，達到自動化測試。
第一次撰寫類似文章，文筆不好或寫不清楚，煩請各位高手留言告知。