這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
上一篇提到產品進入開發階段時的注意事項，以及 PM 需要顧好哪些事情，接著等產品開發完成後、上線之前，還有一個「測試」環節，包括應該要由誰測試、怎麼測試等，這就是這篇要說明的部分。
誰來測試？
在專業分工的組織內，通常會由 QA (Quality Assurance Engineer，品質保證工程師，可能會簡稱「測試」或 “QA”) 負責一個功能或產品的測試。
不過，像我待的前一家公司並沒有專職 QA，那就會由參與開發的核心團隊 — — 包含 PM、設計師、工程師等，再加上業務團隊 — — 如業務、行銷、客服等一起測試。
但「術業有專攻」真的有其道理，如果想要做到盡可能周全的測試，團隊有一位（甚至多位）專業的 QA 是非常、非常、非常重要且很有價值的！下一段就來細談原因。
要測試什麼？
講到「測試」，大家會想到的可能是「啊不就是看產品操作的時候會不會當機、畫面有沒有跑版就好嗎？總之就是要確認產品能正常使用而已吧？」
然而，所謂的「正常使用」涵蓋很多面向，如果只是做一個 landing page，或者更改某幾個文案、某幾頁的網頁內容，或許還不需要專業 QA 出馬，PM 一人就能完成測試。
但如果產品功能較繁複，專業的 QA 會根據 PM 完成的 PRD 以及最終版的 UX 和 UI 內容，撰寫一份超級完整的 test case list，裡面會包含所有要測試的項目與預期結果，一旦發現測試項目的結果有不符預期處，QA 就會整理並請工程師修改。
一般來說，測試面向主要涵蓋以下 3 大類：
1. 功能正常
「功能正常」這四個字說來簡單，但真的包含很多情形，比較普遍的如：用戶能「正常」登入、能「正常」完成某個行為（如：瀏覽文章、完成註冊、按讚等）。QA 基本上就是要確保產品有做出當初 PRD 或設計稿規範的內容，並結合產品內的各種角色權限、用戶使用的裝置（mobile/desktop/tablet，有時甚至還要細分 ios/android, window/mac）、用戶使用的瀏覽器（chrome/edge/safari…etc），確保產品功能在任何（或大多數）情況下，都能正常運作。
以我負責的企業內部工具為例，先前這篇文章〈負責內部產品（Internal Product）的 PM 都在幹嘛？跟 to B/C 端產品有什麼不同？〉有提到，這些工具涉及敏感資訊（薪資、考核、員工個資等），最重要的就是「角色與權限」，隨著每個人的職能、年資、職等或部門的差異，每位同事能看到的資訊也差很多，所以內部工具對於權限控管需要非常小心，發想產品規格、規劃操作流程，以及最終測試時，當然也要非常謹慎。
在這情況下，一個工具可能有十幾種角色與權限，專業的 QA 不只得把每種角色權限都測試過一遍，還要確保每個角色都只能作出對應的權限，能看到的資訊不多也不少。
而且「測試」這份工作不只需要努力與細心，如何有效率地完成測試也很重要，為了減少手動測試的繁瑣，有些測試工程師也懂得寫程式，會試著讓測試過程自動化。
2. 畫面細節符合 UI 給的 mockup
有些眼睛比較利的 QA 還具備設計師的 “pixel eye”，能發現畫面上哪個區塊沒對齊、往左偏了一點、往下多了幾個 pixel 等；不過如果是要確認設計上的細節，畢竟設計師還是最專業的，所以通常會直接請 UI/UX 設計師跟著測試，QA 著重功能邏輯面的驗收，設計師則確認工程師做出來的介面跟設計稿一致。
3. 極端情況
每次功能測試驗收時，我自己最愛但也最怕的 QA 跟我說：「我們遇到一個極端情況 (corner case)……」，意思就是 QA 刻意去做一些一般用戶通常不會主動做的事，比如：輸入很長的字、重複點擊某個地方很多次、不斷刷新頁面等。
看到「極端」，很多人可能會想說：既然是很稀有的狀況，那應該可以略過吧？但事實上，雖然極端，用戶一旦碰到後，如果產品團隊沒有妥善處理對應的動作，便很可能讓用戶的使用過程變得很不順利，進而影響用戶對於產品的整體評價。
比如用戶正在填表單，填到一半網路斷線，如果產品完全沒有跳出任何提示，用戶可能按下送出表單後才發現斷線，那些內容都白填了，用戶一定會氣瘋；又或者用戶做了某些情況會影響到產品效能，進而導致 app 閃退等，這都很可能是屬於「極端，但又非處理不可」的情況。
測出 bug 後，全部都要修嗎？修不完怎麼辦？
當功能完成開發後，QA 就會開始測試，有時 PM 和設計師也會跟著一起測試，測到 bug 後，就請工程師修復此問題。
上面這句話看似簡單，但有時可能是工程師比較不拘小節、產品基礎建設不足、前人留下太多潛在的技術問題、當初的規格沒有訂清楚或者有異動等，這都很可能導致 QA 測出的 bug 數量遠高於預期，有時甚至只是想測 A 功能，但該功能連動到 B 模組，結果有 bug 的是 B 模組，這種盤根錯節的關係，也可能使得 bug 數量再次瘋狂增加。
不論基於哪種原因，當測出太多問題時，萬一剩下的時間不夠修完所有 bug(s)，這時又需要出動「優先排序」這個工作技能了！
PM 可以跟 QA 討論，將較緊急、較重要的 bug 特別標註起來，讓工程師優先修復；至於其他「雖然有 bug，但不至於影響操作」的部分，比如前端工程師選用的顏色跟設計稿內的不一樣、設計稿的文案是置中，前端工程師排出來的是置左等，這些可以挪到優先順序較低的區塊，有空再修，或者排到下一次版本更新時再一起修。
💡 剛開始做 PM 時，會覺得自己很想要盡善盡美、顧好每個部分，所以一看到 bug 票就難受，很想要找時間把它們一起修好；但隨著經驗累積，這個想法多少有點改變。
並不是說 bug 不用修，而是工作上做的每件事情，都有對應到的原因與目的，某個 bug 是否要修、某個功能是否要做、某個產品是否要改版，這都得視當下公司的目標與需求。
有的公司正在瘋狂成長期，首重產品上線、要在第一時間搶下用戶數，所以一些中小型的 bug 通常就不需要在第一時間處理；有的公司穩定成長、固定版更，或者超級講求用戶體驗，且團隊又有充裕的時間與人力維運產品，那麼即使是一些小瑕疵，想必公司也會希望能盡快改進。
結語
上面這些就是大致上的測試環節，測試完成後、bug 也修復後，通常就可以準備上線了！至於上線時還得做哪些準備、上線後又可能會發生哪些（意想不到的）事，就留待下篇詳細說明囉。
