看了开发的代码就不想测了咋整

[SimonOne]

主要做 SAP 顾问，会看 ABAP 代码和写一些 ABAP 面向过程。

最近一个项目，编写设计文档的同事和开发的同事在设计和实现的时候没有考虑很多特殊业务上的场景以及异常的处理。 现在让我进行测试，我看一眼代码就不想进行测试了 T_T ，粗略一扫就能发现很多值得吐槽的代码，如果我是 code review 的人，我肯定要求全部重构（可惜外包 HCM 项目根本不存在什么 code review ）。

我也不知道该怎么让开发意识到某某业务场景下他那样的写法是存在 bug 的（因为他不懂业务仅负责实现所以业务细节一点不知道），而仅仅把 bug 报给他呢，他又会加上自己的理解修改并引入新的 BUG 代码同时复杂度飙升。 如果让写设计文档的同事去说呢，又说不清，因为实际我是通过代码看出来 bug 的，设计的同事又不明白代码实现的事情，即使我从业务的角度和设计的同事说明白，他也不知道该怎么改，于是又是我说一遍他和开发有损复述一遍，然后开发修改并引入新的 BUG 代码同时复杂度飙升。

要么我直接通过测试，然后因为我已知的 BUG 导致上线问题从而背锅； 要么我不通过测试，然后因为我不给过项目延期从而背锅； 要么我自己去重构一遍，可工作量很大，并且我还得从头问一遍业务上的细节，PM 无法理解我这种重复造轮子的行为。

PS：我们这种 SAP 实施项目，人员角色分工是很模糊的，所以权责也是很模糊的，所以懂的越多→操心越多→别人不理解你为什么要操那个心越多。

[someday3]

别给自己加戏

”要么我不通过测试，然后因为我不给过项目延期从而背锅；“
为什么你不通过测试，还要你背锅？按照你的写法，你不是顾问啊，你是总监啊！

[K332]

把 bug 报给他呢，他又会加上自己的理解修改并引入新的 BUG 代码同时复杂度飙升。

有新 bug 继续提就是了，只要不影响工期，有什么关系

[SimonOne]

@someday3 #1 所以说做乙方时，就是这么尴尬和难受，我做久了懂太多了就得承担起不属于我身份的职责，这在我这行很常见。

[mofeimofei]

开发必须理解业务，甚至要比产品更懂业务。如果开发不理解业务你的问题无解呀。

如果只是测试的话提好 bug 就行了，如果为结果负责，那需要尽快跑路。

[SimonOne]

@mofeimofei #4 确实，我也觉得开发不懂业务是无解的（所以有些项目我都要求不要给我配开发了，还不如我自己写😂）。觉得该换个工作了。

[wonderl17]

写用例，根据用例判断是否通过。

[someday3]

@SimonOne #3
你还是没有正式回复我的问题啊，为什么你不通过测试还是要你背锅，测出来 bug ，改不过来，肯定不是你的啊！！
如果说最后延期不通过也是你的锅，那你肯定是项目负责人，不是顾问。如果说你没有决定权，却要对项目负责，那根本不可能！！

[silencil]

测试实际上是对产品负责，产品给的需求逻辑中，测试用例覆盖全面了，执行完毕再出了问题和你测试就没关系。没考虑到的 case 如果不是产品的问题那就是开发的问题，和你有什么关系呢？

[silencil]

如果是测试用例根据产品需求覆盖不到的 case ，说明你发现了产品的需求逻辑问题，那你报给上级或者产品或者开发去调整就行，完全轮不到你背锅才对。

[SimonOne]

@someday3 #7 因为你的项目组成员都是正常人，但是在外包 hcm 项目这种，原定 2 天的排期怎么延期→xx 不给过→xx 的错，你为什么要测那么多细节；功能上线怎么 bug→xx 测的→xx 的错。

[SimonOne]

@someday3 #7 这两个组合拳下来，xx 测试就只能祈祷虽然我没测那么细但是上线可别出大 bug 啊。

[SimonOne]

@someday3 #7 😂所以你能理解我为什么看了代码就不想继续测试了吗，我就像 rick 和 morty 里拿到了死亡水晶一样，可以提前看到自己注定死翘翘的结局了，那我还能开心得起来吗。

[fregie]

你是顾问，既不是开发也不是测试，所以如果是软件 bug ，不该是你背锅。
不过依我猜测你所谓的 bug 可能不是 bug ，而是需求提出的时候场景就没考虑完善，给出了不完整的或者模糊的需求，所以再产品逻辑上有 bug 而不是代码逻辑上有 bug 。如果是这样就并不是开发和测试的锅
这种情况你作为顾问本来就是你的锅（ SAP 里的顾问其实就是理解收集用户需求并且给开发提需求的角色吧）
如果我猜错了就当我没说。

[rrfeng]

我，SRE ，看到某些代码，也有同样感觉。

[darkengine]

真如你所说, 那么测试的时候肯定能测出问题, 测试自然通过不了.

测不出问题只有两种可能, 一是测试用例没覆盖全, 二是代码有问题是幻觉.

[zhazi]

编写设计文档的同事和开发的同事在设计和实现的时候没有考虑很多特殊业务上的场景以及异常的处理。
1.提前介入
我觉得你既然是顾问，就需要在编写设计的文档的时候参与进去，提前将特殊业务场景，用户故事交付到文档。
2.划分测试边界
只保证业务流程相关问题。像边界值，像 happy path 都由研发去负责
3.选择正确的角色
（要么我自己去重构一遍，可工作量很大，并且我还得从头问一遍业务上的细节），从这句话看出你连自己的定位也没分清楚，测试可以戴多顶帽子，产品，用户，运营。但裁判不会下场当运动员的。并且重构不是为了消灭 bug ，而是让 bug 暴漏出来。

[WilsonWenJ]

我在甲方做 SD 模块的，还好我们内部的开发是个优秀的伙伴

[codeself]

"我不给过项目延期从而背锅"为什么是你背锅?怎么可能是你背锅?

[SimonOne]

@fregie #13 确实场景和边界条件考虑不全的锅是顾问的，但是这个顾问不是我，而在外包项目中，PM 可能本身就不达标，他只会将导致延期的锅放到阻碍力最大的人身上，那么调研的顾问、设计的顾问和开发的顾问明显是推动力，而阻力就变成了测试的顾问。
我和在座的各位 V 友当然分得清是调研和设计时考虑不周全导致的，但是整个项目组没有这么清晰的领导者，我想我没别的办法挽救了只能跑路了（当然项目能不能上不看质量，我们的 PM 能诓住客户的话，还是能上的）。

@zhazi #16 其实大部分外包项目都是草台班子，没有那么严格的实施方法论啥的。
从定位上分析，确实我是实施顾问，只负责根据调研文档进行配置以及编写增强功能的功能分开发说明书（以及测试），但是我们项目成员的目的还是能做好实施并上线（拿到钱跑路），在这个前提下，每个顾问都会承担一些本不属于自己的职责。
我很难解释为什么我要自己开发，因为这是很多个因素导致的。
但是如果有这么两个选择放在面前：1.自己开发+测试，1 天搞定无 BUG 上线稳定运行 2.他人开发我测试，来回修改来回重测，一个星期搞定上线偶有 BUG 。
我还是会选 1 的，纯粹是我不想因为别人的（拉胯）能力浪费我的生命。

[blackkkk]

你是项目负责人？你是领导？
不是的话做好自己的活就行，别给自己加戏