嗯，所以准备找新工作了

嗯，个人感觉是后者吧，新换了个领导

同病相怜

同样的架构调整 +1，比较难受

看团队吧。对项目影响是积极的有益的。但对个人来说，上升空间≈阻断。

以前遇到过一次架构调整，让我从测试开发转功能测试，直接试用期果断裸辞了。

我想问下测试总监的直属上级是不是 cto？还是有哪家公司的研发老大是 qa 总监和开发总监平级的。。

如果刚毕业 呆个半年还是可以的 因为可以更加接近源码 去理解里面的东西 但是不建议太久 因为有可能会逐渐失去话语权

如果开发负责人足够专业，并且能从测试角度听取意见，倒是还算 ok，不然就是个坑

其实不用太在意是不是独立，有多少所谓话语权。

如果是新人，其实不用在意。

我也是在项目里，直属领导是项目经理。整个项目，没人关心项目质量如何，测试完全被放养。仅提供个人的情况，供参考，但是觉得负责人对测试的理解和重视程度会有关系。

自主性变少了，跟人提升可能近似与 没有了，你会跟着项目不断迭代，根本没有时间 精力去弄一下 自己感兴趣的东西，并且你的小伙伴变成了开发，能跟你做一些在测试方面技术探讨和提升的人也没了，更严重的是这种模式可能小一点的项目组 就你一个测试，没个 backup 相请个假都比较蛋疼

多了机会学习很多开发的东西，丧失机会学习很多测试的东西。
所以过一段时间测试集中化，过一段时间项目化比较好。
个人觉得项目化的时间占 2/3 比较好，技术可以通过项目分享做。

是否合理没有整体业务情况上下文，不好评价。一般合并部门的决定都是从上往下整体看才能看出是否合理的，从下往上每个岗位肯定都希望有独立部门独立通道。

如果是说对测试人员是好事坏事，这个要看合并后开发怎么用。如果 leader 好，测试可以接触到很多开发的东西同时，保持测试对质量的把关权力，那是好事；如果 leader 把测试当做附属，不关心和不放权，那肯定是坏事。只是长期来说，相比有独立测试部门的，测试天花板会更低（独立部门至少还可能有总监，非独立部门估计经理就到头了，除非能力够强，连着开发一起管）。

一句话，准备找工作吧

楼上有测友认为有好处，可能未经历开发管理测试的一些场景。

举个例子，我司有个事业部只有一个测试挂在开发下面，于是场景是这样的：

开发不愿干的杂活累活脏活全部给那个测试，能提高？！

本人亲生经历过，是相当不爽的，假如想混日子，想的开，按时拿工资的话 应该没啥改变
1、测试并入开发后，测试老大就会听开发的安排，工作安排，开发哪些想测就测，想不测就不测，自测后直接上线更是常规操作
2、基本无话语权，测试老大都听开发的了 ，都不敢刚了
3、没有独立部门那么舒服，测试独立部门的时候，说这个东西有问题，说不上就不上，并入后完全没可能这种，就算有问题，也得上，完全就是糊弄鬼
4、反正没啥搞头，感觉不自由了，看个人吧

在国内，本来测试话语权就少，现在没独立部门，生杀大权全在开发手上，碰到好的开发 leader，还正常；不好的，就做脏活累活杂活吧

你应该直接跟新的项目负责人聊，看他的想法和自己的想法，是否能求同存异，相互成全，不能再说走的事。

我们这边的项目负责人没什么话语权，基本都是副总级以上的领导怎么安排就怎么来。这次组织架构调整其实也跟公司换了大领导有关，前任领导比较看重自己研发团队的培养，两年前专门成立了测试部门，现在的领导看重产品规划和营销，觉得研发外包出去做就够了，就裁撤了测试部门，当然也同时压缩了开发那边的人力资源。

我已于昨晚跟领导正式提了离职申请。这份工作也是我在北京的最后一份工作，下一份工作打算在老家找了。我还没找到下家，算是裸辞吧

深有同感！

嗯，我本人做的就是测试管理，也是因为调整后，我跟其他测试人员一样干开发分派的活儿了，没有了上升的空间了，所以一天也不想待了，当天就跟领导提辞职了

裸辞了。。。

我们这边的测试就只是测试，代码的查看权限都没有。。。

同意，新人无所谓了

哈哈，这种情况，直接走就好了，说明现在新的领导对技术非常不看重。让我想起了《凤凰项目》书里面的情节，非技术的领导，确实容易觉得技术不是公司核心竞争力之一，看轻技术。

