淺談數位產品測試的重要性
測試是專案佔比很重的環節，作用在檢查實際結果與預期結果是否相符且正常運作。功能異常或錯誤皆可能發生各種災情，以網站舉例，試想網頁錯誤所導致使用者流失、金錢損失甚至品牌形象受損等代價，這些都不是客戶想看到的，因此更需要花費心思在驗證及提高品質管理上。
熬過規劃需求、跨過執行挫折，歡迎來到上線前最後一哩路，測試地獄。
為了順利上線，我們會這麼做：
預留測試時程
在專案完成需求規劃提交規格文件後，可依據功能或流程制定test cases、test plan，除了預留測試時程，同樣也要保留編修時間，注意避免低估時程，使得來回測試更新結果最後必須延遲上線，或是壓縮測試時程直接上線，等到使用者盲測出特殊bug時才知道什麼叫做 最怕空氣突然安靜。
階段性測試
依執行階段或功能切割測試時機，例如：網頁切版後先檢查字體、介面是否跑版；Ａ功能完成先測試該單元及其使用流程是否符合期待。測試是一段需要來回的過程，盡量不要在開發後期一次進行所有測試導致loading過大，萬一測到厭世容易想擺爛，當然如果工程師願意接受接下來每天準備好的三餐加宵夜就例外啦。
不要害怕找到bug
以前進行測試時看到不斷增加的bug list都會很懊惱spec規劃不夠縝密、和工程師及設計師討論時不夠清楚，現在雖然進入測試泥沼還是會很糾結，但同時也會很慶幸，先找到bug還是比提交客戶或上線後發現問題來的好太多了啊！
找誰來參與測試
測試的過程特別需要細心和耐心。如果公司有專職的QA（Quality Assurance）可以在開發前與PM討論制定Acceptance criteria；如果沒有也沒關係，請不同的成員協助加入參與測試，也會得到很棒的效果！藉由設計師對視覺介面的敏感、工程師對功能背後的程式邏輯、PM對需求使用情境上的掌握等等，更多的經驗和專業知識都能夠突然成為金手指，抓到隱藏問題。
目前海棠測試的工作皆是由PM為主以及團隊成員共同處理分擔，並以手動測試為多，除了根據使用情境、使用流程、UIUX介面進行測試結果紀錄，同時也會檢查不同版本、極端情況或釐清例外狀況處理方式，以求更穩定的品質監控，同時確保每一位成員都擁有品質意識。
最後餵自己一口雞湯
測試有時候很耗時，時常霸佔半天到一天的時間可能只做這一件事（我不會承認當時是我太閒），大功能更新更可能天天都必須盯著它，但是為了專案上線後的慶功宴，打工人衝啊（？）
