goescat in Testing

在我的職涯裡，我常常是一間公司第一批的自動化測試。 這也讓我發現了自動化測試這個職位的有趣之處——在一間公司最欣欣向榮也最混亂的時候加入戰局。 🤖自動化測試很稀有！？ 我曾經在某間公司聽到了一個很有趣的問題。 那間公司剛招募自動化測試，而我是第一個加入的。 當時有個 PM 和我聊天時問道： 「好酷喔！我到這間公司才第一次知道有自動化測試這種職缺，我以前待過的公司都沒有！自動化測試是不是很稀有啊？」 忽然被這樣問，我反而有點驚訝，我不假思索的回： 「真假？但我之前待過的公司都有自動化測試。」 講完才發覺自己根本在講幹話🫪 我一直在做自動化測試，當然去到的每一家都有，我才會在那裡😂😂 - 上面只是個工作上有趣、輕鬆的插曲，不過從這個問題也確實讓我想到： 「沒錯，並不是所有公司都有自動化測試。」 「一間公司到了某個階段才會需要找自動化測試。」 「自動化測試很容易在一個很有趣的階段加入公司。」 因為一間公司通常不是在產品剛開始的時候，就覺得：「我們要建立一套完善的自動化測試！」 更多時候，原本大家都還相安無事⋯⋯ 🌱 產品還小的時候，手動測試、大家一起測試就好 剛開始的產品，可能只有一兩個核心流程，功能還不多，業務邏輯也還很單純。 今天改了一個功能？Dev 自己測一下。 明天多了一個流程？PM 一起多測一下。 即使回歸測試純手工，但因為產品也不大，跑一次也許幾小時、半天就結束了。 很多公司在這個階段甚至根本沒有 QA。  Bug 修一修，PM 測一下、Dev 自己測一下、老闆本人點一下，產品就能上線了。 如果這時有人跳出來跟公司說：「我們應該建立自動化測試。」 大家的反應很可能是： 「蛤？」 「為什麼？」 「現在不是測得好好的嗎？」 大家說的還真的沒錯。  因為自動化測試不是只要有產品就一定要有。 自動化測試本身也需要成本。 要寫、要維護、要有測試環境、要處理 test data、要處理 flaky test。 有些功能每天介面都大翻新，你花三天把它自動化，立刻又失效；有些功能非常隔離幾乎不會被動到，你花三天把它自動化，結果之後一年只跑了兩次，或是每天跑但是單純快樂表—— 那這些根本不值得自動化。 自動化不是把測試交給程式就沒事，自動化本身也是一套需要持續維護的軟體系統。 📈 直到某一天，產品開始長大了 公司開始成長。 Dev 從幾位變成十幾位...

我早期的經驗都是在做自動化，後來一點的經驗則大多是一個人負責一個專案的測試。 直到近期這份工作，有些專案到了測試階段，可能同時有好幾位 QA 一起測試，我才開始有了和另一位 QA 密切合作的經驗。 某次專案，到了測試階段，重要的主流程卻還有許多 blocked issue。 我們一開始就開了好幾個 critical bug、major bug，同時也發現了介面上有許多可能沒有那麼重要，卻和設計稿不一致的 minor bug。 一開始，我們都按部就班的把 minor bug 開起來記錄。 但眼看時程慢慢推進，一些 critical、major bug 反覆驗證還是失敗，Dev 卻開始先處理 minor bug⋯⋯更恐怖的是，minor bug 的修正，竟然導致了新的 major bug。 這時我在開 minor bug 前都很糾結。有時候真的很希望 UI/UX 和 PM 能放過這些小問題。我開始考慮去和 UI/UX 和 PM 對一下，說服他們維持現狀⋯⋯ 以前的我一直覺得，這是不是代表我有什麼問題。 心靈強大的 QA，看到 bug 應該手起刀落吧？ 「不一樣就是不一樣。bug 開就對了。」 - 但有一天，我和另一位 QA sync 彼此的進度，他截了一張圖給我。雖然功能用起來其實合理，但我看了一下，還是忍不住說： 「這和設計稿完全不一樣⋯⋯」 見字如面。即使遠端工作看不到那位 QA 實際的表情，但他的訊息裡透露著一種我非常熟悉的無奈： 「還是得和設計稿一樣嗎⋯⋯那你去問一下吧」 那一瞬間，我才忽然意識到，原來大家都會有一樣的痛苦。 我們都知道不一樣就要確認，但有時候知道理論上要問，但我現在真的不想成為那個又去煩人的人。 我默默的非常懂，於是我去幫他追了。 我去問 UI/UX 和 PM：這個差異其實不太影響使用體驗，我們是不是可以先不修？ - 以前的我真的會想： 「為什麼我看到 minor bug 會這麼糾結？」 「我是不是太怕麻煩別人？」 「我是不是不夠強勢？」 「我是不是不適合當 QA？」 「正常 QA 應該看到不一樣就直接開 bug 吧？」 但在開始和另一位 QA 密切合作後，我才發現：原來大家心裡都會跑這些東西。 也是在看到別人有一樣的掙扎時，我才反過來理解到，我原本以為這些想法代表自己太脆弱，但其實，這可能是一種 risk-based thinking。 成熟...