同楼主 测试就是垃圾/都归开发管/啥也干不了/就是背锅的

我去年经历了一年这种模式，今年 6 月份离职，感觉偶尔是天堂，但时常是地狱；能更好的接触源码，覆盖代码测试比较方便，可以更好的了解业务处理逻辑；但是话语权被剥夺，测试质量无法保证，背锅是常态，战战兢兢。

你比我强多了，我一天都是煎熬，晚上都睡不好觉。现在已经提离职了，暂时不给我安排活儿了，领导人不错，让我走之前专心找找工作

原本公司想用测试卡脖子，这些年觉得卡脖子把产品卡死了，想明白了而已

那个测试也要抽空想一想，能为产品为公司为客户创造什么价值，这个要比一味的抱怨强一些。

上面已经说了很多了，我觉得我这边测试组属于工程部的，也是挺扯的，不过好处在于独立于研发和项目，只是偶尔有工程部的运维领导来指点江山，我情商高没有翻脸。

挺合理的，我们现在也是这样的架构。

本质上公司技术部门是服务业务部门，业务部门服务客户；测试与研发应该同属技术部门，只是专注点不同。测试部门可以多从业务与技术结合的角度，去追求更有效的发现产品的问题，提升研发整体效能。而且测试与研发合并的话，技术老大也可以更好的帮助研发与测试部门有效配合，提升团队整体的合作意识。

这种结合可能容易碰到的 “坑” 是 研发老大不懂测试 或者 一些研发老大可能 “看不起” 测试，觉得测试 low； 这种时候，就需要测试同学自己展现出自己的实力，用实力说话，别做 low 的事儿，提升人家对你的认可度。 当然，有些极端的情况下可能也需要你去给研发老大 “洗脑”，教会他什么是测试 …… 从而让他重视测试。

我们也一样

干的好好的，为啥要裸辞呀？

产品研发都是进度，资源，和质量之间的博弈。测试作为质量保证的一种手段，你是受到制约的。你就是其中一员，还存在合不合理的问题么？提高自己的核心竞争力，在测试的环节展现自己的才能，才是最合理的。

无所谓，都在提倡 devops，开发 + 运维，和测试有什么关系，以后就没有测试了

• 测试试的目的什么？
  测试作为质量保障的一种重要手段。

• 留存测试部门对质量保障有什么好处？
  测试话语权高，不合格质量的产品不易流出。（该产品是否需要较高的质量）
  
  测试同学有更多的发展路线，有组织交流经验技术，组织归属感更强。

• 留存测试部门对质量保障不好的？
  项目组成员交叉管理，测试同学考核权在测试部门，项目进度往往制约于测试团队，无法通过考核等手段加压。

• 去测试团队后的现象：
  去测试部门实质是去 测试经理，测试内容不减，对于基层测试人员应该是一样的，对于想在该领域寻求突破的人员来讲，不友好。
  1、核心测试骨干离职，上升通道被阻或者不明朗。
  2、测试经理离职。
  3、团队中测试的同学会越来越少，直至无专职测试。
  4、研发水平较高的同学，转岗到研发，团队内都是研发岗，研发自测。

测试组织面临常见的问题：
有些研发经理会觉得，测试做了很多脏活、杂活，“技术含量低” 的活，因此考核低很 “正常”。
如果保留独立测试团队，在考核权上 项目组人员有独立测试人员不受自己控制，项目经理估计会不爽。

未来发展：
去专职的测试团队应该是一个趋势，金融机构留存专职测试的概率比较大。
其他组织，在维持原有质量的情况下，是否可以使用外包替换，是否可以通过研发组自测，降低成本。

去测试部门，去专职测试，对于 测试同学来讲，是个短痛吧，对不喜欢做重复工作，被低级缺陷浪费时间的同学来讲，是利好。

我们可以算是一种混合模式。有独立的测试部门但是员工分散在不同的项目组，每个项目组一名测试人员。这种模式既能保证测试人员考核的公平性，又能让测试人员接触到开发的核心。这种模式下测试人员的技能得到了极大的提升，很多人从最开始只会手动测试，到负责 UI 自动化测试 + BA + 开发（如 UT）+ CI/CD pipeline 搭建 + release 流程。同时，公司也在文化上倡导 “质量是每个人的责任”，所以不只是测试人员做 UI 自动化，每个人都是多面手，有时间大家一起做测试。出色的测试人员因为其更广阔的业务视野，全面的项目流程把控和有深度的质量保证技能，在团队中得到了大家的称赞和尊重。
关于测试部门和人员的建议，我觉得有两点：
1 作为测试部门的经理，我们应该有更全面和更高的视野，给团队一个发展的方向。比如质量保障体系， devops 中测试团队的改进，产品级别的质量保障指标，多维度的质量保障等。另外，要紧跟技术发展培养员工能力，比如 chaos testing，云技术，AI 技术等。
2 作为测试人员，我们要保持不断学习的心态，跟开发学，跟业界学。让自己保持对新技术的敏感度。不断琢磨怎么提高工作效率，提高自己的技术水平。

