手機版表單錯誤狀態 QA：不是只看能不能送出
手機版表單最常被低估的測試，不是「送出成功」那一條 happy path，而是使用者填錯、漏填、切換輸入法、被鍵盤擋住、返回上一頁之後，畫面是否還能清楚引導他完成動作。
很多網站的聯絡表單、下載表單、報名表單看起來都能送出；但一旦使用者漏掉必填欄位，錯誤訊息可能跑到畫面外、按鈕被鍵盤遮住、欄位 focus 不明顯，或是錯誤後把原本輸入的資料清空。這些細節不一定會讓工程 build 失敗，卻會讓轉換率慢慢流失。
我會先把表單流程拆成三段
手機版 QA 不要只測最後按鈕，先把流程拆成三段：
- 填寫前：欄位標籤、placeholder、必填提示是否清楚。
- 填寫中：鍵盤類型、focus 樣式、欄位間距、捲動位置是否正常。
- 送出後：錯誤訊息、成功訊息、資料回填與追蹤事件是否一致。
這樣拆的好處是可以快速定位問題：如果使用者不知道欄位要填什麼，是填寫前的資訊架構問題；如果鍵盤一打開就看不到送出按鈕，是填寫中的 viewport 問題；如果送出錯誤後資料消失，則是狀態管理或後端驗證回傳處理問題。
錯誤訊息要離欄位夠近
表單錯誤最常見的壞體驗，是錯誤訊息只出現在頁面最上方，使用者卻停在頁面下方看不到。手機螢幕高度有限，錯誤訊息應該同時滿足兩件事：
- 欄位旁邊或下方有清楚訊息，讓使用者知道哪裡錯。
- 送出後若第一個錯誤欄位在畫面外，頁面能捲到合理位置。
文字也不要只寫「格式錯誤」。比較好的提示是「請輸入有效 Email，例如 hello@example.com」或「電話至少需要 10 碼」。這不是文案裝飾，而是減少使用者重試成本。
手機鍵盤會改變真正可見的畫面
桌機測試表單時，畫面高度通常足夠；手機上打開鍵盤後，真正可見的區域會變小。若表單底部有 sticky CTA、聊天浮窗或 cookie banner，送出按鈕就可能被擋住。
我會實際用 390px 左右的 viewport 測幾個狀態：
空白表單 → 點第一個欄位 → 輸入錯誤格式 → 送出 → 修正 → 成功
重點不是截一張漂亮圖，而是確認每一步都還能看到目前欄位、錯誤訊息與下一個可操作按鈕。若欄位很多，也要測中段欄位與最後一個欄位，因為問題常出現在表單下半部。
focus-visible 與 touch target 不能只靠顏色
手機表單也需要可見的 focus 狀態。雖然手指操作不像鍵盤 tab 那麼明顯，但很多使用者會搭配外接鍵盤、螢幕閱讀器或瀏覽器輔助功能；再加上錯誤狀態本身也需要清楚標示。
我會檢查：
- 可點擊元素是否至少接近 44px 高。
- focus 樣式是否不是只靠極淡顏色。
- 錯誤狀態是否同時有文字、邊框或 icon，而不是只靠紅色。
- label 是否真的綁定到 input，點 label 能把焦點帶到欄位。
這些細節會影響可及性，也會影響一般使用者在小螢幕上的操作穩定度。
錯誤後不要清空使用者已填資料
表單最傷人的情境之一，是使用者填完很長的內容，送出後因為某個欄位錯誤，整張表單被清空。即使技術上可以解釋為驗證失敗或 session 過期，使用者的感受仍然是「網站把我的內容吃掉」。
如果欄位涉及檔案上傳或驗證碼，至少要在畫面上說清楚哪些資料需要重新選擇；文字欄位、Email、電話、備註這類資料，原則上應該保留。
最後要看事件追蹤是不是把錯誤當成功
網站經營角度還要多看一層：表單追蹤事件有沒有把「按了送出」誤當成「送出成功」。如果 analytics 只記錄 button click，就會高估轉換；比較好的做法是分成：
form_submit_click
form_validation_error
form_submit_success
form_submit_failed
這樣日後看到表單轉換下降，才知道是入口流量不足、錯誤率升高、後端失敗，還是使用者在手機版卡住。
UCAMC 之後維護表單會優先看這幾件事
每次調整聯絡、報名、下載或訂閱表單時，我會把手機版錯誤流程列為必要驗收，而不是等到使用者回報才補測。最小可行驗收可以很簡單：
- 390px 手機 viewport 跑一次空白送出。
- 確認第一個錯誤欄位與錯誤訊息可見。
- 修正欄位後資料沒有被清空。
- CTA 沒有被鍵盤或浮動元件擋住。
- 成功與失敗事件分開記錄。
這類 QA 看起來不是大改版，卻是長期網站經營最需要累積的細節。表單不是只有功能元件，也是使用者願不願意把資料交給網站的信任入口。