本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 28 篇。
週會上，主管盯著一個 AI 生出來的測試案例說：
「這一個 test case 怎麼有六個預期結果？而且裡面塞滿 banner、modal 這種中英夾雜的詞，讀起來很痛苦。AI 寫的案例，怎麼反而讓人看不懂了？」
我當時沒說話。因為我自己前幾天也被一個詞卡住三秒——skeleton loading。
我做了幾年 QA，跑過 API、debug 過 SQL、追過 race condition。然後被一個前端的載入狀態名詞卡住。
Day 17 我講過實習時讀不懂規格裡的區塊鏈術語，以為是自己不夠格。
這次一模一樣，只是講話的換成 AI。
而且我的第一反應也一樣：覺得是自己的問題，不好意思問。
實習的時候我的反應是回去自己偷偷查。
這次我做的是另一件事：我把它列成一張表。
因為我發現這不是零星的幾個詞，是一整塊系統性的空缺。AI 之所以會用這些詞，是因為它讀的是前端設計的語料。那套語言存在，只是沒有人負責把它翻譯給 QA。
所以缺的不是我的努力，是一份對照表。
關鍵不在定義。定義 Google 就有。
關鍵在每個詞後面那句「所以我該怎麼測它」。我把每個詞拆成兩個維度：正常操作下的行為，以及邊界和異常下的防禦。
舉幾個：
Skeleton loading：載入時先顯示灰色骨架而不是空白或轉圈。正常維度：骨架的形狀要跟真實內容對得上，不能跳版。異常維度：載入失敗的時候骨架會不會一直停在那裡，變成假的載入中。
Optimistic UI：先假設操作會成功，畫面立刻更新，等後端回應再修正。正常維度：更新是不是即時的。異常維度：後端失敗的時候，畫面有沒有正確回滾，還是留下一個假的成功狀態。這個維度特別容易被漏掉，而且漏掉的後果是使用者以為他存檔了。
Focus trap：彈窗打開時，鍵盤焦點應該被鎖在彈窗內。正常維度：Tab 鍵會不會跑到背景去。異常維度：彈窗關掉之後，焦點有沒有回到原來的位置。這是無障礙的基本要求，而且純用滑鼠測永遠測不到。
Toast：短暫出現又自動消失的提示。異常維度：多個 toast 同時出現會不會疊在一起、會不會蓋住操作區。這個我實際踩過，Day 23 那個覆蓋整個畫面的東西是同一家族的問題。
我一開始做這張表是為了看懂 AI 寫的東西。
後來發現它更好的用途是拿去要求 AI。
當我知道 optimistic UI 有回滾這個維度，我的 prompt 就會變成「這個功能用了 optimistic UI，請把後端失敗時的回滾情境也列進來」。
在那之前，我只能被動接受它給的六個預期結果，然後覺得讀起來很累。
這是個位置的差別。看不懂的時候我是讀者，看得懂之後我是出題的人。
這張表是我自己整理的，維護的人也是我。
它跟 Day 17 那份新人補充文件的命運一樣：沒有人要求我做，做了不會出現在考績上，而我不做了它就會過期。
我只是這次做得比較甘願，因為它同時解決了我自己每天的問題。
AI 的產出裡出現一個你不懂的詞的時候，不要略過它，也不要只查定義。
查完之後多做一件事：寫下「所以這個東西該怎麼測」。
而且至少寫兩行——正常的時候怎麼測，壞掉的時候怎麼測。
累積十幾個之後你會發現，你手上多的不是一份詞彙表，是一份可以拿去要求 AI 的檢查清單。
明天聊：那兩天我一組一組點篩選條件，點到發現一件事。
iThome鐵人賽
看影片追技術