軟體測試 — 如何推動團隊的測試文化?

我們分別談了軟體測試金字塔、測試驅動開發、實務上寫測試時該注意的事項，這一期我們將把視角轉換到資深工程師資深工程師，假如今天身為資深工程師，想要在團隊中推動測試，該如何能更有效做好?

為什麼團隊不寫測試?

在談推動測試前，我們得先探討為什麼團隊不寫測試? 畢竟相信多數人都會同意軟體測試有一定的好處，只是既然有這些好處，為什麼不寫呢?

以下我們探討三個最常見的原因：

• 不知道該怎麼寫測試：有些團隊成員不知道該怎麼寫測試，或是不知道在測試時可以搭配的相關方法，因為不知道所以就沒有寫。
• 沒時間寫測試：過去很多開發者會被怨沒時間寫測試，因為寫測試花額外時間，會讓功能來不及上線，而公司把優先順序排在功能開發，導致最後只能犧牲沒花時間在測試上。
• 認為測試是 QA 的工作：測試不只是寫測試本身，而是軟體設計與程式實作的一部分，唯有。目前業界越來越趨向，QA 的角色會是協助團隊導入測試工具 (例如幫忙建立模擬測試伺服器 Mock Testing Server) 以及導入測試的最佳實踐，但是測試本身仍會有開發者來寫

以下我們會針對上面這幾點，分別討論身為資深工程師，可以如何幫助團隊克服。假如你目前所在的團隊，也有遇到這些問題，即使你的職稱不是資深工程師，仍可以主動跳出來協助解決。

如何解決團隊不會寫測試的問題?

首先來談團隊不會寫測試這點。多數開發者對於軟體測試都有一定概念，但不一定會寫測試，或者只會最基本的測試。然而，要有效在團隊中推動測試，一個重要的點在於，要讓團隊成員對測試有所掌握，這包含對於測試的概念、方法、工具都有所掌握。畢竟假如團隊成員連怎麼寫測試都不會，這樣要求寫測試會變得很困難。

過去在業界中最有名的導入測試案例之一，是當年 Google 透過在工程師經常會經過的地方 (例如廁所) 加上各種測試相關技巧的說明，讓大家能夠對於測試的掌握度更高。後來因為推動的很成功，甚至有 ToT (Testing on the Toilet) 一詞專門來描述這件事。

具體來說，Google 早年時，公司整體對於軟體測試的掌握並不高，軟體測試並沒有到很盛行。不過 Google 內有一群對軟體測試很有熱忱的工程師，他們嘗試用各種方式協助改善這件事。而在廁所貼測試相關知識的想法，當初是在會議中被半開玩笑地提出，而其中有位工程師後來就直接去貼。

貼完後工程師們在上廁所時，不得不看到眼前的測試相關知識分享，包含依賴注入 (dependency injection)、各類測試時可以用的技巧、測試覆蓋率的衡量、程式怎麼寫可以更容易測試等等。

在這群有熱忱的工程師，直接這麼做好，收到最多的抱怨，不是「怎麼有人在廁所貼這種東西」，而是「這個內容怎麼這麼久還沒更新」，許多工程師的抱怨是自己已經連續一週上廁所時，都是讀同一個測試相關知識，他想要讀新的知識點。從這個抱怨可以看到這個小嘗試有多成功。

如果你對 Google 當時做的廁所測試內容感興趣，詳細的內容可以在《Software Engineering at Google》 一書中讀到，或是很推薦當年參與推動的前 Google 工程師 Mike Bland 寫的部落格文《Testing on the Toilet》。

回到 Google 當時這個嘗試帶給我們的啟發點，在於要教會團隊成員測試，可以把測試的概念，拆解成一個個小的知識點，用淺顯的方式分享給團隊成員，當測試知識變得夠小、夠好消化，團隊自然能輕易學會測試。

這邊最關鍵的，是身為團隊的領導者，能否排除團隊在嘗試某個新東西時的阻礙? 當讓做某件事變得越簡單，就越容易導入，而團隊領導者的任務之一，就是讓團隊成員做這件事情時能夠很簡單。

雖然在廁所推動測試聽起來很簡單，但實際做起來則不容易，因為這群推動 Google 測試文化的工程師，需要把許多不那麼平易近人的概念，寫得很簡單，甚至簡單到大家上廁所時看就能吸收。與此同時，他們也需要花很多時間去釐清、統一詞彙 (以測試來說 fake、mock、stub 等詞有點接近但又不同，需要有個清楚定義)。

進一步來說，當時這群工程師，有了這個半開玩笑的想法後，就直接去廁所貼，這體現一種行動趨向 (bias toward action) 的文化，同時意味著組織是允許有嘗試的空間。回到團隊領導者的角度看，去辨別出對策是主題有熱情的人，給這些人空間去推動，這會是很關鍵的。

如何解決沒時間寫測試的問題?

接著來討論，如何解決團隊因為沒時間寫測試，所以不寫測試的問題。首先，作為資深工程師，可以試著去跟工程經理、產品經理溝通測試的重要性，去爭取把部分時間移來寫測試。

但與此同時，更具體可以做的事情是，讓寫測試不用花很多時間。在給定測試能帶來效益的狀況下，讓小測試只需用花很少的時間，就能更有效說服管理層，讓團隊能花少少的時間來寫測試。

至於該如何做到呢? 身位資深工程師，可以把測試所需要的基礎都先預備好，讓寫測試、跑測試變得很簡單，甚至是比寫程式、跑程式還簡單，這樣寫測試就能變得很快。

具體來說可以做以下幾件事：

• 建置好所需的測試工具： 舉例來說，假如團隊要導入 E2E 測試，資深工程師可以把 Playwright 搭配 Chromatic 的環境與流程都建置好，讓團隊成員只需用寫測試就好，不用去擔心各種環境問題。
• 把 CI 串好： 除了設置好工具，也可以把 CI 也串好，讓測試自然地成為開發過程中的一環，讓團隊成員把程式碼推到遠端分之後，測試就會自動跑起來、測試覆蓋率也會自動計算，甚至生成面板、產出報表，讓團隊能輕易地檢視目前的狀況。
• 導入 AI 工具到寫測試當中： 由於 AI 工具近年來的蓬勃發展，目前業界逐漸出現導入 AI 工具到寫測試當中。舉例來說，目前比較多人用的 Cursor 即是可以導入的工具之一。這邊推薦的方式，是把產品規格 (PRD) 的內容，或者某個功能的通過標準 (包含預期要有的 happy path 與必須特別處理的 edge case) 作為輸入傳給 AI 工具，然後請 AI 工具根據這些案例，來生成測試的程式碼。

在我們過去實際導入的經驗，當團隊不用為環境問題煩惱，可以直接就開始寫測試，這時搭配了 AI 工具，能讓寫測試變得非常非常輕鬆快速。

閱讀更多

在了解最基本如何推動測試的要點後，接著我們會進一步談為什麼要把測試左移、為什麼不推薦過度追求測試覆蓋率。 這些點我們在 E+ 成長計畫的主題文都有更詳細談到，推薦感興趣的讀者閱讀。

本文為 E+ 成長計畫的深度內容，截取段落開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。