標題雖為產品經理如何和 QA(Quality Assurance) 合作， 但實際上應是 PM 如何和整個團隊協作才是，此篇文章純粹紀錄團隊和 QA 之間的協作，以及自己經歷的相關紀錄。

​

目錄

• 測試項目不明確 / 彼此的誤解
• 不切實際的時程
• Retro也不要落掉QA的環節

​

測試項目不明確 / 彼此的誤解

QA 預期某功能的成果和團隊預期的不一致，不斷地 back and forth(來來回回) 卻始終沒有結果，針對產品的測項(測試項目)如果沒有定義清楚，QA 自然不知道要測試哪些東西、不知道實際測試結果和預期結果之間的落差，但這個問題可以及早定義出標準。

​

－PRD 應涵蓋 Feature Design Checklist

當你使用某個產品時發現，咦！這是 Bug 嗎？好怪呀！

但客服人員卻跟你說：沒事的！這是 Feature ＸＤ

很多時候我們在產品設計、規劃，必須要把 feature 各個狀態明確定義出來，才不會讓產品用起來有種四不像的感覺或是很差的體驗。

對使用者來說他們要的是直觀、好上手的產品，可是要開發出這樣的產品給使用者其實是有難度的，最好的方式就是 - 把自己當作傻瓜。

有這樣的同理心，基本上就會預想到大部分會發生的 Scenarios，也才能列出對應的 Feature design checklist 進而設計出易於使用的產品、功能。

在 PRD 當中可以把 QA 所需要的 Feature Design Checklist 列入進去，藉此可以讓 QA 知道功能的預期結果去比對實際的測試結果，其中相關的 Acceptance Criteria(驗收標準) 不僅僅是給 QA 看的，同時也是 RD 在 Local Env 開發所要完成的功能場景。

而這份 Feature Design Checklist 清單會包含：

1. 狀態

   • 預設
   • 等待
   • 失敗
   • 成功
   • 重複使用的保存狀態

2. 裝置

   • 硬體裝置
   • 螢幕大小
   • 瀏覽器

3. 功能

   • 使用者怎麼使用這個功能？
   • 使用者如何發現產品有這個功能？
   • 使用者首次使用(Onboarding) 時，如何指導用戶？

4. 角色

   • 根據不同權限的使用者畫面該如何呈現？（UI）
   • 根據不同權限的使用者需要定義不同的 workflows （UX）

​

－什麼是 Edge Cases

Edge case(極端、邊界案例) 是非常少見的非預期狀況。

在軟體產品當中，Edge Cases 會破壞使用體驗，所以必須明確地義非預期狀況下的 maximums(最大值) 和 minimums(最小值)。

就算團隊沒有 QA，這時候 PM 也要想辦法生出來，多溝通、討論才能設想流程相關的 Edge Cases，這是非常重要的事情！

不過 unexpected(不在預期) 的狀態為什麼這麼重要？

因為 RD 在開發階段一定自然會遇到針對不同功能的狀態顯示，如果沒有 UI, Edge Cases 他們只能自己通靈腦補去做假設，而在有限的時間之內，可憐的 RD 怎麼可能想得出最好的解決方案？

​

－Edge Cases Checklist

除了 Feature Design Checklist 之外，很多時候讓 QA 煩惱的是一些 Edge case(極端、邊界案例) 相關的問題， 因為使用者操作使用產品時，一定會遇到不在預期中的的極端狀況，產品在規劃階段定義清楚極端狀況的反饋、處理，就能夠避免使用者的抱怨。

通常我們會針對所開發的產品，訂定相關的 Edge Cases，例如：

1. 搜尋結果沒找到
2. A 功能對現有功能的影響、彼此連動
3. Mail 可以連續點擊 Send(送出) 郵件
4. 系統的問題而不是使用者的錯誤，必須提示讓使用者知道
5. 產品結帳頁面的 CTA 下單按鈕，能夠不斷重複地點擊結帳
6. 使用者向系統要求的資訊而我們沒辦法提供給他，該如何提示給使用者
7. 沒有網路怎麼辦？某功能進行到一半沒網路會發生什麼情況？顯示的訊息是什麼？
8. 無限上傳圖片，使用者或許不太可能上傳超過一千張圖片，但系統會如何處理成千上萬的圖片呢？有沒有明確定義 maximums(最大值) 和 minimums(最小值)？

