這問題蠻有趣的
我問了一個在微軟跟亞麻做過的業內人士 A關ticket本身有沒有問題
她回答:
non-reproducable其實蠻常發生的，對方又不肯合作釐清問題，除了關ticket還能怎樣
處理過ticket就會知道，很多確實是開ticket的人自己搞崩,不在狀況內,內容寫得不清不
楚 之類的
B看到ticket被關正確做法是reopen並找Ａ的manager
最後還是需要B的協助debug
這根本主要就是B的錯吧

雖然說bug是A寫出來的沒錯 但以A的角度來說當下也沒其他能做的事了吧 依照設定的環境就是測到死都測不出來沒辦法重現的bug是要怎麼修 也只能猜猜看一些懷疑的地方至於切close或是切non-reproducable或是切keep tracking講白了也差不多 橫豎都是放著不會再有人去動他除非QA後來又測出類似的問題才會reopen

A的bug被B不小心測到，B也不是QA只是隔壁部門拉來做整合的工程師，干B屁事你做一個sdk給別人用，別人不小心測到資料毀損問題跟你講，你說你沒什麼可做的，笑死，誰有空幫你找你的問題今天bug不是一個畫面會當掉還是會出現什麼奇怪錯誤訊息，是會把資料刪光，然後一直跳針說”我無法重現”、”你們發現問題的人沒把步驟說清楚“、“規格不明確“這種程度好意思說自己是工程師？笑死客戶資料被你刪光的時候你是不是也打算跟客戶說，你的環境有問題，你怎麼發生的步驟跟我說清楚，否則我無法重現我沒什麼可做的，這樣也能當工程師？笑死

呃，實務上應該大部分作法都是你最後這三行講的。客戶不願意配合的話，九成九就只能羅生門卡關。不能復現的Bug常常要靠天眼通...

關ticket的人要負責任啊，A就應該竭盡所能去重現他，直接殺到B那邊借機器測，借個一小時就能發現問題了，真的無法重現才能關。但刪資料這麼大條的事應該要整個team下去追，A就傻傻的自己測，B也沒權力叫A做事，然後A的同事們也不知道在哪0.0a

原PO有說他(Owner)和A去找B，對方不配合。這大概牽涉到內部人際關係，公司文化改不了無解。只能每次出包每次找人砍頭了事。

我是覺得B不想配合也一定有什麼原因。如果AB主管都介入的話，應該在一天內就解決了不過原po最後也負責救火了，所以老闆也沒火任何人let itgo~

每間公司的流程不一樣，能這樣套喔？跟微軟與亞麻的流程就是錯？如果該公司沒規定reopen原則。B沒有reopen，你不能說他錯啊。另外，請你去問一下你認識的業內人士：為什麼B開的ticket,，A可以有權限關閉？哪套系統可以做到？

B不配合原po第二篇有解釋 B也要開發code 沒辦法借機器給A測 A部門自己要想辦法吧 一直怪B不配合

回答這啥東西？ 這位大概也不是負責人是甩鍋PM吧

結論亂下…你要不要再跟你的朋友討論一下 人家怎麼做

B是別team的也不是QA，誰會沒事去 reopen

不能複現的bug A B都要想辦法找對方去把bug複現 bug不會自己消失 實務上B要多嘗試一點 因為A寫底層的不可能每種usage path都能驗過 既然B有發現過bug表示在B的環境下容易出現 他要提供一些相關資訊或環境讓A容易去抓到問題

B也是工程師阿 又不是客戶? 客戶不肯借出問題的機台給原廠找問題也是滿神奇的

A寫的code要B多努力找bug? B只是來支援的 今天沒有B A怎麼辦?另外A部門也有QA A的code應該也是請QA多找bug吧 B也要寫code幫A找bug 自己的事都不用做了嗎

關B闢室...看下R&R的定義好不好

推jamesho8743

看來brucetu很適合當全端+PM工程師 如果都要一個人去釐清全部問題那還要分工做什麼... 一個人幹甚至都不太可能出現這問題 因為非常接近客戶對B要求主動與要求A主動同樣都是奢求B就不是來支援的 是同個需求的前台 到底有沒有看懂?需求是兩個部門的事情怎麼會只跟一個部門有關...現在公司就是沒什麼制度 issue的close與reopen完全不是重點 而且我也覺得追蹤平台不應該這麼用 會被當作鬥爭與推責任的手段事情大條分時段知曉 不同部門不同 B是一開始就知 而A爆發才知道 本來就驗沒問題你是要怎麼知道就是有這件事情猛追?要怎麼知道就是有這問題才猛追?要求A歸咎A的人其實是在上帝視角看事情 這件事情B知道更多說到這問題就不得不提到之前的文 省的是主管的心底下的人戰戰兢兢深怕被貼上"沒誠信"的標籤是很恐怖的

微軟open source就一堆亂關的呀XD 客服工程師講幹話就關掉,問題連查都不查, 別以為大公司每個部門都有紀律

B 開的ticket A能關 這不是一堆都能這樣嗎 MS Azure devops 、Aws用的JIRA

不同公司不同制度吧，A當然可以在自己主管同意下以can not reprocedure close，只是在跟B不同的測試條件下以can not reprocedure close 本身就存在風險，不同測試環境條件下常常無法重現問題這是很常見的事，公司制度允許這樣的風險那A就沒錯，不允許那A跟原PO就有錯。測試環境ㄧ事B因為手中環境要用不能給A，B有錯嗎 制度不同看待也不同，在這事件看起來A跟原PO認B的錯也許這家公司制度就是這樣。至於B基於什麼理由把code推進去這是另外一件事後者影響不到前者 。QA在這事件的角色是什麼 A+B code release 最終測試者還是問題複測者，後者的話原PO說法B沒在report寫明測試環境跟步驟，那麼QA怎麼知道要測什麼？，前者的話那麼 A 跟原PO 在客戶出包前是認爲A 沒錯是B環境有問題，認為B 所謂測試A 的code有問題是不存在的事，那麼 B release code 一事對 A 跟原PO 來說不存在說B把A有問題的code release出去給客戶，B是對公司來說有責有錯，公司可以罰B 但原PO 事後上來PO文針對B release 一事說不過去，出包前只相信A從未相信過B的測試何來說B release 有問題code出去