《葵花寶典》的第一句話是「欲練神功，揮劍自宮」。這暗示著要練成此武功，必須放下世俗的慾望，才能真正參悟天人合一的道理。在這裡，我們不需要犧牲這麼大，但如果要掌握 AI 時代的開發心法，我們必須重新建立思維，放棄原本的流程，將 AI 導入原本的開發流程，並且調整成 AI 原生的開發方式。

傳統的自動化測試方式：從 ATDD 到敏捷測試

在 AI 時代來臨前，我們的開發流程，即便已經擁抱了 ATDD (驗收測試驅動開發) 和敏捷測試這些現代方法論，但還是有個核心痛點：撰寫測試程式碼需要花費大量時間。

• 在 ATDD 的流程中，我們透過與產品經理討論來產出驗收測試案例（通常是 Gherkin 語法的 .feature 檔案）。這段人與人溝通的過程至關重要，但要把這些自然語言描述轉換為可執行的程式碼，卻是個耗時費力的過程，需要測試人員手動編寫每一行測試腳本。
• 在敏捷測試中，我們強調盡早測試、不斷回饋，但程式碼的實際編寫仍然是主要的瓶頸。對許多追求 0-day release (零日發布) 的團隊來說，要做到開發和測試同步完成，除了前期的溝通討論，撰寫測試程式碼的速度也必須跟上極致的效率要求。

我認為，這種方式最大的困難點，就是我們是否能跟上開發的節奏。隨著 AI 的進步，或許我們可以讓 AI 協助我們撰寫測試程式碼，藉此突破這個效率瓶頸。

使用 AI 原生的開發方式

既然傳統方法有其瓶頸，那麼我們就得找到另一條路。我發現，現在一種全新的自動化測試模式正在浮現，我將其稱為「AI 原生測試」。在這個流程中，AI 不再只是單純的輔助工具，而是測試流程的核心驅動力。

這個流程是這樣的：

• 意念先行，招式自成：我們不再先寫程式碼，而是先用自然語言描述測試意圖。接著，讓 AI 根據我們的描述，自動生成測試腳本的骨架、多樣化的測試案例，甚至是符合需求的測試資料。這段過程，就像是《葵花寶典》的心法，意念一動，招式自成。
• 用設計模式規範 AI：光讓 AI 生成程式碼還不夠，如果它寫出的是一堆難以維護的爛程式碼，那也沒有意義。這時，我們前幾天學到的 Design Pattern (設計模式) 就派上用場了。我們可以明確要求 AI，根據我們團隊約定好的模式來撰寫程式碼。例如，要求它使用 Page Object Model 來組織頁面元素與動作，或是使用 Data-Driven Testing 的方式來處理多組測試資料。這些模式成了我們與 AI 之間的共同語言，確保 AI 產出的程式碼不僅功能正確，而且具備高可讀性與可維護性。
• 人工審核，補足測試覆蓋率：在 AI 生成腳本後，我們的工作重心從「編寫」轉變為「閱讀程式碼」。這包含兩個層面：首先是程式碼審核，讓 AI 產出的程式碼符合我們的預期與風格，並進行必要的重構。更重要的是，我們還可以使用 AI。給它我們已有的測試情境，讓它協助分析並找出可能遺漏的邊界條件、負向測試或極端值。這大大彌補了每個測試人員可能存在的盲點，幫助我們更完整地涵蓋測試範圍。
• 持續進化，內功精進：這是我認為最重要的環節。我們對 AI 的掌握不是一次性的，而是一個不斷學習與調整的過程。我們需要持續優化我們的 Chat Mode Prompt 和 Best Practice，就像不斷打磨自己的內功心法一樣。透過紀錄與分享，讓 AI 能夠產出如同我們親手寫的程式碼和風格，使團隊的協作效率更上一層樓。

欲練此功，必先「自宮」

在 AI 時代，我們討論的「欲練此功，必先自宮」，犧牲的並不是思考與溝通的能力，而是將思考結果轉換成繁瑣程式碼的過程。這讓你的角色更純粹、更專注於使用者體驗與測試策略，這也正是測試工程師最寶貴的價值所在。不過，AI 技術在自動化測試領域仍然正在探索其可能性，是否真的能夠完成這麼理想的測試，接下來的幾天，我們會逐步實驗是否能夠完成以往的測試任務還是仍然還有侷限性。