Re: [心得] 我在科技業遇到的鬼故事之一

軟工

252846

我是原po,我來交代一些細節,供大家參考一下。

角色:

我在這裡的角色是application owner,我要推一個應用給客戶去使用。

我這個application需要多個feature來組成,B是我其中一個feature owner。

B這個feature需要多個kernel function整合才有辦法達成,當然B自己也要寫不少code。

A是B負責的feature的kernel function owner,同時我也是A的主管。

我也有配到一組跟我對應的QA,而我要承擔最終的成敗。

這其中:BU1:{{A,我},QA} BU2:{B}


一開始A接到bug試不出來,有去找B討論,但是B認為步驟寫在bug report上很完整了。

而且B有其他feature要開發,無法把機器+環境借給別人。

然後我想可能是概率問題,去找QA幫忙,QA也有在他們各種環境下增加這個測項。

最後A/QA都試不出來,於是A把bug mark成無法複製。 QA也確認無法複製之後就close了

B發現被mark無法複製之後,B就把feature 打開commit上去。(我當時不知道他是故意)

根據我們release流程,他的change被QA挑進mouthly release中,通過測試release。

最後客戶拿到就炸掉了,如上一篇文章所講。


這個過程中,其實我犯了幾個錯誤。

B的report是寫發生率100%,但是包含B在內的RD都很習慣把(實驗一次:發生一次)=100%

所以我誤判這個問題並非100%,才有後面請QA幫忙大範圍測試。

事後分析,B的確也只遇過一次。當下能複製的環境,在最後檢討的時候也不見了。

最後釐清完反推才知道,原來在錯的環境下,就是100%複製沒錯。



第二個錯誤,我跟A其實有作code review。A也有找到幾個疑點,會導致bug描述的現象。

於是他也預防性的做了一些修正,但是因為無法複製問題,所以無法確認是否正解。

我手上一堆『無法複製』的問題,我最後卡關的條件就是QA大規模測試無法復現,加上

code review有正面反饋,我就給過了。因為也不是正解,我之前描述就沒講到這段。


第三個錯誤,我當時對QA team花的時間太少。客戶的使用情境,我們原本應該是要能夠

造出對應的測項去把關。 在PM跟我們(RD+QA)解釋完客戶的情境之後,我就單方面認為

『情境QA都知道了,QA都是老鳥應該是知道怎麼造測項吧?』

如同前面的敘述,我本身是RD leader,在臨危受命去協調這個applicaiton時,

我的mindset還是覺得我就是RD leader,而不是要扛成敗的人。 我覺得這個mindset

才是整個事件的主因。最後我也因為這樣失去一些升遷,但是我也覺得這超出我能力。



最後我分享上面這一些事情,其實都是各位工程師們的日常。

原本也沒有什麼特別好講的,我只是覺得最後B跳出來自爆這件事很扯。

所以我認為鬼故事的點,是B竟然會自爆。太不可思議了。


就如同我在上一篇文章裡面留言的,我一開始就知道我一定是全責。

也並沒有要把責任推給任何同事的意思(事實上也不可能推得掉XD)。


這件事的後續是,我跟QA留下來作PDCA,結論就是最後這關一定要弄清楚客戶環境。

客戶的部分,我負責了客戶資料救援,最後也是有救回來,可能是這樣所以考績沒影響。



其他人的部分,我是極力不想對A究責,B的主管也是一樣的態度。

最後我們兩個送上去給老闆的說法是這兩個人的責任,10分裡只有1分。

但是老闆還是砍了他們分紅,我們打上去的考績也是被打折。

A因為這件事,有點不爽的離職了。

我因為這件事,有點心灰意冷.....覺得自己不勝任,後來也是離職了。

B的部分,我不知道他心理怎麼想,我只知道他最後因為請人代刷門禁被火。



下面是技術細節,可略過。


B的環境,其實是因為他在測A的功能之前,先跑了網路相關測試。

在網路的測試中,有一個Link Aggregation的測試中,跑完忘記把LAGG拆掉。

導致B測A的code時,因為有LAGG所以A的code 才跑出不預期的行為。

而B其實也沒有描述他前一天他的機器有跑什麼測試(這也合理)。


之後有人發現網路測試中,LAGG沒有拆掉,導致後面一堆測試錯亂,所以『修正』了。

所以後面我們大規模測試也沒有測出這問題。


