今天的故事

Day 24，PawPal 終於真的上線了。

網址可以打開。

網站也沒有直接跳出什麼嚴重錯誤。

那時候我的第一個想法其實很單純：

能開、沒有報錯，應該差不多完成了吧？

剛看到網站真的出現在網路上時，我確實有這種感覺。

但等興奮慢慢退下來，我才開始想到另一件事：

等一下，那我們到底要怎麼確認這個網站真的沒問題？

我知道網站上線後還是要測。

問題是，當時的我其實不知道：

一個網站所謂的「完整驗收」，到底要驗哪些東西？

也是從這時候開始，我第一次發現：

網站能打開，和網站真的可以安心交給使用者操作，中間其實還有一段距離。

網站能開，我原本真的以為差不多完成了

以前在開發功能時，我最常確認的事情很直接。

例如：

按鈕能不能按？

畫面有沒有出來？

API 有沒有成功？

有沒有看到明顯 Error？

只要這些東西看起來正常，我很容易就產生一種：

好，這個功能完成了。

的感覺。

但到了專案後期，我們開始重新把整個網站走過一次。

不只是看自己正在做的那個功能。

而是從首頁開始，實際切換頁面、登入、操作功能，再換成手機、平板和電腦去看。

我也會先確認自己負責的功能，再一起看看其他地方。

這時候我才慢慢發現：

有些問題根本不會讓網站壞掉。

網站還是能開。

按鈕也還是能按。

甚至不一定會直接看到明顯的錯誤訊息。

但實際使用起來，就是不對。

第一個讓我印象很深的，是 Sidebar

其中一個很明顯的例子，就是 Sidebar。

PawPal 的 Sidebar 會依照登入狀態，顯示不同的功能內容。

正常情況下，會員登入後，應該看到會員狀態對應的功能。

但在實際走網站流程時，我們曾經遇到：

會員登入
↓
顯示會員 Sidebar
↓
切換到公開頁面
↓
網站還是可以正常操作
↓
Sidebar 卻變回訪客版

這個問題很特別。

因為網站並沒有因此整個壞掉。

頁面也開得起來。

如果只測：

這個頁面能不能開？

可能就會覺得沒有問題。

但如果真的從：

登入
↓
切換頁面
↓
繼續操作

走完整個流程，就會發現：

我明明已經登入了，為什麼 Sidebar 看起來又像沒登入？

這也是我第一次很明顯感受到：

單獨一個頁面正常，不代表整個使用流程就是正常的。

有些畫面，不能只看現在在哪一頁

後來回頭看程式才知道，Sidebar 不只和目前頁面有關，還要一起考慮使用者的登入狀態。

可以用「簡化概念」理解：

頁面狀態
+
登入狀態
↓
Sidebar 顯示內容

這讓我第一次發現，有些問題單獨測一個頁面很難看出來。

一定要真的把：

登入
↓
切頁
↓
繼續操作

整段流程走過一次，才比較容易發現。

另一個問題更奇怪：假資料會先閃一下

除了 Sidebar，我還記得另一個很容易被忽略的問題。

當時在重新整理頁面或切換帳號時，我曾看過原本拿來測試的假資料短暫出現在畫面上，之後才變成真正的寵物資料。

最後看到的資料其實是對的。

但中間會變成：

進入頁面
↓
先看到測試資料
↓
真正資料載入完成
↓
畫面更新
↓
最後結果正確

如果只看最後：

資料是不是正確？

答案可能是：

對。

但如果從使用者角度看整個過程，就會發現：

為什麼剛剛出現了一隻不是我的寵物？

這其實就已經是問題了。

後來從專案紀錄可以確認，歷史上的 petStore 的確曾經放過 mock 寵物作為初始資料，後續也有移除 mock 初始狀態、處理帳號切換與 session 狀態的修正。

但這個問題的主要修正不是我完成的。

對我來說，它更重要的地方反而是：

我是在共同驗收的過程裡，開始注意到「最後結果正確」還不夠。

載入前。

載入中。

載入後。

其實都是使用者會看到的過程。

「會報錯的都是小事，不會報錯的才是最困難的」

那時候我有一個很強烈的感覺：

會報錯的都是小事，不會報錯的才是最困難的。

這不是什麼技術定律。

比較像是我當時做專案後的一個感想。

因為有明顯 Error 時，至少還有一個線索可以開始找。

真正讓我覺得困難的，反而是像 Sidebar 這種問題。

網站沒有整個掛掉。

使用者也還是可以操作。

但實際呈現的狀態就是不合理。

或者像假資料閃現。

最後資料明明是對的，但中間那一下就是怪怪的。

這種問題，如果沒有真的把自己當成使用者重新操作一次，很容易就被漏掉。

所以後來我開始覺得：

沒有看到 Error，不代表真的沒有問題。

