講一個真實案例，某個做韌體產品的公司，規劃了某個 release 功能，
然後PM找了SW RD lead 跟 FW RD lead 說明工作內容，然後兩邊估了大概一個月的
時間。最後弄出一版要給我(QA)測試，我玩了玩發現不太妙，找了這兩個大頭到白板
前面，溝通一下我看到的問題，然後...兩個資歷總和是我三倍的人就開始吵起來...
原來是 SW / FW 從最基本的訊號溝通的定義就有落差，一邊是 Clock Base，一邊是
Event Base，只有在慈孤觀音保佑時才保證兩邊能正常溝通...
最後我趁亂逃了出來，他們繼續「溝通」了幾個小時，結論是當初的設計有誤，最後花
兩個月的時間，才把功能做出來。
這個案例說明了，專案從一開始 RD Spec就做錯了，而且沒人發現，然後就一路錯到底。
SW/FW Lead都沒發現，他們用各自以為的方式做事，PM根本搞不懂。然後 QA 完全沒被告
知要參與討論...
從 原PO文章看起來，流程上好像 QA 只是整個流程的最後一關。其實這不是QA，這只是
QC 而已，真正個 QA 不該只是成品完成之後測試，更是應該在設計階段就該導入。
上一篇文章有提到，如果等到錯誤的設計已經被實做了，那 QC 進來只是瘋狂採地雷而已
完全沒有效率，而且難以確保產品的品質。QA 的精神應該要盡可能的左移。
當 PO 開出 Product Spec 的時候，QA應該要來檢查Spec 是否合理？是否跟現有功能抵
觸？ ...
當 RD 提供 Design Spec時，QA 要檢查設計是否合理，元件切割是否妥當，介面是否有
足夠的測試功能？unit Test 是否足夠？ ...
當然 QA 也應該要提供 Test Plan，詳述測試目標、方式、範圍、組態。並切讓 PM 與
RD 瞭解。
請不要把 QA 當 QC 用。如果你的團隊有個討厭雞婆的 QA，請好好珍惜他...