上線前的檢查，要在別人的裝置上開過一次才算結束

把這個產品從頭用到尾的只有一個人

離上線只剩幾天。功能齊了，設計也確認完了，版本也放上伺服器了，看起來只差打開。可是從第一個畫面一路走到最後一個畫面的，到現在還是只有做它的那個人。

做的人走的是自己鋪的路。註冊表單裡填的是慣用的那組值，走到付款頁的順序也是自己排的那一版。這條路走過幾十次，當然不會卡。問題是第一批使用者不從這條路來。他們從搜尋結果直接落在內頁，註冊到一半把視窗關掉，一個小時後再回來，付款途中按了瀏覽器的上一頁。

所以上線前的檢查，與其說是勾掉幾條，不如說是誰走過哪條路。把清單拉長，通常不如把清單上沒有的那條路走一次。

接成一條線走完

一個畫面一個畫面分開看，最後會得到一種狀態：每個畫面都沒問題，服務卻用不了。使用者做的事本來就不是一個畫面，而是從進來到把事情辦完的一條連續的線。把那條線不中斷地走一次：註冊、收驗證信、登入、加入購物車、付款，再回頭去找剛才那筆紀錄。

會卡住的地方多半不在成功之後，而在失敗之後。卡片被拒、驗證信一直沒來、付款途中按了上一頁、同一個按鈕連按兩下。順利的那條路在開發過程中看過幾十次，失敗的那條路卻常常一次都沒走就上線了。重複成立訂單，或是錢收了卻沒有訂單，就是從這裡長出來的。

帳號也重新開一個。開發時用的帳號早就累積了權限和資料，團隊裡沒有人看過空狀態。今天早上才註冊的人看到的是什麼，只有新帳號回答得了。

寄出去的東西，落地了才算數

畫面上顯示已送出，跟那封信躺在對方的收件匣裡，是兩件不同的事實。聯絡表單、註冊驗證、重設密碼、訂單確認、通知。這些在真的寄到一個真實信箱、而且在那邊被打開之前，都不算確認過。

開發階段通常用只收不寄的測試工具驗證，那種工具根本不會把信送出去。一旦切到真實寄送，寄件網域的驗證就成了關卡。主要的信箱服務這幾年已經把 SPF、DKIM、DMARC 記錄當成寄件網域的前提，少了就進垃圾信，或者直接被退掉。這些記錄握在管網域的人手上，不在寫程式的人手上，所以它們常常是上線之後才被發現。

收的那一端也看一次。如果聯絡表單寄出的信正安靜地堆在負責人的垃圾信匣，那就是表單完全正常，只是詢問永遠到不了。

舊手機、慢網路、沒登入的視窗

做產品的那台機器一定是最新的、螢幕寬的、網路快的，而且早就登入著。把這四件事一次全部打破。用一支用了幾年的實機打開，用無痕視窗從首頁進來，再看網路慢的時候畫面是照什麼順序畫出來的。圖片重的網站，只有在這種條件下才露出本來的樣子。

可見性設定也放在同一輪看。測試環境通常擋著搜尋引擎，那道封鎖跟著上線，網站對人正常打開，在搜尋結果裡卻永遠不出現。反過來也有：測試網址一直開著，同一份內容在兩個地方都連得到。這兩種在畫面上都看不出來，都會在幾週後變成一句為什麼搜不到。

退得回來嗎

再怎麼檢查，總有上線之後才冒出來的東西，所以最後一個問題不是查了什麼，而是有沒有地方可以退。有沒有人知道怎麼退回上一個版本，那件事是幾分鐘做得完還是要花一個下午，如果這次改動碰到資料庫，備份是什麼時候的。

把退不回來的部分另外標出來。畫面和程式碼退回去就沒事，搬移過或刪掉的使用者資料、已經寄出去的信、已經請款成功的付款，退不回來。把這類操作從上線當天挪開，本身就是檢查的一部分。

上線的時間也是個決定。禮拜五傍晚上線，出了事沒有人在。異常通知要在上線之前打開，因為第一天的差別就在於，故障是自己的監控先告訴你，還是客人打電話告訴你。

「不能用」還不是檢查結果

回報如果只有一句付款壞掉了，修的人就得從零開始重現。點了什麼、照什麼順序點，哪台裝置哪個瀏覽器，哪個帳號什麼時候，畫面上出現了什麼。這四樣附上去，原因通常當場就收得窄；沒有，光重現就吃掉一天。一段螢幕錄影是這四樣最快的版本。

檢查的人和修的人不是同一個人，就把這個格式先講好。上線前那幾天正是問題集中冒出來的時候，沒整理過的回報堆起來，修的時間就變成讀的時間。

陌生人的位置我們來坐

Weple 的上線前品質檢查，就是替你走一遍團隊沒有理由去走的那些路。把不能出事的流程做成真實瀏覽器執行的自動化測試，換著瀏覽器和螢幕尺寸再跑一輪，並且刻意放進真實使用才會出現的條件：空值、超長輸入、慢網路、連點、上一頁。不需要儲存庫權限，一個開得起來的網址加一組測試帳號就夠了。我們接哪些事、用什麼單位計價，寫在價格說明裡。開發還沒做完就找我們也可以，而且通常更好，因為查出來的東西還有時間改。發現的問題會附上重現步驟、螢幕錄影和嚴重程度交回去，直接轉給工程師就行。