测试经理只是个title，小一点如测试主管，大一点如测试总监都有类似的窘境。看似有资源，但发现测试资源打散在业务线，实际工作任务掌握在相应业务线的项目经理或产品经理。好一点的，自己还能给组员打一些绩效，不太好的，发现绩效自己也未必能完全做主，一些业务自己也不了解，不太能插上手。
所以一些测试leader会强推一些测试工具和平台，这样自己就有产出了。但随着行情下滑，公司愿意投在测试技术的成本也越来越少，这些测试平台停工或者维持现状对于公司也没太大影响，这无疑对部分测试leader来说基本盘都丧失了。
总结一下容易被架空的测试经理的行为特征：
- 公司项目参与程度低，只做任务分配和进度收集。
- 忽视项目本身的业务测试问题，只做技术测试。
- 喜欢组织团队分享，但自己不输出，流于形式和汇报。
- 与项目经理以及业务部门交流少，存在感低。
测试leader自己也困惑，不清楚自己的定位是啥，因为测试这行业的立身之本就不明确，业务？技术？沟通？流程管理？似乎每一项都沾边，但是你陷进去其中一项就会发现测试管理未必能做好。这种情况是你看到了事情本身，但缺乏一个管理者的底层逻辑去指导你。底层逻辑是你的管理思维，关于业务、技术沟通是呈现出来的部分。
测试管理最重要的是满足公司核心利益，实际讲是满足兄弟团队的共同利益以及自身的利益。是的，我把兄弟团队放在前面，比如开发团队和业务团队，对于测试团队的属性咱们不用特别高估，本身就不属于第一生产力，所以我们的价值就是把核心技术团队的价值维护好。那对于测试leader如何把这件事情做好呢？
从思维上来说，这涉及到三个管理逻辑：同级管理，向上和向下管理。
（这里说的管理，不是说组各种利益团体，而是如何把事情抓在手里，并且做好）
同级管理
我们经常遇到一个问题是跨部门合作好像蛮难的，为什么难？
因为别人觉得是你自己的事情，为什么需要用我的资源帮你达成？但事实上，最终能够产生价值的事情从来不是一个团队的事情，这部分前提是要找到共同的目标价值。比如我拿精准测试来说，一些改动和实验是需要研发配合，这件事情做之前就需要拉上研发一起，找到共同的价值诉求以及制定捆绑的KPI。
而不是遇到问题了，去找别人，别人才知道你在做这件事情，而且还需要抽资源来帮你，这部分资源和时间也不在别人原来的规划里。这种情况下，你觉得能够做好的概率有多大？做不完说别人不配合你？说团队没有技术追求？我相信这样的话很多人听过，但可以反思下自己的做法是否科学。
最后，不要因为你觉得跟同级管理者有利益竞争就放弃合作，这样等于给自己画了一个句号；应该尽量做到你中有我，我中有你，寻找双赢的机会。
向上管理
对于测试来说向上管理尤为重要，小到每天站立会，大到部门例会，测试往往发言的机会都不会太靠前，所以主动向上管理就显得比较关键。
向上管理有哪些注意点呢？
- 不要觉得自己做的事情越多，就一定会有结果，做的事情和价值要能呈现出来，且有一定的思维高度的总结。
- 不要闷不吭声，绝大多数leader还是喜欢能表达的同学，不要去吐槽，能说问题也要能说解决方案。
- 遇到机会，敢于承担，风险预控，提前暴露，不要还没做就怕做不好，0-1的经验很关键。
- 站在leader的角度看问题，甚至可以到N+2，当思维趋于一致时，就容易与leader产生共鸣，这样的人leader自然喜欢。
向下管理
- 不要跟下属一起去吐槽人或者事情。吐槽本身就不积极，会带偏团队节奏；而且吐槽是最容易的，最“爽”的事情，会传染。如果你作为leader喜欢吐槽，团队可能会被带垮。
- 学会沉淀和分享，不要流于形式，真正从问题出发，从方法到方法论的提升，让团队成员能够看到你的认知水平，提升自己的影响力。
- 参与核心项目，不要只做任务的传递者，分析问题并解决问题，有公信力的leader是带队打仗打出来的。
- 管理的核心要素在于事情梳理，在平时一些无关紧要的事情上，不要用职级去干预。
- 作为leader要保持谦虚，遇到自己不了解的技术问题或者业务问题也是正常的，虚心请教，不要放不开面子。
如果上述的事情你有几乎都没做到，那你作为leader还需要加强自身的管理能力，不要被每天的会议带的晕头转向，然后只做一些任务的简单分配，这样的管理者价值不大没有粘性，一旦公司成本收缩，你这样的角色要不要就难说了。每天睡前留一些独立思考的时间，把团队和个人目标达成都能想一想。
下面是具体的一些实践思路
测试管理也要学会下地干活儿，通过实践才能更好地优化你的管理思维，才能更容易达成管理目标，脱离事情本身做管理，会极易产生脱节。这里阐述四点。
技术
作为一个团队的管理者，各种技术细节很难事必躬亲，但是你得有基本的认知。比如，你们公司的微服务架构，各种组建解决什么问题，能不能自己搭建一套实施一下，这样的技术成本不是很大，但可以很大的提高你的技术对话能力；比如，业务一些开源的自动化平台以及框架，部署试用发现其优缺点和适用性，这些小尝试都可以提升技术视野且性价比也是高的。如果没有一定的技术基础，你怎么与相同段位的开发或者运维去对话呢？而你没有对话能力，不仅是你个人的问题，必然也会带来团队的被动。
业务
业务能力在于整合资源，识别风险，保证项目按时交付。虽然简单一句话，但是需要你具备多种能力，首先是对内的管理机制，在资源相对紧缺的情况下，组内能不能有增援快速上手，对外有没有分析造成项目紧张的原因去争取更多的资源。
而且我的建议是：虽然你是管理，但最好带一支核心的业务。这样看问题才会更全面，做决策才更有依据，而执行的颗粒度你也是可以自己控制的。一些管理者由于每天琐事的插入和自己的惰性会逐渐远离繁琐的业务，这一点是不可取的。对于测试管理来说，这个岗位本身就在被稀释，当你跳槽了，是不是还是管理属性，或者管理属性会不会打折扣，是打问号的。
质量体系
做这事情的前提是——认知。有的同学经历过多家公司会发现在一些公司很难做成的事情在另外一家公司就是基本操作，比如说业务测试中的单元测试，比如说冒烟执行的通过率，比如说性能测试的数据需求分析。
已经变成基本操作的公司都已经在做执行质量内建的实践，而很难做成的公司别说实践，他们可能连质量内建的意识都没有，或许根本也不了解什么是质量内建。对于我们测试人员来说，说小一点会影响我们的工作环境，工作环境的好坏会影响我们的心情；说得大一点，一些局面没有打开，有可能会影响我们的职业生涯。在难做成的公司，其实你存在大量的机会，可以认真思考下质量内建这件事，质量内建不是本文重点，我稍微引申下4个关键因素：测试左移+持续反馈+测试右移+全员参与。
- 测试左移：尽可能在测试本身活动开展之前就接入测试，包括在需求和设计阶段（形成规范+落地实例）。
- 持续反馈：保持高度的信息透明和及时的信息反馈，才不至于由于信息盲区导致的风险变大（尽早介入+固化流程）。
- 测试右移：项目交付后的线上运营也是至关重要的一环，获得用户的反馈并不断地迭代优化（灰度发布+用户调研）。
- 全员参与：质量内建是项目全体成员都需参与并为之负责，结合自身和公司情况，先做好自己（日志+告警+资源），形成影响力，再落地体系。
善于沟通
沟通这个事情看似简单，但其实是多种能力多种要求。在一些公司，会沟通可能比你会做事情会更重要。做好沟通需要你有一定的情商，同时也要求你的技术认知和业务认知能够做到同频，这样才能深入地去讨论各种问题的细节。