Test Corner #34 是一次非常特別的社群活動, 除了 Oneday Software 與 Test Corner 一起舉辦之外, 也感謝阿福管家 Howard 及團隊許多用心的安排, 讓上了一整天班的與會者可以享受其中. 自己很榮幸參加到這次 Event, 並且擔任講者, 見到不少老朋友, 也認識了許多新朋友. 回顧 Test Corner #1 ~ Test Corner #34, 從一群小火苗到現今的人數, 社群真的需要大家的支持, 才能讓火繼續的燃燒.
猶記得 2024 年初收到 Howard 傳來 LinkedIn 的訊息, 想要結合社群的力量拓展軟體測試的深度與廣度, 並且回應 Oneday Software 成員的許願, 舉辦一場實體的分享會增加社群的黏著度. 就在我的小小推坑之下, 連結了 Test Corner 夥伴與 Howard 接洽. 無形間也促成了這次的活動.
除了前言, 這次也很開心可以認識 Mark 大大, 聽到 Google Test Engineer 軟硬體整合測試的經驗, 也聽見了阿福管家 Max 跟 Kevin 在實務上遇到的問題及解決方案. 受益良多.
這是我在疫情後第一次對外的實體分享, 也想回應給社群的夥伴, 分享的主題其實不只有硬實力 (Automation Test, Performance Test…) , 任何測試的想法或實踐都可以來 Test Corner 分享. No Majic Just Basic. 跳脫以往只給乾貨的內容, 這次更多的是分享基礎能力的培養, 並且應付突如其來的變化的撇步.
更多分享的內容稍早已經發佈:
截至目前, 已經有 5 場對外社群分享的經驗 (TestCorner #4, Mopcon2017, TestCorner #16, iPlayground2019, 軟體發展協會專題演講), 疫情期間大多是以線上分享為主, 漸漸忘記實體分享的手感. 但歸功於過去的經驗累積, 讓我在台上無比的自在, 準備的時間也縮短了, 並且整體時間拿捏也剛剛好. 雖然如此, 每次的經驗跟 Q&A 都能讓我學到寶貴的經驗.
- 別看我在台上可以輕鬆侃侃而談, 我還是必須一次又一次的感謝曾經給我建議的前輩們, 是你們讓我勇敢在眾人面前分享, 在每次的分享後, 越來越成熟.
- 這次的 Q&A 時間來得有點突然, 但老樣子, 準備的問題一項都沒有被問到. 這次有一個特別的體驗, 出現了許多跟過去分享重複的問題, 我想這可能是大家的痛點, 也可以成為未來寫作及分享的主題.
- 這次的大挑戰是在工作的轉換期間插入了社群分享, 一面要應付新舊工作的轉換, 一面也要思考分享的內容. 必須利用下課的時間預備, 在頻繁的 context switch 下, 白頭髮也多了幾根. 歸功於過往經驗, 這次準備的時間縮短成 1~2 天, 沒有 rehersal 直接上台分享, 可說是一次不錯的體驗.
- 另外一個挑戰跟現場觀眾實體互動, 特別準備了蘋果的問題 (源自於軟體測試之道：微軟測試團隊的成功經驗 CH6), 事後有夥伴反饋說這個舉例很有趣, 正中人心. 唯一美中的不足是自己的現場引導技巧還不夠熟練, 也是我未來需要加強的地方. 但隨機發揮及信手捻來的話題, 應該已經是個人的特色了.
由於時間的關係, 當天並非全部都回答完 slido 上面的提問, 所以選出幾個很有啟發的問題, 並嘗試回應, 也歡迎後續找我聊聊跟討論.
若有遺漏, 後續有機會再整理一篇分享
A: 這是一個很實際的問題, 倒底是要先手動測試還是自動測試. 當然這題也是要回到團隊本身, 以終為始, 若團隊是以高比例的自動化測試案例為目標, 就該思考當下團隊的能量如何, 若人力已經不足負荷產品出版, 是否就該停下腳步重新調整, 如果今天團隊有很充裕的資源包含人力跟時間, 那隨時跟上會是一件很開心的事. 推薦讀者閱讀軟體測試實踐 — 業界成功案例與高效實踐, CH7.4.2 小節有不錯的經驗談.
A: 假設問題背後的問題是當自動化測試案例指數性成長後, 測試時間拉長影響到出版的時程. 這時我們可以回過頭來思考團隊怎麼對於測試案例分類. 有了妥善的分類, 那就更容易在 pipeline 某些階段直接某些特定的測試案例, 事半功倍. 至於多久審視測試案例一次, 我想也是要回到團隊本身, 也許在產品的淡季排上還技術債任務, 大掃除一番.
A: 當天沒有很有組織的回答, 但會後想起當初在趨勢服務時, 提倡的 80/20 法則, 因為不太可能有 100% coverage 這件事, 即使辦到了 100% 也肯定有漏網之魚. 80/20 會是一個合理的比例假如團隊需要定義的話. 此外, 若使用工具量化, 也可以試試 Jest (如果讀者是 JS 開發者的話), 在測試結束之後, 同時也會產一份 Coverage Report 衡量現狀. 但如果這題背後的問題是在質疑 QA 團隊怎麼沒有防守到某個 issue 時, 那可能需要重新思考品質是每個人的責任, 不是單一團隊的責任.
A: 不確定這個問題是要問測試右移, 還是考慮何時導入測試右移. 如果是後者的話, Shift Right Testing 更多的是在探討產品上線後的 Test In Production, Observability Test 等. 也許未來針對此議題, 分享過去的經驗. 如果是前者, 推薦讀者閱讀軟體測試實踐 — 業界成功案例與高效實踐, 裡面 CH8 專門針對此議題分享, 歡迎讀者前往閱讀.
A: 工具有蠻多的, 推薦像是 Gherkin 基於 Abstract Syntax Tree (AST) 產出的 Framework 方便團隊規劃測試. 或者讀者可以自行處理也是不錯的選擇.
附上一個案例:
A: 推薦下面這篇分享, 裡面能夠找到答案.
附上活動照片
投影片
錄影
最後附上投影片, 錄影, 歡迎一起交流～ 有機會來分享~