以上這幾種具體的 Edge Cases 其實更抽象來看就是這幾種層面：

• Validation(驗證)
• Submission(送出)
• Permission(權限)
• Content(內容)
• Role(角色)

而在 PRD 列出 Edge Cases 的好處是：

1. 交出高品質的產品
2. 提高客戶滿意度 / 降低客訴
3. 減少 release 後的 bug / issue
4. 大家準時下班ＸＤ

​

－更多、更多、更多地溝通

PM 產出 PRD 後接著和團隊過一次 Kick-off Meeting，務必要請 QA 也參與這個會議，通常 QA 還沒看到 Acceptance Criteria 只確認相關的 UserStory 就會提出產品、功能會遇到的問題並提出對應方式，而相關的預期行為也就要補充到 Acceptance Criteria 這個 Section 當中。

除此之外，PM 一定要再三和 QA 確認驗收標準，任何影響到功能運作的情境都要不斷地補充、溝通。

最後，如果時間允許也請 QA 針對這份 PRD 列出 Acceptance Criteria，因為很多時候雙方的標準不一樣自然就增加溝通的成本。

​

不切實際的時程

團隊都知道 Deadline，但始終沒有預留 buffer 給 QA 做好測試 …

除了不切實際的時程之外，更多時候是漏掉測試所需要的時間然後就匆匆忙忙地上線，最後 … 最後東西就爆了。

​

－如何抓時程？

概算、預估 RD 所需要的開發時間一直是 PM 的難題之一，而我針對排程計畫通常會這麼做：

1. Break down 功能模組，切細再切細
2. 由 RD 概算開發時間

把大功能、產品主流程服務切成各種小等分，例如網頁的 UI Layout, Fetch API 這些 Task 分開並各抓時間出來，最後再由 RD 親自去概算一個時間，這樣才能大致精準抓出開發所需要的時程。

以上是團隊協作必須要有的默契和認知，那 QA 這裡怎麼抓時程？

1. 跑 Scrum Sprint 讓 RD, QA 一起估算 Story Point，把開發、測試時間一併計算進去。
2. 不是敏捷的開發流程，不管有沒有 QA Team，我都會把 RD 所概算出的開發時間(理想) 乘以 1 倍(實際)，而這些時間其實就是 QA 的測試時程，同時也讓 RD 解相關的技術問題。

而在 RD 完成所有開發工作之前，QA 同時也要提供 Test cases sheet(測試項目列表) 和團隊溝通。

​

－Bug 也有優先順序

QA 開始測試時，貓抓老鼠的遊戲就此登場囉～

這時候 RD 都是雙手合十祈禱不要有 Bug，就算有也不要叫我修ＸＤ

簡單的換位思考，QA 要的就是測試、交付高質量的產品，但工程部門一心只想要趕快把東西交付而忽略測試，純粹是利益不同的問題。

測試同時會產出 Bug Report，但 PM 一定要積極主動確保哪些 Bug 不會拖到 Deliver 的時間，在時間有限的情況之下， 有些 Bug 不修也不影響產品的主流程，或只是 UI 上需要微調的部分，這些情況不應該影響到 release ，所以一定要和 QA 保持溝通。

​

Retro也不要落掉QA的環節

如果團隊是跑 Agile(敏捷開發)，在 Retrospective Meeting(回顧會議) 一定要好好討論 QA 的工作環節。

我們可以在 Retro 當中討論這些問題：

1. 哪些功能 QA 花最多時間測試？
2. 哪些 Bug 是 RD 花最多時間去修復的？
3. 哪些 Bug 是在 release 之前就能發現的？什麼原因不能在 release 前就修好呢？
4. QA 在開測項有無遇到什麼問題？
5. 最後，任何想到的 Edge case(邊界案例) 一定要記錄到下一次的 Test cases sheet(測試項目列表)

產品的版本、功能一個又一個不斷地 release， 開發順利的同時也必須從經驗和大家的建議去進步，為的是省下 QA 的測試時間、為 RD 排除各種狀況專心寫 Code。

謝謝每個團隊中的 QA 夥伴，即使在產品的 Roadmap 訂定市場的突破點，但 QA 就是站在使用者和差勁的 UI/UX 中間，為產品做最後的把關！

​

Ref

• Cover Pic - epicpxls
• Pic - thenounproject