这问题蛮有趣的
我问了一个在微软跟亚麻做过的业内人士 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出去