我們不是一發現怪怪的地方，就直接開 Issue

當時大家一起驗收時，如果有人發現某個地方怪怪的，也不是馬上就把它當成 Bug。

我們通常會先提出來討論。

例如：

這個狀態是本來就這樣設計嗎？

還是實際操作起來真的不合理？

大家確認之後，如果覺得這確實是一個需要修正的問題，才會正式建立 GitHub Issue。

所以流程比較接近：

發現異常
↓
提出來討論
↓
確認實際使用是否合理
↓
確認這真的是問題
↓
建立 Issue
↓
分工修正
↓
重新測試

這也改變了我原本對 Issue 的想法。

以前我可能會覺得：

有 Bug，就開 Issue。

但後來我才知道，中間其實還有一個很重要的步驟：

先確認我們看到的「異常」，到底是不是不符合預期的行為。

驗收不是最後一天才突然做一次

我們當時並不是等網站全部做完，才第一次開始測試。

平常在開發功能的過程中，本來就會邊做邊測。

只是到了接近完成、準備正式上線的階段，大家又會更集中地把網站重新走過一次。

所以整體比較像：

平常開發
↓
邊做邊測
↓
接近完成
↓
集中重新驗一次
↓
發現問題
↓
討論
↓
開 Issue
↓
修正
↓
再測

有些問題就是在這種「重新走整個網站」的時候才會出現。

因為平常開發時，很容易只盯著自己正在處理的功能。

但真正使用網站的人，不會只操作單一頁面或單一功能。

他會登入、切換頁面、重新整理、換裝置，也會一路操作不同功能。

這些動作串起來之後，才比較接近真正的使用情境。

當時其實沒有一份完整的驗收 Checklist

現在回頭看，我們當時並沒有整理一份很正式的：

PawPal 完整驗收 Checklist

然後每一項打勾。

比較接近的是大家一起測、互相討論、發現問題，再慢慢修正。

所以這篇所說的：

我第一次整理完整驗收流程

不是要說當時我是負責 QA 的人。

也不是我當時制定了一份正式規範，帶著整個團隊照表操課。

我只是團隊共同驗收的一個參與者。

而現在回頭看完這些經驗，我才第一次真的把：

如果今天再讓我驗一次網站，我到底會檢查什麼？

整理成比較清楚的方法。

如果現在重新驗收一次，我會怎麼做？

如果現在重新讓我驗一次 PawPal，我不會只打開首頁看一下，也不會只確認有沒有 Error。

我會把這些事情重新走過一次：

• 主要功能是否真的可以從頭操作到尾。
• 登入、登出，以及公開頁面和會員頁面的狀態是否正確。
• Desktop、Tablet、Mobile 的版面與操作是否合理。
• API 資料在載入前、載入中、載入後是否正常。
• 重新整理之後，資料狀態是否仍然正確。
• Sidebar、Navigation、頁面切換與返回是否符合預期。
• Loading、Toast 和錯誤提示，有沒有清楚告訴使用者現在發生什麼事。
• 發現奇怪現象後，先確認它是不是問題，再決定是否建立 Issue。
• 問題修正後，再重新走一次原本出錯的流程。

這不是我們當時正式使用的一份團隊驗收清單。

而是我現在回頭整理 PawPal 的驗收經驗後，自己會使用的方法。

因為真正走過一次完整專案後，我開始知道：

驗收不是只看最後一個結果，而是看整個使用過程。

修完 Bug，還要再走一次原本的流程

還有一件事情，是我後來越來越重視的。

問題修掉之後：

還要再測一次。

因為修改一個地方，有時候可能會影響另外一個地方。

所以我現在會希望至少做到：

發現問題
↓
修正
↓
重新走原本出錯的流程
↓
確認問題真的消失

至於實際修 Bug 時，我們又是怎麼一步一步找到原因的，那就是下一篇的故事了。

我對「完成」的定義開始改變了

如果是以前的我，「完成」很接近：

畫面有出來
+
功能能操作
+
沒有看到明顯 Error
=
完成

但 PawPal 做到後期之後，我越來越不敢這麼快下結論。

因為使用者不會在意：

某一個 Component 單獨看起來有沒有正常。

他只會感覺：

這個網站實際用起來到底對不對。

以前我會先看畫面有沒有動、有沒有報錯。

現在我更在意的是：

整個流程走完之後，使用者看到的結果到底對不對。

沒有報錯，和真的沒有問題，是兩回事。

而這大概就是我第一次真正理解「驗收」這件事的開始。

下一篇預告

驗收的過程中，我們找出了不少問題。

但「知道這裡有 Bug」只是第一步。

真正困難的是：

到底是哪裡出了問題？

有時候看到的異常發生在畫面上，真正的原因卻可能藏在完全不同的地方。

下一篇：

Day 26｜修 Bug 的過程，我學到比寫新功能更多。