狗屎DIAG开发，谢谢你，把我周一上班的心情直接打倒最低点。
写的新版本DIAG变更用例设计方案，找他核对，结果一共五条，他指摘的四条是项目流程问题，而不是内容本身，最后一条就是嗯蹭说有问题。
仕样澄清，B152C96、B152C87香氛DTC的记录条件以香氛仕样为准。（不影响实装）
仕様明確；フレグランスDTC：B152C96、B152C87の記録条件はフレグランス仕様要求に準拠する。（実装に影響ない）
首先香氛DTC变更的式样是这么写的，然后我先去翻了最新DIAG DTC的式样，发现没写具体内容。然后我又去翻香氛的所有正规式样，也没发现具体内容。
接着我搜索Q&A票，发现有这么一张写着香氛DTC变更内容的QA票，然后我又那这票问另一个DIAG开发，得到承认之后去按照这上面的变更点去进行设计。
结果他不信，让我去搜这个项目和其他项目的最新DIAG式样，发现还是变更前的内容，然后又让我搜香氛式样，也没搜到。按道理来说最后这张变更的QA票就是最正规的参考内容了，但他又觉得我的流程不对：就算式样翻了没找到，你找到变更相关的QA票，又去问了开发也不能保障是对的，还要去问SL( ˇωˇ)
那我寻思你这狗开发干什么吃的，自己模块的式样变更自己不知道还要让我这最底层的测试去问需求管理，我不好说。最后三个相关的测试点被指摘流程问题
另一个副无线充电相关的DTC，式样上很明确写了从支持该DTC到不对应，正常来说按照这个DTC的触发方式再执行一遍确认该DTC不出来就行了。结果他说：代码没变，只是这个机型不支持副无线充电的硬件了，相当于不会有发送该报文的场景。所以你发这个报文再停止发送这个DTC还会触发，所以你设计的测试方案也有问题。
我：那你的意思是这条式样和测试流程以及代码变更部分也有矛盾，我也要去问QA吗( ˇωˇ)
他：是的，你不能我说什么你信什么，你们必须要和SL核对。
本质上SL和开发和PM才是直接沟通的关系，式样问题你负责这个模块的开发就应该去和SL核对到底哪有问题哪没问题，而不是我这个最底层的测试跨级去找SL。反正到现在，我对这弱智项目的垃圾印象的一半都来源于这种问他问题他嫌烦，自己琢磨他又觉得不对的脑残开发。
