互帮互助 不通知组员情况下,测试 leader 是否有权限修改组员的测试用例?[关于测试平台权限调研]

zailushang · August 22, 2018 · Last by safin9527 replied at August 29, 2018 · 2499 hits

强调一下:是功能测试用例
**最近在公司碰到一个问题,部分测试leader希望有权限,直接修改组员的功能测试用例(在不通知组员的情况下)。

备注:

  • 我们平台原则上,测试用例只有测试输入者可以修改,别人只有查看和复制case的权限,没有修改权限。
  • 用例输入者离职后,会把权限给交接者

请问:大家公司的测试平台,不通知组员的情况下,测试leader有权限直接修改组员的测试用例吗?

做一个小调研,希望大家可以多多帮忙,留言格式为:公司+可以/不可以+职位+理由
比如:猎豹移动+不可以+测试工程师+需要尊重别人的劳动成果,而且组长修改的不一定更好

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
最佳回复
zailushang 回复

所以这类问题我的理解是可以修改,但是不建议修改(也就是有修改权限)。也许领导只是想改个错字而已……

推荐的流程是:leader写备注并@该用例所有人,提出修改意见 ——》 用例所有人收到通知 —— 〉执行修改或驳回、忽略。

leader的修改意见不一定正确,用例优化/修改也应该有评审——code review

共收到 35 条回复 时间 点赞

XX公司+不可以+测试工程师
理由:测试leader直接修改case:
1、容易导致混乱,虽然有修改记录
2、容易写成更差的case,组长写出来的case不一定更好,如果不好,组员没有组长的勇气,可以直接改回来
3、容易伤害测试组员的自尊心

不可以,可以增加留言功能。leader如果觉得组员的用例有问题,也应该让组员认识到并且自行修改达到要求

jacksonchina 回复

同意

可以+QA Engineer

victor 回复

谢谢修文,可以说明一下理由吗?

zailushang 回复

为什么你会知道我的名字。。。。

case不属于个人,谁都可以改,至于改了没有通知原作者,这是流程的问题。

同意可以修改
从系统角度来开 可以不可以修改是权限控制的问题
修改完成后的 日志 痕迹 内审等是 健全的问题

但,话又说回来,用例管理的软件很多,可以参考
如果系统只限于内部使用,完全可以内部调研搞定

用例评审不就解决这个问题了吗

我问问 回复

涉及到用例优化的问题,评审也不一定一次就最优

白纸 回复

属于测试平台,有很多业务线使用,问题是:测试leader有权限直接修改组员的测试用例吗?

中冶赛迪+不可以+测试工程师+1、对测试工程师没有最基本的尊重;2、即使是leader在细节方面信息不一定比专门负责该模块的测试全,贸然改很容易出事;3、这个先例一旦开始,就会出现研发老大随意私下改代码,公司老板任性一键删库跑路的案例了

victor 回复

关注你很久了

zailushang 回复

知道你得问题,从系统权限设计出发,高级权限对应的功能多,开不开 用不用是流程问题.
不是尊不尊重成果的问题,别上升到道德绑架
而且,大部分作为leader 不会自己修改,会安排测试工程师修改

有米钱包-----看情况而论-------测试专家
一般情况:不可以😡 .
紧急情况:可以修改,但是需要注明修改了那些地方.并通知用例输入原作者😋

因为修改失败了,就变成了原创了😂 😂

丁香园---不可以---测试经理
可以当面/微信/邮件,也可以测试用例的留言或做备注标识等,但不能直接修改,这是对别人起码的尊重,不管别人的输出有多渣。
而组员根据leader的意见进行修改,对自己编辑用例的能力也是一种提高

longbow 回复

谢谢,冯大辉是我偶像,虽然他走了

这个测试leader很闲。。。。。。

autowang 回复

我们要做一个测试平台,目前部分需求还在调研中,这是其中之一

