測試與除錯：客戶案子的品質關卡

婚紗不是拍照那天才第一次穿 比喻：試穿。不合身的地方，要在試衣間裡發現，不是在婚禮現場。 客戶案子的測試也一樣。上線那天才第一次讓使用者碰到系統，你就是在婚禮現場試衣服。 為什麼客戶案子要測得比自家產品嚴 自家產品出問題，你可以當天修、發個公告、下一版補上。客戶案子不一樣： ・你不在現場。他們發現問題時，你可能在另一個客戶那裡 ・他們沒有工程師能先判斷這是不是真的壞了 ・壞掉的成本是信任，不是一個 bug ticket 所以測試在這裡不只是品質手段，它是風險管理。 三層測試 層　·　誰做　·　測什麼 功能測試　·　你　·　每個功能自己會不會動 端到端測試　·　你　·　跨系統走完整流程，含第 10 集的對帳 UAT　·　客戶的使用者　·　在真實情境下，這東西能不能用 前兩層是工程紀律，這一集的重點在第三層。 UAT（User Acceptance Test，使用者接受度測試）的定義很簡單：讓真正會用的人，用真實的情境，自己走一遍。 UAT 設計的四個要素 1. 寫情境劇本，不是功能清單 功能清單（沒用）　·　情境劇本（有用） 測試報價單新增功能　·　幫老客戶某某公司開一張含三項產品的報價單，其中一項給九折，送主管核准 測試權限設定　·　用業務帳號登入，確認看不到其他業務的客戶 功能清單測的是「程式有沒有壞」，情境劇本測的是「這套東西符不符合他們真實的工作方式」。後者才會抓到需求層級的問題。 2. 用他們自己的真實資料 去識別化之後的真實資料（第 09 集）。假資料永遠太乾淨，測不出那些「我們有一個客戶名字裡有括號」的情況。 3. 讓使用者自己操作 不要幫他點。 這是整集最重要的一句話。 你坐在旁邊，手很癢，看到他找不到按鈕就想伸手。忍住。他卡住的那三十秒，就是這次 UAT 最有價值的資訊——因為上線後你不會在旁邊。 4. 記錄「卡住」的地方 準備一欄專門記這個：他在哪一步停下來、猶豫了多久、最後怎麼解決的。這一欄比任何錯誤回報都準確地告訴你介面哪裡有問題。 帶客戶跑 UAT 的三個原則 1. 挑實際會用的人，不是主管。 主管會...