前言
初次見面！我是 QA 工程師 SA！
我作為 QA 事業部的代表，每天都在與軟體品質正面對話。
突然問大家一個問題：你們有過「理所當然的工作」在某一天突然整個改變的經驗嗎？
我有。而且，這還是幾個月前的事。
以前手動作業的故事
在我加入這個團隊之前，我待的是一個手動建立測試情境、手動執行測試的團隊。
我們會把測試案例一項一項寫到 Excel 或試算表裡，實際操作瀏覽器，一邊看一邊確認——就是這樣的世界。甚至連情境測試這個概念都不存在，整個現場都以「人來操作」為前提。
之後我調到現在的團隊，第一次接觸到了 Playwright。
能把 E2E 測試當作程式碼來用 Playwright 管理，光是這點就讓我覺得「這環境也太厲害了」，但在當時，還是有一部分工作得交給人來做。
測試結束後，打開瀏覽器，找 GitHub 的 issue，寫留言，然後把狀態更新成 done。
雖然很瑣碎、很花時間，但我當時覺得「這就是工作」。
Claude Code × GitHub 串接帶來的改變
轉捩點是，我遇見了 Claude Code。
Claude Code 是一個可以讓 AI 撰寫程式碼、操作終端機的工具。把它和 GitHub 串接之後，整個世界都變了。
現在，我只要用自然語言對 AI 下指令——
- Playwright 測試會自動執行
- 測試結果會自動留言到 GitHub 的 issue
- 狀態會自動變成 done
這整個流程，完全不需要人介入就能完成。
第一次跑起來的時候，老實說我笑出來了。「欸，這樣真的能動喔？」那種感覺到現在我都還忘不了。
從 QA 現場看到的 AI 應用真心話
當然，一開始並不是「太棒了！超讚！」這樣的反應。
「AI 真的能執行測試、守住品質嗎？」「如果它做出非預期的行為，誰要負責？」——這些不安，不只是團隊裡有，我自己心裡也有。
實際用下來，AI 並不是萬能的。如果指令下得不夠清楚，它也可能不會按照預期行動。作為前提的設計，以及 QA 該如何判斷的標準，終究還是必須由人來掌握。
但反過來說，我也感受到，人類該做的工作的解析度變高了。把單純重複的工作交給 AI，我們就能更專注在「該測什麼」「哪裡有風險」這些本質性的思考上。
AI 時代不能落後
作為 QA 事業部的代表，這件事我可以很明確地說。
AI 的浪潮，確實已經來到 QA 現場了。
實際上，能熟練運用 AI 的 QA 工程師和不會用 AI 的 QA 工程師之間，已經開始出現很大的差距了。這不是危言聳聽，而是我在現場親身感受到的真實情況。
「這跟我的工作沒關係」「還早得很」——當你這樣想的時候，現場其實已經悄悄在改變了。工具在變，需求的技能在變，工作的定義本身也在改變。
而且我甚至覺得，這樣的時代也許真的會到來：
「不會用 AI 的工程師，已經不算工程師」
聽起來很誇張嗎？但我是真的認為，這是離我們不遠的未來。既然如此，哪有不搭上這波大浪的選擇！！
QA 工程師正從那種一邊點點點操作畫面、一邊執行測試的時代，邁入全新的階段！！
不需要害怕。先試一件小事看看吧。做一個小小的自動化就好。只要對 AI 下達一個指令就好。那種「真的跑起來了」的體驗，肯定會成為下一步的起點。
結語——其實這篇文章，也是和 AI 一起寫的
最後，我要坦白一件事。
這篇文章，其實是和 AI 共同創作的。
從構思架構到整理文章內容，我都是一邊和 AI 對話一邊完成的。明明在談「測試自動化」的話題，結果就連寫文章這件事本身，也讓 AI 參與進來了。
老實說，我自己覺得還挺有趣的。
這就是現在的現實。AI 已經不只進入寫程式的領域，甚至也進入了「思考」和「傳達」的領域。
所以我才會這麼想：
AI 時代不能落後——這不是別人的事，而是你的事。
感謝你讀到最後！
原文出處：https://qiita.com/a_sato_JQIT/items/a82fccf6d52c05156384
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
