「這你專門吧？」 — 測試應該 RD 寫還是 QA 寫
故事是這樣的
筆者有個朋友，在前公司待了十年，都在當手動測試的 QA，最近突然被栽員（應該說是公司準備收起來了）。幸好，經過一番努力，很快找到了新工作，可喜可賀。一聊之下，才知道他是要去我另一位朋友公司上班，要做的是「做自動化測試的 QA」。
這件事是這樣的，據我所知，這個團隊是屬於「RD 沒時間寫測試」的那種。這個時機，專門聘請一位 QA 來「專門做自動化測試」，這件事我有點感觸。
測試就是測試嗎？
「測試不就是 QA 的工作嗎？」很多人都會直覺地這麼想。但事實上，一樣是測試，還是有很多不同類型的，例如下圖就是一種分類法：
在上圖中，我們口中的測試被從兩個維度（四個象限）來討論：
- 支持團隊（功能對不對） v.s. 評價產品（產品好不好）
- 面向技術（需要技術能力） vs 面向業務（需要商業思維）
而這四個象限的工作，如果都叫 QA 做，那麼他的測項會變得太雜太多。
例如，左下的測試就比較適合 RD 做，因為「面向技術又支持團隊」的測試，如果通過了，那就代表開發團隊做出了一個「跟當初動手寫扣前表現一樣」的功能，也就是 RD 的工作真的有做完。
於此同時，右上的測試就比較適合 QA 做，例如 Exploratory Test，就可以幫助我們知道這個商品「要怎麼解決問題、有沒有解決、用起來有沒有用戶意料外的事情會發生」。這種測試雖說比較適合 QA 做，但就不容易（或無法）自動化測試。
那 QA 的自動化測試要測什麼？私以為，你可以在左上角找到。例如整合環境下的功能測試，可以幫助我們判斷這個產品功能「在指定場景下，能不能如預期般表現」，這就是 QA 不自動化的話，每天都在手動做的事。這樣的事重複做多了，將其自動化，可以幫助 QA 工作起來事倍功半。
自動化測試與單元測試
回到我朋友的情況。如果一個團隊，只有一個 QA 在做自動化測試，其他 5 ~ 6 個 RD 連單元測試都不做，會發生什麼事？
我想，對 QA 來說，一開始大概不會有什麼問題，因為他找 Bug 的速度變快了。這些 Bug 可以被快速地開出來，省下 QA 不少時間，減少加班機會。
然後呢？
然後這些單依舊 Queue 在 RD 手上，因此對整體開發速度（我是指維持一定的可觀察品質下）幫助不大。
然後呢？
然後老闆會發現 QA 事做完了的同時 RD 忙得要死，這時你是老闆你會做什麼？給 QA 加薪？放榮譽假？
不可能吧？
當然不可能！你只會：1) 叫 QA 做更多其他象限的測試，或 2) 請更多 RD 來製造更多待測功能（或 bug）來平衡工作量。
不論是哪一個，都不是很有效率的方法對吧？
各司其職
問題在越後面被發現，修復成本越高。當然，絕對是比完全不自動化好，但我們好還要更好，對吧？
如果一個團隊的 RD 也會做單元測試，那麼 QA 的測試能抓到的 Bug 就可以控制在一定的量之內，才不會有大量來不及解的 issue 常態性存在著。這時 QA 再把這些工作自動化，才會相輔相成。
因此，私以為，自動測試並不只是 QA 的專屬工作。大家都把自己該做的事做好，並在可以的範圍內自動化，方能讓我們的努力更加事倍功半！
Reference
More about Me
- 更多軟體工程相關討論：https://www.facebook.com/kukumamaya
- 我的YouTube 頻道：https://www.youtube.com/@yu-songsyu6598
- 沒時間寫測試？沒時間重構？你就是不寫測試才會沒時間： https://www.tenlong.com.tw/products/9786263332645?list_name=lv
