相信每個 QA 工程師在工作中，一定都被問過這句話：「這個問題你怎麼沒測到？」（ 如果你是 RD，你可能也被問過，又或者你就是問這個問題的人 XD ）
接下來大家不免一邊甩鍋一邊修 Bug：
「我明明都做過單元測試了啊！」
「誒不是，這個 case 誰會注意到啊…」
「趕時間上版，來不及測那麼完整…」
好的團隊倒還好，大家湊一起找到問題修一修就沒事了，如果不是，那我相信那天會是一個漫長又難忘的一天。
前言
作者在《軟體測試實務：業界成功案例與高效實踐》這本書中，以「你怎麼沒測到？」為開場白，談到了測試的責任歸屬。
Bug 的背後，藏著更深層的問題
在開發時，可能還是會有多數人這樣認為：「QA 就是測試 RD 寫的程式碼，確保上線後沒問題。」這種單方面的藉由職稱來了解 QA 的職責很可能會產生以下狀況：
- RD 在開發時連單元測試都沒寫，反正會有專門做測試的，所以只要確保在時間內交差就好。
- PM 礙於時間壓力，縮短 QA 的測試時間。
- QA 需要頻繁測試基本功能，一發現問題就要等 RD 修好，然後再重複測一遍。
長期下來的結果就是產品上線後頻繁出狀況，然後第一個被檢討的往往是 QA。但我們需要停下來想想：
- 開發時程是否太過緊湊？
- 需求是否在一開始就定義清楚？
- 團隊間的溝通是否順暢？
這些都是造成 Bug 產生的潛在原因，單純將責任推給 QA，只會讓問題更加惡化。
改變思維，重新定位 QA 的角色
與其在事後追究「誰該負責」，不如：
- 在專案初期就納入 QA 的意見
- 建立清晰的測試策略 ( Test Plan )
- 重視自動化測試
- 培養團隊共同對品質負責的文化
QA 的真正價值不在「抓蟲」
說真的，QA 最重要的價值，不是找出所有的 Bug（因為這根本是不可能的），而是：
- 提前預防可能的風險
- 協助團隊建立更穩健的開發流程
- 從使用者角度主動提供產品建議
如書中所說，當 QA 能夠讓團隊理解某個問題可能帶來的影響和後果時，主導權就會回到 QA 手上，專業的 QA 不僅手握軟體開發流程的主導權，更是開發團隊和專案經理、設計師之間不可或缺的橋樑。
畢竟，軟體品質不應該只是 QA 的責任，而是整個團隊共同的目標。
寫在最後
不論是 RD 還是 QA，下次聽到「這個怎麼沒測到？」時先不要動怒，我們可以想想「是不是團隊間哪裡出問題了？」
好的軟體品質需要 RD 和 QA 的緊密合作，就像書中說的，這不是一場拉鋸戰，而是一個共同成長的旅程。
接下來的系列文章，我會繼續整理更多在《軟體測試實務》中的筆記，也可以在分類中找到喔！
