看板 Soft_Job 關於我們 聯絡資訊
講一個真實案例,某個做韌體產品的公司,規劃了某個 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,請好好珍惜他... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.43.132.233 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1551636193.A.295.html
xam: 這聽起來是RD廢到笑..RD自己基本的都沒驗過要找 Q 浪費時間? 03/04 03:07
ripple0129: 敏捷開發也是要解決這種問題 03/04 05:05
s06yji3: RD的問題,接口對不起來太誇張了。 03/04 06:20
jhjhs33504: PM的問題雖然追蹤進度但完成度沒QA就不知spec是否達成 03/04 08:34
jhjhs33504: 難不成要RD自由心證最後QC再打回然後再掰理由拖延進度 03/04 08:38
final01: 笑了,貴司真的厲害 03/04 08:53
wellkom: 顆顆,RD這麼廢的公司台灣還真的不少啊~ (煙) 03/04 09:46
chuegou: 需求要是有講清楚 是SW還是FW的鍋一目了然 03/04 12:50
chuegou: 看來是沒講清楚 PM在做啥呢 03/04 12:50
superjeff: 還蠻常見的 哈哈 03/04 16:30
annedoo: 我是文章原PO,謝謝你的分享,我也是撞了幾次牆後才發現 03/04 17:09
annedoo: 一開始就找QA一起進來他們在看spec的時候就可以先debug一 03/04 17:10
annedoo: 輪了總比進開發進測試才發現漏東漏~都是踩過雷才知道.. 03/04 17:12
annedoo: 如果你的團隊有個白痴PM(如年輕的我)請好好教育他QAQ 03/04 17:12
anandydy529: 那把QC當QA用的公司你怎麼看 03/04 19:32
mathrew: RD太廢啊,最基本的東西都沒測過就直接丟給QA 03/05 07:32
GameGyu: 別說最基本的東西都沒測過,我遇過連自已部門(不到5人) 03/05 08:23
GameGyu: 的東西都能打架 03/05 08:23
y3k: 這種事情有兩種假設 一種是這篇這種善良的 大家都認為自己在 03/05 09:14
y3k: 做對的事情 至於另一種邪惡的嘛....XD 03/05 09:14
viper9709: 推這篇 03/05 21:16