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

[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]

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

[someday3]

@SimonOne #10
不对的，测试用例是要经过评审的，跟据用例去测试。哪怕是外包团队，也会约定好测试的边界，有些细节可以忽略，则不在测试用例里。
在用例里你没测出来是你的问题，不在用例里，你非要测，大家才会抱怨你。

[MJTest]

"我不给过项目延期从而背锅"
无法理解

[SimonOne]

@codeself #18 因为这就和外包项目成员的奇葩处境有关了。
乙方的项目组领导其实本质上是不关心实施质量的，其实上线前更多关心能不能完成阶段里程碑（里程碑的时刻点又不是由分解的工作量决定的，有时为了抢到单子就会答应一些离谱的工期），上线后更多关心能不能收到钱（这时候才和质量有一部分关系）。
所以在测试时，此功能测的业务场景丰富了，人天投入多于预期了，这类领导的想法（上线前）是“你测的那么细干嘛，能上就行了，项目成本增加了，锅在你测太多”，所以测试背锅；那么如果你测试的业务场景稍微只覆盖常见的几个，按期上线了，出生产 BUG 了，这类领导的想法（上线后）是“都是你测得不够完备，影响交付质量了，锅在你测得不够细”。
你明白了吗，这是很多 to B 的外包项目的现状，毕竟分锅的人又不会那么客观去分析，他想的是多收钱少承担成本。

[SimonOne]

@someday3 #21 在外包项目中，一切都可以省的，我当然明白锅不在我，用例要评审，开发要了解业务。
可是实际实施时，什么都可以节省，什么都可以越过。我要能决定/项目组成员各个角色都完美完成工作，我就不苦恼这开发质量这么差无法进行测试了。😂

[kristofer]

@SimonOne #23 为什么会压到你身上呢，我按照你的描述来看，其实你就是负责背锅的。是你比较好欺负吗，不行跑路吧。

[kristofer]

@kristofer #25 项目失败了总要有一个人背锅，但是这个人却总是你，这是让人无法接受的。干他丫的。

[Erroad]

背锅的岗位要么跑，要么躺平接锅嘛，干点别的，准备面试，学外语，实在不行就刷 v2 划水

[SimonOne]

@zhazi #16
1.确实正常做法是我应当介入，但是实际这份文档是 10 月份编写的，而我是 11 月进场的，这就很无力了。
2.业务边界无啊，这种赶工外包项目，业务细节都只在项目组成员的脑子里，那几位的说法都在我进行测试过程中变化呢。（一会说离职再入职得复用旧工号，一会说离职再入职得分配新工号，那么测试的场景都在测试过程中变动呢，我真的无法掌控这些变化啊）

[qingshui33]

开发没有意识到某些业务场景下有问题，我个人感觉开发有一定的责任，但并不是主要的，站在我现在的工作环境来说，每个人负责一部分，不了解整体的业务或者历史的感觉也情有可原，但不是一点责任都没有。

感觉主要应该是需求的责任吧，需求对整体的业务各方面的流程应该是最为熟悉的人，再者测试对整体的流程熟悉感觉也是正常的，因为测试大多数情况下都是从头走到尾。

上述表达全是以我当下的工作环境为基准

[SimonOne]

@kristofer #25 😂确实后入场的更容易背上锅，因为在领导看来，明明定好的逻辑定好的功能（他们认为开发完成到测试之前就已经酸完成了，测试只需要一点点时间和修改就可以了，重心要投入到下一个功能的开发上去了），为什么你进场就要求改呢（改要时间成本和金钱成本的，打乱原本就紧张的计划的）。

[SimonOne]

@qingshui33 #29 确实，我目前看下来，整个项目做成这样啊，主要原因就是实施时间不足，里程碑定的是 12 月初上线，而按照目前我了解的工作内容来说，定到 2 月 1 号都很赶了，所以整个项目风气就是业务细节了解不充分就开始干活。
sap 项目的话，有些业务细节对后续方案的影响是很大的，比如就拿离职再入职是否复用旧 id 来说，就严重影响所有的人员信息入职、异动、离职、和七八个外围系统增量全量同步的接口、所有的人事信息查询接口、所有的人头相关报表的取值逻辑。只要他们变一下说法，那么这些都得重写。

结果就在我测试中，我不断得向设计功能的顾问提出这个问题，他们不断得变化说法😂。

说到底，都怪 PM 和销售。

[wildman9527]

OP 既然是 QA ，那就把测试用例写写好，问题自然就测出来了啊！

[SimonOne]

@wildman9527 #32 问题在于，这个测试用例不是固定的（说点难听的，PM 到时候逼急了，不测直接上生产都有可能），我不就在平衡“测试用例的场景丰富度”上犯难了吗。
我写的多了要背影响上线进度的锅，写的少了要背影响功能稳定性的锅。测试过程中，业务还在变化，给的 deadline 却不变。

我真的要裂开了，除了跑路别无他法。

[qingshui33]

@SimonOne 哈哈哈，这种的感觉需要在需求评审的时候就把能想到的场景说出来看看怎么沟通，其他的就多提 bug 或者让开发多熟悉业务，（不过我猜开发也不希望提太多的 bug ，如果要统计开发 bug 率的话 😂）

[tool2d]

如果测试出来，一切业务情况下，会影响系统稳定性，那肯定要修改的吧。

软件系统是拿来用的，又不是拿来看的。

等到了项目大后期出问题，那时候修改起来会更麻烦。

[SimonOne]

@tool2d #35 我是这么想的，如果出问题了再改，数据治理很麻烦（有些覆盖了也没法轻易恢复，basis 说的是 sap 恢复只能全机回滚，那存档后的数据又丢了）。
所以我测试一般都以理论上能出现的操作进行的，奈何这个项目的开发质量经不起我的这个测试法啊。我稍微了解下业务后，提出了一些特殊场景，都是没覆盖的😅。

[tool2d]

@SimonOne 你们这个项目那么搞，绝对有屎山的潜质。

未来代码一旦复杂起来，开发应该是先跑路的，留下一堆 BUG ，面条一样的代码绕来绕去，后人无人敢动。

这种工期短，项目紧的，就注定成功率很低。你一个人急也没用，开发自己都不急。

[SimonOne]

@tool2d #37 确实，我现在急了也没用，PM 都不急，我自己急也徒耗心力。
我刚也问 PM 了，到底我要覆盖多少场景才算测试 ok ，还是说我只要持续测试直到上线能覆盖多少是多少。
他默认后一种，笑死了。😂

[SimonOne]

@tool2d #37 其实我这一行做功能设计的，大都没有软件工程的底子，做出来的东西都是健壮性低耦合度高可拓展性低的功能。
我是很抵触这样的（一方面觉得这样不道德，别人花了钱交付一坨垃圾；一方面是，有时候会运维到这样的项目，觉得实在是恶心），但是我不是领导没法去改变什么。

有些项目是我一个人做 PM 和实施的，我就要求领导别给我配开发了，我自己兼了，反而全包干下来功能代码都能跑得很好。因为我自己设计自己开发，只要别人 20%的人天就能做完不加班（当然会搭配摸鱼/看技术文档，看起来每天都在满负荷干活🙈），干起来也很轻松；交付给客户时，有些 It 出身的甲方也说说我代码思路很清晰，考虑了很多纯业务或者纯开发都不会想到的检查。
这么一来更不适应和不懂业务的开发做项目了（ sap 开发理论上都是跟模块的，按理应该至少是了解通用的模块业务的）。

[someday3]

@SimonOne #24
你要完美主义的东西，肯定是去顶级的团队啊，你在外包团队搞什么完美主义。