【PM夥伴攻略】如何跟QA合作？
每次被問到回答不出來的產品細節或邏輯，我都會去找 QA 確認，因為他們是這個世界上最瞭解功能細節的人！
軟體業中的 QA（Quality Assurance）是負責軟體測試、確保軟體功能正常的重要角色。在我剛加入團隊時並沒有專職的 QA，功能測試的工作是由產品經理、工程師、客服共同負責，而在兩年後 QA 部門已經比 PM 人數還要多了，包含手動測試、自動化測試與有經驗的 QA 主管來協調資源與管理測試項目（Test Cases）。
為了確保產品的穩定度與安全性，「測試」這件事情對於使用者數量多、以及會碰到「錢」的電商、金融相關產品尤其重要，因此除了 QA 本人會負責測試之外，產品經理、工程師也會在不同階段為測試盡一份心力。
▍軟體開發流程中的各種測試
1. 工程師 — Unit Test
開發時，工程師會寫單元測試（Unit Test），Code Review 時其他工程師會再次檢查 Code & Unit Test 是否合規。
2. 產品經理、設計師 — Use Case Review
當工程師的開發告一階段，會請產品經理、設計師測試功能與情境是否符合期待。通常就是對照著 PRD、mockup 來檢查與測試。
3. QA — End-to-end Testing (E2E), Integration Testing
到了 QA 手上時，會進入 End-to-end Testing (E2E)、Integration Testing 的階段，包含手動測試與自動測試。
手動測試時會檢查每個新任務的細節，除了正常使用情境與介面檢查外，也會測試極端情況、錯誤使用方式的處理、不同版本或權限的管理等等。
而在我們的流程中，自動測試的環節出現在新版本的功能、優化、bug fix merge 到主要分支後、準備上線前的最後一道關卡，跟 DevOps、SRE 密切合作。主要測試項目為目前線上已有的功能與模組，例如註冊、登入、加入購物車、結帳流程等等，避免新的版本影響到原有功能。而新功能的自動化測項則是會邊開發邊加進去，逐漸提高代碼覆蓋率（code coverage）。
自動化測試工具可參考《Best Automation Testing Tools for 2019》
QA 主管負責掌管龐大的測試項目（Test Cases）資料庫，使用如 TestRails 這類型的工具將測試項目分類、互相關聯、複製、移動，同時跟工程師、產品經理溝通新的功能開發的測試項目、資源、時程。
手動測試和自動測試都很重要，前者強調使用情境、使用流程、UIUX的具象狀況，後者則是能快速檢查與盤點大部份重要功能的實作與邏輯運作狀況。
【補充參考】其他類型測試
・效能測試（Performance Testing）
・用戶驗收測試（UAT - User Acceptance Testing）
・易用性測試（Usability Testing）▍如何跟 QA 合作？
1. 提供細節清晰的測試需求
與 QA 的溝通工具同樣為 PRD，測試跟開發一樣是非常細節導向的工作，QA 的工作是要將所有可能發生的狀況展開來，比對「預期結果」與「實際測試結果」並回報非預期的狀況。
除了 PRD 以外，我通常也會整理一份非常概要的清單給 QA 同步參考，QA 再依照 PRD 與清單內容來擴寫測項。
【清單舉例】
・正常、極端、錯誤情境
・未登入、已登入情況下
・已開啟、未開啟A功能的使用者，使用新功能時的情況
・裝置、螢幕大小、瀏覽器2. 除了測試功能，也讓 QA 從產出 PRD 的階段開始幫忙偵錯
我們的 QA 是隸屬於獨立的部門、並未直接安排在各小組內。每個 Scrum Team 會共用測試資源，因此 QA 會同時測試許多不同類型、模組的功能。
我合作的 QA 都是邏輯很好、記憶力高超的細節魔人，讓他們及早加入產品設計的討論、跟工程師設計師一起規劃的好處是可以在看 PRD 的時候就幫忙偵錯（是不是少考慮A情況呢）；也因為同時熟悉許多其他模組的功能，可以及早發現功能間有 dependencies 的問題（跟B功能之間的關聯是否有考慮到），避免進入開發後才發現問題。
3. 掌控好每次開發、測試的項目的範圍
以敏捷式開發來說，產品經理會跟工程師一起將大的功能切成不同 Phase，每個 Phase 會有多個小任務，按照前後端、頁面規劃、User Stories 切分。
將任務切小的優點除了時程與資源較好預估外，也減輕單次工程師開發、Code Review 以及 QA 測試的負擔。
試想若整個功能都做完了，一次測試到 10 個問題，心裡直接山崩地裂土石流，接著工程師改完 10 個問題後，發現修好 A 又壞了 B，整個心累。
若能將功能分成 5 個小任務，也許第一個任務測試到 3 個小錯誤，改完後就先上線這個小任務（用 Feature Flags 先藏起來不讓使用者看到），接著再著手進行第二個任務、或是同步讓其他 QA 測試其他範圍來加快速度，每次的負擔較小外，持續 deliver 的感覺真的很好呢！
4. 記得預留 Buffer Time 給測試時程
怎麼每一篇都會提到要給對方預留足夠時間啊？摁⋯⋯因為我們每次都把事情想得太簡單了！事情真的不是你想的那樣！
工程師開發時間的預估是一個難題，但是測試時間的預估更是困難重重！有些功能改一個小邏輯（工程開發很快）但是測試卻要測到非常多種特殊情況與結果，不論是手動測試或自動測試，光是寫測項就要花很多時間了，更不用說實際測試、驗證、寫下 BUG 重現步驟、截圖截影片所花費的時間。
接著工程師拉回去修正，也不確定要修多久，修完再來測試一遍，超級耗神費工！也因此第三點將任務切小尤其重要，至少減少單次實作、測試的時間，讓來來回回（back and forth）的狀況減少。
5. 上線前找到 BUG 皆大歡喜🎉
剛開始接觸這份工作時，每當 QA 找到 BUG 我都很氣餒，尤其是一次開了十幾個 defect 要我一一檢查的時候。煩惱自己跟工程師溝通不夠清楚、跟設計師一起 Review 的時候沒抓到錯誤、寫 PRD 的時候思考不夠縝密，然後想著上線時間又要延後了，不想面對啊！
隨著做的專案與上線的功能愈來愈多後深刻體會到，問題提前被 QA 抓到總比上線後被客戶發現、被使用者回報好太多了！畢竟到那田地，就不是單純心情不好、時程延後被被老闆唸這麼簡單——小則客服、業務被客戶罵，大則讓客戶賠錢、造成使用者流失，甚至成為公關危機導致品牌信譽沒了，這些才是更嚴重而且難以挽回的狀況。
從此以後，上線前找到 BUG 我都心懷感激，謝謝 QA 總是這麼細心的把關，對PM、工程師來說，每次都是學習的機會，看看自己又少考慮了些什麼，一起討論下次如何避免，大家各自發揮自己的專長，就是團隊合作最讓人開心的時候！
延伸閱讀：想更瞭解各種測試的類型與其重要性，可以參考《一次搞懂單元測試、整合測試、端對端測試之間的差異》，裡面也有對自動化測試更詳細的說明唷～
謝謝你的閱讀！如果有任何疑問、建議的主題也歡迎留言給我 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多團隊合作的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我們知道 👏🏻未來也會分享跟團隊內其他角色的合作方式，敬請期待！
想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)