公司进行组织架构调整，取消了测试部门，把测试人员划分至开发部门，由开发人员进行管理，是否合理

只是一个拿锤子的约德尔人 9
2022-07-22 18:58:55 未知地区 1F
回复

不合理。我刚刚经历对非测试人员来说无所谓，但对测试人员来讲影响很大，由之前独立的部门变成挂靠在研发团队下面，话语权少很多，加上挂靠在项目下面，那基本以后都是业务为主，能伸手做其他事情的机会更少了。个人觉得架构调整是很正常的有利也有弊，根据公司运营情况调整架构，可能是为了提效，也可能为了重新洗牌让一拨人上车，总之打工人 打工魂嗯，所以准备找新工作了嗯，个人感觉是后者吧，新换了个领导同病相怜同样的架构调整 +1，比较难受我们有测试部，但是人又挂在项目里，测试部老大只协调资源了，基本跟着项目走看团队吧。对项目影响是积极的有益的。但对个人来说，上升空间≈阻断。以前遇到过一次架构调整，让我从测试开发转功能测试，直接试用期果断裸辞了。我想问下测试总监的直属上级是不是 cto？还是有哪家公司的研发老大是 qa 总监和开发总监平级的。。如果刚毕业 呆个半年还是可以的 因为可以更加接近源码 去理解里面的东西 但是不建议太久 因为有可能会逐渐失去话语权如果开发负责人足够专业，并且能从测试角度听取意见，倒是还算 ok，不然就是个坑不好说，在上家公司的时候，有半年也是搞了这个架构调整，在开发组做测试。不过我遇到的开发 leader 人比较好，愿意把测试当自己人，技术方案评审，code review 和同组研发都在一起，有的研发同事在我测试前还会串讲一遍代码，让我帮忙看看有没有什么逻辑上的问题；有些大的项目，难测的点，leader 会问我，这个能不能测，会不会测，可以用研发的骚操作去测等等。待了半年，个人感觉对我自身的测试效率，测试深度，技术方向，技术能力，业务系统理解，系统设计代码规范都有不小的影响，甚至在职业方向上都影响贼大（跳槽之后转开发了）。
我在那段时间的体验是，非常的累，不过！每周！都感觉脑子里被灌了很多新东西，但有不少其他同事的体验却是工作很乱，没有节奏，排期不合理，无法接受。
感觉对于年轻人来说，这个模式不一定是坏事，但是对于已经有稳定的技术栈、工作节奏的老测试工程师来说，应该挺难受的其实不用太在意是不是独立，有多少所谓话语权。如果是新人，其实不用在意。我也是在项目里，直属领导是项目经理。整个项目，没人关心项目质量如何，测试完全被放养。仅提供个人的情况，供参考，但是觉得负责人对测试的理解和重视程度会有关系。自主性变少了，跟人提升可能近似与 没有了，你会跟着项目不断迭代，根本没有时间 精力去弄一下 自己感兴趣的东西，并且你的小伙伴变成了开发，能跟你做一些在测试方面技术探讨和提升的人也没了，更严重的是这种模式可能小一点的项目组 就你一个测试，没个 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）