客戶環境,就是使用LAGG。而QA也有測LAGG,也有測A的功能,就是沒有兩個一起測過。




關於B的處理,補充一段後續。

會議當下我聽到B自爆,我正在想要怎麼處理,要去找B的主管。 結果QA直接report給老
闆這件事,我們就不得不處理。

我/B/B的主管,三個人在會議室。

我問B:你是看到A/QA把bug close後,你又測了一次發現還是一樣,所以才打算commit上
去想要highlight他是嗎?

B說:沒有,後來就沒有測。

我問:你沒有測,你怎麼會知道這個問題還在?

B說:他就說can not reproduce啊,所以問題一定還在。

我說:這不一定吧?

B的主管:所以你只是因為他沒有解,所以你認定問題還在,才想要highlight這個問題?

B說:對,我只是想提醒大家問題沒有被解決。

我說:那你到底測過幾次?

B想了一下說:1次

我說:可是你寫always耶!

B說:我就想說測1次中一次就100%啊。



後來B先被請出去了,我跟他主管談這件事。

我們最後的共識是相信B主管的總結:因為bug close當下,那段有問題的LAGG test code
已經被修掉很久了。 B不太可能有真的機會複製出這個問題。 而且LAGG test code被修
掉這件事,也可以解釋為何我跟QA沒有辦法複製。 這個說法,大家都會有台階下。

所以最後我沒有去糾結為何他那麼明確知道bug還在這件事.....我接受B主管的說法了。



--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.74.78 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690282742.A.167.html
xam1樓B只有遇到一次,且無法複製,那就是Once,不是Always 07/25 19:02
awenracious2樓別的不說 B的個性人品道德應該是有問題的 07/25 19:07
ybon33樓有些大環境的管理方式真的是很打擊前線人員士氣 07/25 19:08
ko27tye4樓B只出現一次 那把功能打開不是正常嗎 A和QA都確認過了 07/25 19:20
本人5樓的確只有一次,他不是QA,也不好要求多測幾次。總之我是 07/25 19:35
本人6樓接受。 07/25 19:35
本人7樓所以B根本不需要講他是故意的話。 07/25 19:37
airtsubasa8樓自爆的場合是跟你一對一閒聊? 07/25 20:23
sirlers9樓QA建完測項沒跟PM/leader核對過需求嗎? 這補述B根本該0 07/25 20:23
sirlers10樓責 真的做出release到客戶端的是QA呀 你們這流程B當時的 07/25 20:23
sirlers11樓確就該commit了 07/25 20:23
viper970912樓推四樓 07/25 20:24
superpandal13樓B不講但是B commit了 頂多責任比較少才算公正 07/25 20:25
airtsubasa14樓測試沒有做整合測試也是恐怖? 07/25 20:26
superpandal15樓這不是純一個人的問題 不可能零責的 07/25 20:29
本人16樓沒錯原本以為B是無責,在我bug review找他進來幫忙時自爆 07/25 20:29
本人17樓,我都不知道他是哪裡搞錯。 我猜他沒有意識到現在是在討 07/25 20:29
本人18樓論炸在客戶的問題。 他當下也不是故意commit的,因為他只 07/25 20:29
本人19樓測過一次。 A mark 無法複製後,他是沒有複驗的。 我猜 07/25 20:29
本人20樓測他只是聽到A的bug 被客戶打出來之後想要嘴一波。 07/25 20:29
sirlers21樓你說"原本以為" 那現在回看呢? B作業上的疏失在哪? 07/25 20:34
本人22樓如果B是明知道code 有問題,但是他故意不擋,那就有責任 07/25 20:41
本人23樓了。 但是他不自白,沒人會知道他是故意的。 就算我事後 07/25 20:41
本人24樓覺得他可能只是嘴秋,但是會議上留紀錄了啊。 07/25 20:41
superpandal25樓不講責任小 講了責任大 07/25 20:45
superpandal26樓他是統整的人還是會有小小的責任 07/25 20:46
CindyK27樓推mindset 07/25 20:53
justfortest28樓怎麼覺得 B 會被究責原因的在心態(用客戶HL),不然 07/25 20:54
justfortest29樓處理的方法很合理阿。owner + QA 都說沒問題,憑甚 07/25 20:54
justfortest30樓麼要求 B 說要擋。再退一步,不管 B 心態有沒有問題 07/25 20:54