新加入一個產品，我第一週會做的五件事

新加入一個產品，我第一週會做的五件事 目錄 1. 那次我沒做好第一週的代價 2. 五件事 3. 一個常見的錯誤：急著開始測試 4. 結尾 那次我沒做好第一週的代價 Ministry of Testing 的社群調查顯示，新加入的 QA 工程師平均需要 6–8 週才能達到穩定的測試產出品質，而主要障礙不是技術能力，而是對產品脈絡的理解不足。第一週怎麼用，決定了後面幾個月的起點。 我加入 我們的 App 的時候，第三天就接到任務：「這個功能做完了，你去測一下。」 我直接開始測。 測了兩天，開了七個 bug。但其中有三個，後來 RD 告訴我是「已知問題，下個 sprint 要重構這個功能，所以現在先不修」。有兩個是「這個行為是我們刻意設計的，不是 bug」。 我浪費了時間開了五個不必要的 ticket，RD 浪費了時間回應這些 ticket，關係有點尷尬。 如果我在第一週花時間搞清楚基本情況，這些浪費可以避免。 五件事 第一件：讀完所有「已知問題」清單 每個產品都有一份某種形式的「已知問題」清單：Jira 裡的 open bug list、Notion 裡的 backlog、或者口頭傳承的「這個地方先不管」。 第一週花半天把這份清單讀完，知道哪些問題已經被記錄了、哪些是刻意的行為、哪些在下個 sprint 要重構所以先不修。 這讓你之後開的每個 bug 更有可信度：你知道哪些是真的新發現，哪些是舊問題。 第二件：跑一遍完整的用戶流程，不帶測試目的 不是去找 bug，是去理解這個產品的用戶是怎麼使用它的。 我們的 App 的主要流程：下載 App → 建立帳號 → 選樹種 → 開始計時 → 完成計時 → 查看森林。從新用戶的角度把這個流程完整跑一遍，記下讓你困惑的地方、覺得奇怪的地方——這些很多時候是 UX 問題，或者是文件沒有說清楚的「設計如此」。 分清楚「我不懂這是什麼」和「這可能是 bug」，這需要先理解產品。 第三件：找出「最常出問題的地方」 去問 PM、RD 或其他 QA：「過去這個產品最常出 bug 的地方是哪裡？」 這個問題通常得到的答案很具體：「訂閱相關的邏輯最複雜」、「跨裝置同步出過好幾次問題」、「iOS 和 Android 的行為有時候不一致」。 這些歷史告訴你哪些地方需要特別注意，讓你的測試資源從第一週就放在正確的地方。 第四件：了解 release 流程和頻率 什麼時候是 feature freeze？什麼時候是 release 日？測試窗口是幾天？有沒有 regression testing 的 checklist？是 CI 自動跑還是全手動？ 這些決定了你每個 sprint 的時間分配和工作節奏。第一週就搞清楚，比第三週才發現「原來明天就 release」要好很多。 第五件：建立一份「我不懂的問題」清單 Stack Overflow Developer Survey 2024 顯示，超過 60% 的工程師認為缺乏文件和知識傳遞是團隊效率最大的阻礙之一。主動建立問題清單，是把隱性知識轉換成可查詢記錄的第一步——不只讓你學得更快，也讓下一個加入的人少走彎路。 整個第一週，把所有讓你困惑的東西記下來： 「這個功能的預期行為是什麼？」 「這個 error message 是刻意的還是 bug？」 「這個畫面只有特定帳號才能看到嗎？」 每週固定找 PM 或 RD 問這些問題，不要一個一個問（打斷太多），一次問五個（效率高，對方也比較好回答）。 這份清單也會顯示你在快速學習——比沉默兩週然後開一堆不必要的 bug ticket 好很多。 一個常見的錯誤：急著開始測試 新 QA 加入，第一個反應通常是：「我要趕快開始貢獻，要趕快開始測。」 這個直覺的問題是：沒有充分了解產品的情況下測試，產出的是低品質的 bug report（缺少脈絡）、誤判的 severity（不知道哪些重要）、還有一堆「這是已知問題」或「這是設計如此」的 ticket。 這不是貢獻，是噪音。 第一週用 80% 的時間理解產品，20% 的時間測試——這個比例在第一週是對的。到了第三週，比例反過來。 理解是測試品質的基礎，急著跳過理解直接測，是在砍掉自己的品質上限。 結尾 加入一個新產品的第一週，你的輸出不是 bug 數量，是你對這個產品的理解深度。 讀已知問題清單、跑完整用戶流程、找出歷史高風險區域、搞清楚 release 流程、記下不懂的問題——這五件事花掉的時間，在接下來幾個月裡省掉的混亂和浪費，遠遠超過這個投資。 我現在每次加入新專案或接手新功能模組，都會先做這五件事，再開始測試。 參考資料 1. Ministry of Testing — Getting Started in QA — QA 社群對新進測試工程師的實戰建議與資源 2. Stack Overflow Developer Survey 2024 — 工程師對文件缺失、知識傳遞障礙的全球調查 3. ISTQB Foundation Level Syllabus — 軟體測試基礎知識框架，包含測試流程與測試技術標準 4. Google Testing Blog — Test Onboarding — 大型工程組織如何讓新成員快速掌握測試脈絡 5. Capgemini World Quality Report 2024 25 — QA 人才培育與知識管理的產業現況調查