---

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

角色：

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

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



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

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


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

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

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




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

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

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

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

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







第三個錯誤，我當時對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想了一下說：1次

我說：可是你寫always耶！

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



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



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



--
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.74.78 (臺灣)
※ 作者: pokkys 2023-07-25 18:59:00
※ 文章代碼(AID): #1alwhs5d (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690282742.A.167.html