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

我是原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