线上漏测，就会问，为什么测试了还有漏测，这种如何应对呢

从一个小的测试组整体把控项目到把测试划分到了具体的业务线，归属到了不同的业务线，对于测试人员的整体发展基本上是弊大于利吧，但接受现实了就需要拥抱变化，拥抱了变化就变成了开发的附属

其实无论怎么调整，对于自己来说，自己的能力提升，才是最重要，只要自己够强，任他千般不化，自己也稳如老狗

和我司一毛一样，测试老大只是协调资源的，人还是跟着项目来，也难受

可能大部分场景来说测试有独立部分比较合适，但是本人亲身经历：测试老大平时没有什么卵用，只抓故障数和效能，不顾你业务多忙一味只要效能产出，搞得好像业务测试不花时间似的，也不会多给你资源，以便完成他的 OKR。对于这种测试领导，反而是个累赘，不如干掉的好。有这种测试管理者的存在只会让测试在业务的专注度分心，反而影响业务质量。坦白讲，如果我是公司的创始人，我会把测试部门干掉，把这些测试管理者干掉。

可悲了吧，所以测试的产出到底是什么？

不太合理，测试是为了保障交付质量的，本来就应该独立于交付方，不然都是一伙人，起不到监督作用

这个模式有利有弊：
3 年前，我们就是这种模式，每个测试是工作在开发组内的。 好处是对于这个技术层的纵深会有提高。你会经常接触到源码，框架。你需要设计特有的自动化来进行功能/性能甚至白盒测试。技术发展是突飞猛进。
不好的地方是话语权，如果领导认同质量管控，给与话语权， 那还好， 不认同那就是背锅工具人了。

但是我工作了 4 年，都是归开发团队领导来进行管理

我们也是这种 与其说是成都研发中心 倒不如说是成都外包中心 每个项目各自为政 测试部又跟到每个项目走 各种不规范 大公司不容易去改变 小公司还有希望

那我这边边可能是属于比较好的了。我的直属领导不在这边，而且平时他负责的工作比较忙没时间管我。我在这边跟着开发他们，项目经理让我自己管着自己就行了 。

看完了大家的回复，其中@zy的回复，跟我们这边类似。小结与建议一下哈：
1、测试部门调整，是正常的。因为公司是大家利益的共同体，公司需要在这个不断变化的社会环境中生存与发展，当公司运营发生变化，如高层变化，业务调整等，所以我们只能去拥抱变化。
2、是否要有独立的测试部门，与当前组织的发展阶段及成熟度有关。如测试团队才几个人，此时，没有独立部门的必要，因为有测试小组即可解决项目业务质量守护的问题了。当有多个测试小组，如 20-30 人，或更多，此时，成立测试部门，在专业发展上寻求突破，让更多人看到希望。对业务对个人的成长都是好事，这通常见于中型、大型公司。再往上，如果存在多条业务线，不同业务线有不同测试部门，为了加强测试平台建设，提升测试效能，此时增加测试事业部（或叫测试中心），新增测试总监是比较合适的。这可能是国内大厂才能匹配或有这方面的需求。
3、就我们国内，软件测试领域可以说从 2000 年后才慢慢发展起来。存在各种各样的问题，很正常。对于我们已选择这个领域的职场人来说，更重要是如何加强内功，给公司创造价值，如如何更好更快完成某业务的测试，无漏测，有时还能提出一些业务需求问题，也能给开发的架构设计提出有建设性的建议。开发的测试工具不仅内部用，还可以给开发、其他专业方向团队使用，给团队存在的价值发挥正能量、影响力。

先说这么多了，关于测试团队的发展之路，更详细的分析可读《软件测试之魂》第 13 章 追逐软测之理念，里面讲到当下多种测试团队的发展模式。（微信读书或知乎上有电子书：https://www.zhihu.com/pub/book/120259368）

多问一句哪里难受

不合理，本来测试开发平级，这下差不多搞成上下级关系了。测试地位低下就会造成背锅局面，不管什么情况都是测试背。亲身经历过，已出坑