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

2023-11-08 13:57:07 +08:00
SimonOne  SimonOne

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

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

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

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

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

4224 次点击
所在节点   职场话题  职场话题
40 条回复
someday3
someday3
2023-11-08 16:44:31 +08:00
@SimonOne #10
不对的,测试用例是要经过评审的,跟据用例去测试。哪怕是外包团队,也会约定好测试的边界,有些细节可以忽略,则不在测试用例里。
在用例里你没测出来是你的问题,不在用例里,你非要测,大家才会抱怨你。
MJTest
MJTest
2023-11-08 16:55:37 +08:00
"我不给过项目延期从而背锅"
无法理解
SimonOne
SimonOne
2023-11-08 16:56:51 +08:00
@codeself #18 因为这就和外包项目成员的奇葩处境有关了。
乙方的项目组领导其实本质上是不关心实施质量的,其实上线前更多关心能不能完成阶段里程碑(里程碑的时刻点又不是由分解的工作量决定的,有时为了抢到单子就会答应一些离谱的工期),上线后更多关心能不能收到钱(这时候才和质量有一部分关系)。
所以在测试时,此功能测的业务场景丰富了,人天投入多于预期了,这类领导的想法(上线前)是“你测的那么细干嘛,能上就行了,项目成本增加了,锅在你测太多”,所以测试背锅;那么如果你测试的业务场景稍微只覆盖常见的几个,按期上线了,出生产 BUG 了,这类领导的想法(上线后)是“都是你测得不够完备,影响交付质量了,锅在你测得不够细”。
你明白了吗,这是很多 to B 的外包项目的现状,毕竟分锅的人又不会那么客观去分析,他想的是多收钱少承担成本。
SimonOne
SimonOne
2023-11-08 17:00:32 +08:00
@someday3 #21 在外包项目中,一切都可以省的,我当然明白锅不在我,用例要评审,开发要了解业务。
可是实际实施时,什么都可以节省,什么都可以越过。我要能决定/项目组成员各个角色都完美完成工作,我就不苦恼这开发质量这么差无法进行测试了。😂
kristofer
kristofer
2023-11-08 17:17:47 +08:00
@SimonOne #23 为什么会压到你身上呢,我按照你的描述来看,其实你就是负责背锅的。是你比较好欺负吗,不行跑路吧。
kristofer
kristofer
2023-11-08 17:19:24 +08:00
@kristofer #25 项目失败了总要有一个人背锅,但是这个人却总是你,这是让人无法接受的。干他丫的。
Erroad
Erroad
2023-11-08 17:23:05 +08:00
背锅的岗位要么跑,要么躺平接锅嘛,干点别的,准备面试,学外语,实在不行就刷 v2 划水
SimonOne
SimonOne
2023-11-08 17:25:04 +08:00
@zhazi #16
1.确实正常做法是我应当介入,但是实际这份文档是 10 月份编写的,而我是 11 月进场的,这就很无力了。
2.业务边界无啊,这种赶工外包项目,业务细节都只在项目组成员的脑子里,那几位的说法都在我进行测试过程中变化呢。(一会说离职再入职得复用旧工号,一会说离职再入职得分配新工号,那么测试的场景都在测试过程中变动呢,我真的无法掌控这些变化啊)
qingshui33
qingshui33
2023-11-08 17:27:04 +08:00
开发没有意识到某些业务场景下有问题,我个人感觉开发有一定的责任,但并不是主要的,站在我现在的工作环境来说,每个人负责一部分,不了解整体的业务或者历史的感觉也情有可原,但不是一点责任都没有。

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

上述表达全是以我当下的工作环境为基准
SimonOne
SimonOne
2023-11-08 17:28:54 +08:00
@kristofer #25 😂确实后入场的更容易背上锅,因为在领导看来,明明定好的逻辑定好的功能(他们认为开发完成到测试之前就已经酸完成了,测试只需要一点点时间和修改就可以了,重心要投入到下一个功能的开发上去了),为什么你进场就要求改呢(改要时间成本和金钱成本的,打乱原本就紧张的计划的)。
SimonOne
SimonOne
2023-11-08 17:39:47 +08:00
@qingshui33 #29 确实,我目前看下来,整个项目做成这样啊,主要原因就是实施时间不足,里程碑定的是 12 月初上线,而按照目前我了解的工作内容来说,定到 2 月 1 号都很赶了,所以整个项目风气就是业务细节了解不充分就开始干活。
sap 项目的话,有些业务细节对后续方案的影响是很大的,比如就拿离职再入职是否复用旧 id 来说,就严重影响所有的人员信息入职、异动、离职、和七八个外围系统增量全量同步的接口、所有的人事信息查询接口、所有的人头相关报表的取值逻辑。只要他们变一下说法,那么这些都得重写。

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