如題，這篇是在說，不分手動與自動，可能是成熟團隊的結果，而不是起點。 ➼ 很多很猛的團隊不分手動和自動⋯⋯ 沒錯，不少成熟的測試團隊，其實不太會把手動測試和自動化測試劃分成兩種職位，而是要求團隊成員都具備一定的自動化、開發能力，依照需求去做不同的測試工作。 也因此，有些測試團隊在成立的初期，似乎就設定了一個目標：「不分手動和自動」。 這在產品穩定發展、大家能平平順順覆蓋核心場景時，其實都沒什麼問題，但是有些產品可能迎來幾次爆發式的成長，或是過去太順了，一直疏於建立自動化測試，終於有一天就掉進了回歸和手動的泥沼。 我後來覺得，如果今天的目標是「救一個已經陷入測試泥沼的團隊」，明確區分手動與自動，可能是一個有效的做法。 ➼ 先 align 一下認知 手動與自動化測試，本質上都是「測試」這一件事，不過它們分別適合產品與功能的不同階段。 手動測試比較適合負責緊急、零碎、現階段變動較大的工作，例如新功能初期的驗證、需要複雜裝置或網路設定等情境，以及需要一個真實的人類，根據實際狀況判斷「這個功能到底好不好」。 而自動化測試則適合保護關鍵業務邏輯、核心功能、CI/CD 中的 smoke test、覆蓋已經穩定的功能 E2E 流程與回歸測試；在功能開發初期，也可以從核心的 API 邏輯介入。 ➼ 掉進回歸、手動的泥沼 舉兩個我實際遇過的例子。 案例1 團隊為了推動自動化，把自動化測試的人員分散進各個 scrum team，希望每個人都能同時負責新功能的手動測試與自動化。 理想上，這應該會讓自動化更貼近產品。 但實際上，新功能一個接一個進來，手動測試有明確的時程壓力，自動化卻變成「有空再做」。最後不是自動化的人沒有能力做，而是根本沒有時間做。 久而久之，自動化工作開始不斷延期，原本負責自動化的人逐漸失去發揮空間。甚至由於被大量的手動測試工作消耗，選擇離開。 案例2 測試團隊的招募策略是廣招 Staff 等級、擁有很強工程能力的測試進來。 照理來說，這應該會發展成有完整可靠的自動化測試的團隊。 但結果卻是大家每天都忙著手動測試新功能。 因為沒有專門的人承接那些緊急、零碎、需要人工判斷的測試工作，所以每個人都被拉進手動測試的泥沼裡。最後反而變成一個很諷刺的狀況： 一群很會寫程式、也知道應該做自動化的人，卻沒有建立自動化測試。 「所有人都會自動化」和「團隊真的有能力持續建立自動化」，其實是...