本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 18 篇。
那支腳本常常壞。而且壞的方式很固定：功能好好的，畫面看起來也一樣，但腳本找不到它要點的那個東西。
通常我們這邊遇到的情況就是東西根本沒有 ID有了 ID你同一個功能的按鈕它在不同的頁面ID 有時候不一樣畢竟它裝的樓梯都不一樣所以有時候只能靠位置或者文字去抓或者是用很不穩定的方式去抓過一過就壞掉了
我那時候真心相信這是我的技術問題。
所以我加了備援，也就是AI常說的fallback：先用 id 找，找不到就用文字找，再找不到就用相對位置。我把定位邏輯包成函式，出錯的時候自動重試。腳本確實變得比較耐撞。
然後下一次改版，它又壞在別的地方。
我修了很久才意識到一件事：這條路沒有盡頭。我每一次都在把同一個問題往後推，而不是解決它。
後來做跨 App 的自動化，同一個問題放大了。
用設計系統做出來的畫面，同一套元件會被好幾個 App 共用。明明長得幾乎一樣的搜尋按鈕，在這個 App 的 id 是一組，在那個 App 又是另一組。我得重新推敲一次每個元素怎麼定位。
我一開始還是用老方法想：locator 沒寫好、該封裝得更聰明。
直到我去問了做那個元件的工程師，能不能幫我加一個測試用的識別碼。
他說：這個元件太抽象了，我不知道產品要拿它做什麼。
那句話一字不差，而且他完全沒有錯。
設計系統的元件是無語義的通用插槽。它是一個可以放圖片、可以設定點擊去哪裡的殼。做這個殼的人不知道它會被當成搜尋按鈕還是通知鈴鐺。
語義是誰給的？是產品端在組裝畫面的時候才決定的。同一個殼，這裡當搜尋，那裡當篩選。
所以「叫做元件的人加一個 testID」是搞錯了層級。
一個識別碼像 home.search，編碼的是「這個東西是做什麼用的」。那是意圖。而意圖只存在於「有人決定了用途」的那一層。
把它蓋在別的層級，只會落入兩種下場：蓋的人沒有那個資訊，或者資訊被複製一份、然後開始漂移。
| 放在哪一層 | 誰來蓋 | 會怎麼壞 |
|---|---|---|
| 不蓋（現況） | 沒人，測試靠結構 id、位置、文字硬抓 | id 由實作決定而不由用途決定，維護成本隨 App 數乘版本數成長 |
| 元件層 | 做元件的工程師 | 他不知道用途，只給得出 imageSlot1。那是把亂碼換個名字 |
| 測試層 | QA 自己 | 能動，但對應關係住在 QA 的檔案裡。每個新 App 要重推一次，而且會漂移 |
| 組裝層 | 產品端 | 唯一同時知道用途、是單一真相來源、而且會自動散佈到每個 App 的地方 |
代價講白一點：這不是「沒有識別碼」的問題。你是把「語義對應到元件」這件事，從一份由產品端維護、會自動散佈的真相來源，降級成 QA 逐個 App、逐個版本手動重建的維護稅。而這筆稅會隨著 App 數量和改版頻率複利成長。
組裝的時候，每個元件實例多一個欄位，讓產品端填用途。渲染的時候，這個欄位存在就把它設成元素的測試標籤。測試端就用這個標籤定位，跨 App、跨版本都穩。
這個方向之所以推得動，是因為它對每一邊的要求都很低。不要求做元件的人懂語義，他們本來就不懂。不要求 QA 去讀原始碼，QA 只消費渲染後的標籤。產品端只是把本來腦子裡就決定好的用途，寫成一個欄位。
技術上，這是渲染引擎的一次性改動。
但它只有在產品端用一致的詞彙時才成立。
如果一邊填「搜尋」、另一邊填「search_btn」，同一個邏輯元件還是會分岔。
所以真正的成本從來不是加一個欄位。是這兩個問題：誰維護那份共用詞彙表？產品端憑什麼要遵守它？
這兩句話，跟這一週前面三天問的是同一句。Day 15 那個沒人決定過的 bug 預設、bug 管理不在誰的 KPI 上、那份沒人維護的文件——全部都是「沒有人被指定要負這個責」。
只是這一篇的版本更難一點。前面三個是沒有人接。這一個有人接得了，但那個人不知道自己手上握著一個測試會用到的決策。
這篇我最想講的其實是這個轉變。
實習的時候，腳本壞掉，我的反應是「我 locator 寫得不夠好」。現在同一件事發生，我的反應是「這個定位困難的根，長在組織的哪一層」。
看得出來，是有價值的。但看得出來不等於改得動。
建立一份跨 App 的共用詞彙表、讓產品端在組裝時填一個欄位，這是流程變更，要動到兩個部門的工作方式。那個決定不在我這裡。
我能做的只有一件事：把提案縮到小得不能再小。 不談全面標準化，只挑「每個 App 一定都會有」的那幾個——首頁、搜尋、通知、更多、返回，五到八個就好。App 專屬的元件維持各自定位，不強求統一。
一開始就想規範全部，就推不動。這是我從那份只會變長的回歸清單學到的同一件事：你要的不是一個完美的方案，是一個小到有人願意點頭的方案。
腳本又因為定位壞掉的時候，先別急著把 locator 寫得更聰明。
問一句：這個元素「是什麼用途」這件事，是誰決定的？
如果答案是某個人、而那個人不是你，那你手上的就不是技術問題。你只是在替一個沒有被記錄下來的決定，手工重建它的紀錄。
你未必改得動那一層。但你可以把你正在付的那筆維護稅算出來，講給決定的人聽。
明天聊：理論上最好的那個方案，為什麼在組織裡跑不動。
iThome鐵人賽
看影片追技術