(1) SDET 只寫測試程式, 但是不做手動測試. 他其實就只是在開發, 他在開發測試程式, 他不是在做測試 ….
(2) 測試自動化只是 checking, check 你已經知道的東西, 是否有出錯. 所以他無法找出未知的 bug, 他只能發現原先知道的自動化場景不 work
(3) 如果是 RD 底的當測試人員或是測試主管, 首先要改變一個思維: 假設任何地方都可能出錯
(4) 測試自動化寫完後就不用管. 通常是
a. 它沒有在執行
b. 它的量少到不行
c. 它都 return true
(5) 如果 Daily meeting 都沒有聽到測試自動化失敗的訊息, 沒人說他要去修復測試自動化, 這是一個 bad smell
(6) 要常常去 review 測試程式的 code, 你會看到很多很神奇的地方
(7) 寫測試程式就是在做軟體開發, 軟體開發會遇到的爛事, 測試自動化一樣會遇到. 你沒有 code review, refactoring, 日子久了測試程式就會越改越慢, 越來越不穩定.
如果沒有, 通常代表他們沒有持續在寫測試程式
(8) 測試程式的執行結果, 每次執行都要寄出來給團隊分享, 上面要說明跑了多少 test cases, 成功多少, 失敗多少, 執行多久. 你就會看到很多貓膩 …
(9) UI 的測試自動化, 如果沒有常常出錯 …. 絕對不是你選對工具, 也絕對不是你設計測試程式的功力很強. 絕大多數就是 test case 的量很少, 或是沒有執行.
(10) 開發測試程式需要做架構設計, 不要讓 QA 或是沒有經驗的 SDET 主導, 當 test cases or test program 多的時候, 就很難調整. (如果真的有天會寫很多)
(11) 測試金字塔是要告訴你測試要有不同顆粒度, 不該一條道走到底, 要有 unit test, integration test and UI test, 只是比例不同. 但是不管比例如何, UI test 的自動化絕對輪不到他是大宗.
(12) Unit Test 是絕對值得大量投資, 尤其是 RD 要開始做的話. 另一個就是 API test, 這部分比較不用牽扯大量架構修改, ROI 比較高.
(13) Smoke Test 是一個很好的 E2E test automation 起點. 可以多做, 並且整合到 CI 中. 但是不適用 UI automation 方式來落實.
(14) 測試自動化有錯就要立即修復. 否則日子久了, test program 就變成廢鐵
(15) 測試程式維護的成本, 遠比你想像多得多, 如果你們有持續做的話. 只做幾次的話, 或許沒有.
發表迴響