这个问题其实是两个问题。
1.能否有权限修改,这是系统设计问题。
2.需不需要通知组员,这是工作流程问题。
从个人角度觉得,测试平台可以有这个修改的功能,但是在流程上要规定清楚,并且修改后应该有对应的修改记录,针对case要有版本控制。
------分割线------
讲下个人工作体会,实际执行case过程中,我会发现一些case有问题:
1.比如就是一些简单信息需要更新,case不需要大的改动,我会对creator说一下,然后自己直接去修改case,我们team用的testlink,case有版本控制和修改记录,我觉得这样效率最高。
2.如果这个case逻辑或者需要大的改动更新,我会让creator自己更新,讲清楚需要更新的原因。

不可以+测试
测试leader可以有修改权限,但必须要通知组员,如果在不通知的情况下出了问题,谁来负责呢?
我赞成刚才楼上的回答,这是两个问题,一个是系统设计,另外是工作流程。
在我们使用脉冲云产品的时候,整个系统中的设计是分权限的,可以给leader权限,让其有权限管理组员任务,发现问题并修改team相关任务时,关联的修改记录以及历史版本都有存留,同时脉冲云的系统功能在leader修改时,消息推送到组员查看任务修改的地方,同时了解到为什么修改。其实,在team合作中,这样即使对组员的尊重,也在一定程度上帮助了组员。团队协作相当重要!

xx公司+看情况+测试
系统的设计上觉得可以有这种权限
实际项目开展中,一般测试领导应该不会主动修改

xx公司+可以+测试开发

  1. 用例不是个人产物,是团队结晶。团队内的人都应该开放权限修改,有需要就可以优化。
  2. 至于是否适合修改,那是约定,但没必要通过系统权限这种机制来限制死。
  3. 用例的每次修改后应该都保留一个版本,如果新的修改不合适,可以随时切换回修改前的版本。
  4. 考虑一个场景,leader 给老大演示用例,发现一个明显错别字想立即改正,但却没有权限,多尴尬。。。

而且说实话,leader 没有合理理由就擅自修改用例,这个问题是 leader 的问题了。即使系统限制了,他还是会找你开通权限的,这种限制作用并不大。

一般情况下,是由leader通知组员进行修改的,但是打了招呼是可以修改的,再说了修改面一般不大,如果修改面比较大估计就得分工了。

可以的前提:管理者要知道每天的创建、维护用例变化,并且系统有地方记录变更的原因、人员、时间。

24Floor has been deleted

测试还需要测试用例吗😀

狼图腾 回复

我只能说,当事情达到一定复杂度的时候,肯定需要写写画画、整理规划。
如果你觉得你的工作只需要想一想思考思考就可以完成,那你的工作肯定还不够复杂

XX公司+可以+测试,可以修改测试用例,但是一定要和组员讲明修改的理由。当然,哪个组长会这么闲啊,一般都是直接用例评审,有啥直接说的

每次看到类似这样的问题,顿感头痛.
等同于:红灯亮起,应该闯过去吗?神智清楚的,基本会回答"不会".但实际呢,闯灯的行人/自行车那么多(原因别深究了).
还有,劳动者的8小时工作如何保证,在吃饭养孩子的前提下,你敢去找领导正面怼么.
现实的无奈就是如此.

有装糊涂的领导,真糊涂而且固执的领导,精明的领导和不识时务的手下,就是一场闹剧。
另外我觉得滴滴纵然做的不好,但当了终极替罪羊,也真是够呛

hellohell 回复

哈哈,这个跟滴滴什么关系啊

zailushang 回复

现在黑DD已经什么都可以往上靠了😏

换个角度,开发leader可以修改组员的代码吗?

edsion 回复

对,同理不同事

zailushang 回复

所以这类问题我的理解是可以修改,但是不建议修改(也就是有修改权限)。也许领导只是想改个错字而已……

推荐的流程是:leader写备注并@该用例所有人,提出修改意见 ——》 用例所有人收到通知 —— 〉执行修改或驳回、忽略。

leader的修改意见不一定正确,用例优化/修改也应该有评审——code review

edsion 回复

好的,自认为最佳答复,棒

我觉得应该是可以修改,但是改了之后要邮件通知用例所属人

领导有权限修改,但是发现用例问题应该提醒组员自己去维护

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up