作者:
kkc0828 (慢跑後衛)
2019-03-04 02:03:10講一個真實案例，某個做韌體產品的公司，規劃了某個 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，請好好珍惜他...
作者:
xam (聽說)
2019-03-04 03:07:00這聽起來是RD廢到笑..RD自己基本的都沒驗過要找 Q 浪費時間?
作者: s06yji3 (阿南) 2019-03-04 06:20:00
RD的問題，接口對不起來太誇張了。
作者: jhjhs33504 ( ) 2019-03-04 08:34:00
PM的問題雖然追蹤進度但完成度沒QA就不知spec是否達成難不成要RD自由心證最後QC再打回然後再掰理由拖延進度
作者:
final01 (牛頓運動定律)
2019-03-04 08:53:00笑了，貴司真的厲害
作者:
wellkom (wellkom)
2019-03-04 09:46:00顆顆，RD這麼廢的公司台灣還真的不少啊~ (煙)
作者:
chuegou (chuegou)
2019-03-04 12:50:00需求要是有講清楚 是SW還是FW的鍋一目了然看來是沒講清楚 PM在做啥呢
作者: superjeff 2019-03-04 16:30:00
還蠻常見的 哈哈
作者:
annedoo (蕭安)
2019-03-04 17:09:00我是文章原PO，謝謝你的分享，我也是撞了幾次牆後才發現一開始就找QA一起進來他們在看spec的時候就可以先debug一輪了總比進開發進測試才發現漏東漏～都是踩過雷才知道..如果你的團隊有個白痴PM（如年輕的我）請好好教育他QAQ
作者:
mathrew (Joey)
2019-03-05 07:32:00RD太廢啊，最基本的東西都沒測過就直接丟給QA
作者: GameGyu (GameGyu) 2019-03-05 08:23:00
別說最基本的東西都沒測過，我遇過連自已部門（不到5人）的東西都能打架
作者:
y3k (激流を制するは静水)
2019-03-05 09:14:00這種事情有兩種假設 一種是這篇這種善良的 大家都認為自己在做對的事情 至於另一種邪惡的嘛....XD