Automated acceptance tests

June 30 21:05~22:06

講到火鍋，就想到牛x牌沙茶醬；講到 automated acceptance tests，就想到 Robot Framework（以下簡稱 Robot）。

話說約一年前 Teddy 從指導教授那裡聽到 Robot 這個工具，當時就有一股想要卯起來導入的衝動。無奈 Teddy 自己不懂實做細節，也沒時間去學（其實是人老了開始變懶...XD），再加上 product backlog  裡面的 stories 已經快滿出來了，沒什麼空間可以『插花』加入寫 Robot test cases 的 stories。雖然剛開始的時候 Teddy 跟 team members 介紹了 Robot 這個工具，也有安排時間讓大家『摸一下』，但是卻沒有立刻『動起來』確實採用 Robot。

其實說沒有『空間 or 時間』只是自欺欺人的講法，主要的癥結點還是決心問題。某日 Teddy 心一狠，決定每個 sprint 都至少安排一個寫 Robot test cases 的 task，至於能寫幾個 Robot test cases 倒是其次，一開始的重點是『這件事情有開始在動了』，這樣 team members 也才有機會可以慢慢熟悉這個工具。

到現在，已經累積了不少 Robot test cases，數量多到可以從晚上下班之後跑一整夜，有時候一直到隔天上班都還沒跑完（ㄟ...這種情況其實是發生不明原因才會跑這麼久...XD）。看到這邊鄉民們應該會問，這些 Robot test cases 都在『跑些什麼』？

基本上，可以把 Robot test cases 至少分成以下幾類：

• 標準安裝，反安裝：講得好聽一點，Teddy 的團隊算是有達到某種程度的『continuous delivery』。基本上，每天都會產生 N 次的安裝程式，以方便做 end-to-end 測試（例如 acceptance tests）。這一類的 Robot test cases，可以快速驗證這一次所產生的安裝程式能不能在該軟體所支援的平台上面以『預設模式』被正確的安裝（該啟動的服務或是應用程式有沒有啟動，該安裝的檔案有沒有存在等等）與反安裝（該移除的目錄，檔案，或是捷徑等有沒有被刪除）。對與每一個所支援的平台（作業系統），跑一次這種測試大概只需要幾分鐘的時間。
• 快速功能驗證：假設鄉民再過 5-10 分鐘之後就要把剛剛才產生出來，還熱騰騰的安裝程式立即交給客戶使用，那麼你會想跑哪些 Robot acceptance tests？從這個角度來思考，被選出來的 Robot acceptance tests 就屬於這一類。如果是一個 web 系統，通常 login 這種功能是最優先被測試的。如果客戶連 login 都不行，那其他的功能就不用說了。接下來還可以檢查每一個網頁的 link 是否都正常之類的。快速功能驗證有點像現在很流行的『快速剪髮』，方便，便宜，但是...別肖想會剪得多漂亮。
• 重要功能測試：假設這一次鄉民們時間比較充裕一點點，再過 10-30 分鐘（or 10-60 分鐘，依據不同團隊與專案規模來動態調整） 之後才要把軟體交客戶，那麼就可以多選一點測試案例來執行。當然這一點點時間還是不足以將全部的 Robot acceptance tests 跑完，所以挑選的原則就是『從重要，或是經常使用的功能開始挑選』。如果能夠跑到這邊，那麼對於這個版本的信心指數應該可以達到 60 分了。
• 所有功能測試：所有的功能都可以被測完一遍，不同的專案依據其規模大小與所支援的平台多寡，所需的時間可能差異很大。基本上跑完這一個分類信心指數應該可以達到 85 分以上。
• 所有非功能測試：所有的軟體系統一定會有『非功能需求（non-functional requirements）』，例如 availability，reliability，security，performance 等等。如果連這一類的 Robot acceptance tests 都可以跑完，那麼 信心指數應該可以達到 99 分以上了。

為什麼只有 99 分以上而不是 100 分？很簡單，敢問鄉民們何時用過 100 分的軟體？而且有些測試，像是 usability ，還是需要『真人參與』，恐怕很難自動化。

***

以上的分類，主要的精神還是 agile 的 time boxing 精神。做任何事情，都要有『時間觀念』，有多少時間，做多少事，Teddy 覺的這一點很重要。要成功導入 Robot，要克服幾件事：

• 第一階段要克服『沒有時間做 automated acceptance tests』的心裡障礙（任何改變都是困難滴）。
• 第二階段要克服『沒有能力做 automated acceptance tests』的技術障礙（寫 Robot tests 也是有點小難度）。
• 第三階段要克服『沒有足夠數量 automated acceptance tests』可以被執行的障礙（數量不夠，coverage 很低，找不到問題，有跑等於沒跑）。
• 第四階段要克服『沒有足夠時間來執行 automated acceptance tests』的障礙（時間不夠，想跑也不能跑）。

Teddy 靠很強的 team members 也搞了快一年才略有小成，後面的路還長的很。

***

友藏內心獨白：只要傻的願意相信，就有可能化不可能為可能。