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

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

同意

可以 +QA Engineer

谢谢修文，可以说明一下理由吗？

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

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

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

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

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

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

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

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

关注你很久了

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

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

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

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

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

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

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

这个问题其实是两个问题。
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 通知组员进行修改的，但是打了招呼是可以修改的，再说了修改面一般不大，如果修改面比较大估计就得分工了。

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

测试还需要测试用例吗

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

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

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

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

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

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

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

对，同理不同事

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

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

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

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

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

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