楼主:
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