说到底,都怪 PM 和销售。
wildman9527
wildman9527
2023-11-08 17:43:37 +08:00
OP 既然是 QA ,那就把测试用例写写好,问题自然就测出来了啊!
SimonOne
SimonOne
2023-11-08 17:49:17 +08:00
@wildman9527 #32 问题在于,这个测试用例不是固定的(说点难听的,PM 到时候逼急了,不测直接上生产都有可能),我不就在平衡“测试用例的场景丰富度”上犯难了吗。
我写的多了要背影响上线进度的锅,写的少了要背影响功能稳定性的锅。测试过程中,业务还在变化,给的 deadline 却不变。

我真的要裂开了,除了跑路别无他法。
qingshui33
qingshui33
2023-11-08 17:50:42 +08:00
@SimonOne 哈哈哈,这种的感觉需要在需求评审的时候就把能想到的场景说出来看看怎么沟通,其他的就多提 bug 或者让开发多熟悉业务,(不过我猜开发也不希望提太多的 bug ,如果要统计开发 bug 率的话 😂)
tool2d
tool2d
2023-11-08 18:13:53 +08:00
如果测试出来,一切业务情况下,会影响系统稳定性,那肯定要修改的吧。

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

等到了项目大后期出问题,那时候修改起来会更麻烦。
SimonOne
2023-11-08 18:27:20 +08:00
@tool2d #35 我是这么想的,如果出问题了再改,数据治理很麻烦(有些覆盖了也没法轻易恢复,basis 说的是 sap 恢复只能全机回滚,那存档后的数据又丢了)。
所以我测试一般都以理论上能出现的操作进行的,奈何这个项目的开发质量经不起我的这个测试法啊。我稍微了解下业务后,提出了一些特殊场景,都是没覆盖的😅。
tool2d
2023-11-08 18:34:32 +08:00
@SimonOne 你们这个项目那么搞,绝对有屎山的潜质。

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

这种工期短,项目紧的,就注定成功率很低。你一个人急也没用,开发自己都不急。
SimonOne
2023-11-08 18:42:18 +08:00
@tool2d #37 确实,我现在急了也没用,PM 都不急,我自己急也徒耗心力。
我刚也问 PM 了,到底我要覆盖多少场景才算测试 ok ,还是说我只要持续测试直到上线能覆盖多少是多少。
他默认后一种,笑死了。😂
SimonOne
2023-11-08 18:56:25 +08:00
@tool2d #37 其实我这一行做功能设计的,大都没有软件工程的底子,做出来的东西都是健壮性低耦合度高可拓展性低的功能。
我是很抵触这样的(一方面觉得这样不道德,别人花了钱交付一坨垃圾;一方面是,有时候会运维到这样的项目,觉得实在是恶心),但是我不是领导没法去改变什么。

有些项目是我一个人做 PM 和实施的,我就要求领导别给我配开发了,我自己兼了,反而全包干下来功能代码都能跑得很好。因为我自己设计自己开发,只要别人 20%的人天就能做完不加班(当然会搭配摸鱼/看技术文档,看起来每天都在满负荷干活🙈),干起来也很轻松;交付给客户时,有些 It 出身的甲方也说说我代码思路很清晰,考虑了很多纯业务或者纯开发都不会想到的检查。
这么一来更不适应和不懂业务的开发做项目了( sap 开发理论上都是跟模块的,按理应该至少是了解通用的模块业务的)。
someday3
2023-11-09 13:47:21 +08:00
@SimonOne #24
你要完美主义的东西,肯定是去顶级的团队啊,你在外包团队搞什么完美主义。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/989852

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX