當產品已經進去開發了，那一步的動作，就是要確認開發的內容是不是有符合開發的規格內容，這個階段就是所謂的「軟體驗證SQA(Software quality assurance)」，軟體驗證是一門專業，產品經理是不用到完全了解，但是需要知道SQA運作機制，以能確保再上架上市前，可以確認產品服務的完整性。

與SQA確認issue項目時，可以進行下列幾種狀態，以利於SQA確認是否需要開票給RD進行修正

• Priority
  • Blocker：發生嚴重功能服務的錯誤，如果該issue沒有修正，相關功能均無法使用，比如說：付費功能不能付費，所以觀看影片服務亦不能使用。緊急程度最高
  • High: 必須盡快解決核心功能錯誤問題，因為該錯誤嚴重影響產品的核心功能，在修復完成之前，服務都會無法提供正確使用狀態，比如：影片播放的啟動按鍵，無法被點擊，以致無法正常觀看影片。緊急程度高。
  • Medium: 該錯誤問題為可能被預測或開發過程中已知問題，需在正常開發活動過程中解決，可等到創建新的內部版本或版本，隨版本更新，比如：在開發中，知道串流供應商將會升級版本，可能會影響使用者播放影片順暢度，就需要帶串流版本更新後，也隨之更新新版本上架，減少使用這看影片的不適體驗。緊急程度中等。
  • Low: 該問題是一個刺激增加使用的因素，但非為主要核心功能，需進行修復，修復時間點可以推遲到更嚴重錯誤之後進行。比如：播放影片的按鍵翻譯有誤，但不影響觀看影片內容，可於下一版本更新。緊急程度低。
  • Backlog：有一些問題是可能不緊急或是現況不緊急但是影響成面過大，在現況運作之下不宜修改，需要完整規劃後再安排時間進行修正。比如：影片播放時，自動翻譯內容有誤，但仍不影響產品服務使用，不即時修正，需排查AI功能內容。緊急程度視影響程度安排排修。

基本上所有的issue在DEV或Pre-Stage環境先把重大issue都先解完，然後再進入Stage，然後再解中/低等級的issue，最後要上先之前，只剩下Low或Backlog；理想上是最好上線前都是0 issue，但是現實是不太可能，因為上線會有時間條件的壓力，因此不可能都全部解完，才可以進入Prod上線，因此就會需要PM的衡量，那一些issue一定要修，那一些可以慢慢修。

• 分配原則 ： 每一張Bug 都要有指定人員修正或追蹤
  • SQA 會將每個 issue 都設定等級並直接先分配給各SPM(Software Project Manager)。判定原則如JIRA 系統的4種不同分級的定義。
  • 由 SPM 視等級優先度，責成給工程師修正排查 ，或轉給 PM 規格釐清等。
  • Priority 的欄位交由 SPM 使用，視專案任務的時程進度來調整。
  • SQA 仍可直接提出 Priority Blocker 的問題，主要會是阻礙測試繼續進行的問題，會優先指派給 SPM 安排修正並發行新版本 。

Take away

軟體開發不可能做到0 bug，因此要衡量issue/bug的影響程度，對於使用者使用服務體驗上的影響程度。

再有人員資源分配及時間壓力之下，需要評估修改issue的可行性，不一定要一次修完100％才可以，可以分批次修改，以能讓功能持續運作。

每一個issue可先與SQA人員討論確認後，在進行分配給RD進行修改，以能暸解RD人力資源的運作，讓功能進行順遂。